Moving services shouldn't mean starting again.
Glimpr is an experimental project for creators who offer paid memberships. We're working toward a way for creators to change the service running their page while keeping their name, membership records and members' existing access.
Moving services should not mean starting your membership business again.
- For creators
- Choose another host without rebuilding your membership relationships.
- For members
- Keep the access you've already paid for when a creator moves.
- Status
- Early prototype. Not yet a public membership service.
Imagine moving your work.
Without starting again.
You write stories for 200 paying readers.
The service running your page becomes expensive or unreliable. You want to move. But you don't want to ask 200 people to find you somewhere else and subscribe all over again.
That is the problem Glimpr is working on. The goal is to let you change the company hosting your work while keeping your name, membership records and the access your readers have already paid for.
a new service
Technical detail
Why a move can be checkedThe creator authorises the replacement host. Membership history can be exported and verified rather than recreated from an unverified customer list.
Authority and availabilityA move still needs available history, content and creator-held secrets. Ending a host’s authority cannot reconstruct missing files.
You already paid.
That should still count.
Now imagine you're one of those readers. You paid for a month of the writer's stories. Halfway through, the writer changes the service running their page.
You're still supporting the same person. Your membership should still mean the same thing. A change of hosting company should not, by itself, require you to buy the same access again.
Glimpr's design lets your device hold evidence of that membership. A replacement service can check it against the creator's records.
That is the experience we're aiming for. Posts still need an available service to deliver them, and payment arrangements need working integrations.
Technical detail
Member-held evidenceA membership is bound to the member’s identity for that creator. A service must authenticate the presenter and evaluate the relevant history under its verification policy.
A host change is not a payment migrationPreserving an existing membership does not establish that a recurring-payment authorisation can move between payment providers.
Hosting is a job.
You choose who does it.
A host is the company storing your posts and keeping your page available. A payment provider handles charges and payouts. Glimpr is the experimental protocol—the shared rules intended to let these services recognise the same creator and memberships.
The idea is familiar: a book club can rent a different meeting room and remain the same club. Changing the venue should not dissolve the membership.
-
You publish your work.You choose a hosting service and define what your paid membership offers.
-
Someone becomes a member.A payment provider confirms payment, and a record establishes the access they receive.
-
The member reads your posts.Their device holds membership evidence and receives what it needs to open eligible content.
-
You can choose another host.The replacement checks the available records so the existing relationships can continue.
We are developing those rules and a prototype to test them. Glimpr is not a finished membership service you can sign up for today.
Technical detail
Why “confederal”?Each creator authorises their own services. Clients contact the host serving that creator; hosts do not need a host-to-host federation protocol.
The creator is the authorityA host receives a bounded delegation to act within a particular epoch and range of history positions. It does not acquire the creator’s root identity.
A name that can
follow your work.
People should be able to find the same creator after a move. The goal is for your Glimpr name to lead to the service you currently use.
You authorise that change. A member's app checks the supporting evidence before accepting the new destination.
The aim is to help people keep finding you. Disputes over who deserves a name still need rules and a way to resolve them.
Technical detail
Proof-bearing discoveryDirectory lookups carry inclusion or non-inclusion proofs against an accepted root. A failed response is not proof that a name is unclaimed.
An independent reference mattersA directory cannot establish independent assurance by supplying every reference used to check itself. The prototype has not yet established an independently anchored deployment.
Your membership records.
Ready to move with you.
A list of names is only part of the relationship. You also need to know who joined, what they paid for and whether their membership is still active.
Glimpr records those changes in a history that another service can check. That gives a new host a basis for recognising existing memberships.
The goal is to carry the relationship forward with evidence of what happened. Importing a list from another platform does not automatically transfer its payment permissions or billing history.
Technical detail
History that can be comparedEvents form an append-only, hash-chained log. Witnesses attest to checkpoints. Conflicting signed statements can provide evidence of incompatible histories when those views are compared.
What a record cannot doA valid history does not supply missing content, and a valid older checkpoint may omit later events. Availability and freshness remain separate requirements.
Payments go through
providers you choose.
In the design, money goes from the member, through a payment provider, to the creator. Glimpr does not hold a member balance or a creator payout balance.
You can authorise more than one provider and choose the order in which they are tried. If one cannot serve you, the aim is to have another usable route for future payments.
That requires real integrations and a valid payment method. A different provider cannot release funds already frozen elsewhere, and switching is not automatically effortless for the member.
Live payment processing is still work to establish. We are not presenting prototype fallback as a guarantee for real payments.
Technical detail
Payment evidenceA provider-signed receipt supports membership issuance or renewal. An attempted charge is not a confirmed payment; pending outcomes need reconciliation.
Refunds have two partsThe provider returns funds and the membership history records the corresponding revocation. A verifier can recognise that change only once it receives acceptable evidence containing it.
Private posts.
Less to hand over.
Member posts are designed to be encrypted before they reach the host. The host can store and deliver them without receiving the secret needed to read them.
| Information | Where it belongs |
|---|---|
| Member posts | Encrypted on the host; opened on authorised creator and member devices. |
| Card details | With the payment provider, outside the membership records. |
| Account secrets | On the member's devices and in their protected backup. |
| Public posts and profile | Visible to everyone, including the host. |
Privacy has limits. The host can still see activity such as when a post is requested and how large it is. Payment providers can know who paid.
Members can also keep copies of what they read. Ending a membership cannot take those copies back.
Technical detail
Shared audience encryptionThe current design shares one audience secret across a creator’s member content. Tier restrictions depend on serving policy, and the secret is not rotated on revocation. A former member may decrypt other files using that secret if they obtain them.
Data minimisationSeparate identities reduce matching across creators by identifier. Imported rosters, delivery systems and request logs still need their own privacy handling.
A membership another
service can recognise.
Think of it as holding a membership card whose authenticity another service can check. The card refers to the creator you support, rather than relying solely on the company currently running their page.
That is why a membership record you can carry matters. A replacement service needs a way to establish that you already belong, what access you have and whether it has ended.
The check can run on a device using the evidence it has. It still needs sufficiently current records: an old proof cannot reveal a cancellation that happened afterwards.
Technical detail
Same inputs, same policyThe verification calculation uses supplied evidence and an explicit policy. It makes no network request and reads no local clock. Different policies or evidence can produce different results.
The application still mattersThe surrounding software may fetch evidence or log activity. A local calculation does not establish that every application using it is telemetry-free.
What we're building.
What still needs work.
Glimpr is experimental. The examples above describe the experience we're working toward.
The private prototype explores membership records, encrypted content, verification, payment fallback and changing hosts in controlled conditions. A controlled demonstration does not establish a reliable public service.
| Still to establish | Why it matters |
|---|---|
| Independent checks | The pilot combines roles under one operator. Naming and history need references and witnesses independent of the service being checked. |
| Real payments | Live providers, settlement and usable fallback must be demonstrated before promising uninterrupted billing. |
| Recovery | A move needs available records, posts and creator secrets. A lost host cannot be replaced using authority alone. |
| Account protection | Losing all usable devices and backups can mean losing the account. Removing a device cannot erase secrets it already copied. |
| Public operation | The service needs to keep accounts safe, preserve records and recover reliably when something goes wrong. |
The aim is simple: a creator should be able to choose a different service without asking their audience to begin the relationship again. We need to demonstrate the parts that make that possible.
Technical detail
No absolute independence claimGlimpr does not describe the prototype as trustless or promise that a creator cannot be deplatformed. Providers and infrastructure can still refuse service.
For developersThe documentation explains the design and its limits. The implementation is private and interfaces are not a stable public integration contract.
Glimpr started as something else: a stranger-chat protocol. That version is not coming back. The reasons were about safety, and they were good enough to stop over.