Protocol overview
Glimpr separates the authority over a creator’s membership community from the services that operate it. Identity, hosting, naming, witnessing and payments have distinct responsibilities. Combining those roles in one deployment does not make their trust assumptions disappear.
Participants
| Participant | Responsibility | Boundary |
|---|---|---|
| Creator | Signs the creator record, membership offering, host authorisations and changes of host. | Must protect signing authority and retain the material needed for recovery. |
| Member | Holds a separate identity for each creator and the evidence supporting that membership. | Device access and recovery material determine who can act as the member. |
| Host | Maintains authorised history, stores encrypted content and applies access checks before serving it. | Its authority is limited by the creator’s delegation. |
| Directory | Resolves a name to the creator’s current record with a proof of inclusion or absence. | A proof needs an independently established directory reference. |
| Witness | Co-signs history checkpoints and retains the statements it signed. | Independence and comparison of views are necessary to expose conflicting histories. |
| Payment provider | Processes payments and supplies signed evidence of their outcome. | Retains control of settlement, disputes and funds in its custody. |
A client is software acting for a creator, member or verifier. It checks evidence before relying on a service’s answer.
From a name to a membership
- The client resolves the creator’s name and verifies the directory evidence.
- The creator record identifies the authorised services and commits to the membership offering.
- An authorised payment provider confirms payment. The host validates the receipt and records the resulting membership within its delegation.
- Witnesses attest to the updated history. The member receives evidence tied to their identity for that creator.
- The creator’s client delivers the material needed to open member content, encrypted individually for the eligible member.
- A verifier checks the membership, its supporting history and the presenter’s authority under an explicit policy.
Payment confirmation, membership issuance and content-key delivery are separate events. A pending step must remain visible as pending; it cannot be replaced by an assumption that the next step succeeded.
The chain of authority
The creator authorises the host. A valid provider receipt supports the membership. The history fixes where issuance occurred. Witness evidence supports the accepted checkpoint. The member proves authority to present the relationship.
Each link answers a different question. A genuine host signature does not establish that the host was authorised. A valid receipt does not establish that the presenter is its member. A consistent history does not establish that it is current enough.
Protocol invariants
- One signed representation. The purpose and contents of a record are bound together; formatting changes cannot create a second interpretation.
- Proof-bearing reads. A failed lookup is distinguishable from proven absence. Unverified directory data is not a fallback answer.
- Append-only history. Later events extend earlier history. Corrections and revocations are recorded rather than silently replacing the past.
- Bounded delegation. The epoch and position range limit what a host may authorise.
- Explicit verification policy. Witness threshold, permitted lag, grace and requested access are part of the decision.
- No protocol custody. Membership records describe payment outcomes without holding member funds or creator balances.
These are design requirements. The independent operation and recovery needed to support them in deployment are addressed in Limits.