Glimpr: an experimental confederal creator-commerce protocol

Glimpr is a protocol for paid memberships in which the creator controls their identity, the member holds their membership, and a host serves the relationship under a limited grant of authority.

A creator’s name, membership history and payment arrangements should remain theirs when a service changes. Glimpr gives each of those claims a mechanism: signed routing information, witnessed history, bounded hosting authority and an ordered choice of payment providers.

Confederal describes how those mechanisms fit together:

• Creator sovereignty. The creator’s signing identity is the root of authority. It authorises the host, the membership offering and changes of service. Clients check those authorisations independently.
• No host-to-host federation. A client contacts the host serving the creator it needs. Hosts share a protocol for recognising creator authority; they do not have to establish a federation with one another.

Status. Glimpr is an experimental design with a private prototype. This book describes the protocol and its trust assumptions. It does not announce a released product, a public implementation or a stable integration contract. Deployment boundaries are stated in Limits.

Design principles

• Bounded hosting authority. A creator authorises a host for one chapter of history and a fixed range of positions. An action outside that grant fails verification even when the host’s signature is genuine.
• Portable membership history. Issuance, renewal and revocation belong to a per-creator append-only log. Witnessed checkpoints let a replacement host verify the history it receives.
• Verifiable discovery. A name lookup carries evidence of inclusion or absence against a directory state the client can independently establish.
• History-relative verification. Freshness and membership standing use witnessed progress and recorded billing periods. The verification decision does not consult a local clock.
• Content sealed before upload. Member content is encrypted for the creator’s audience. Storage and the authority to decrypt it are separate responsibilities.
• Money as facts, not custody. Providers handle funds. Signed payment evidence supports membership issuance and renewal; Glimpr holds no payout balance.
• Separate member identities. Each creator relationship uses a distinct identity, reducing correlation through a shared account identifier.

Hosting is a job you can fire. The test is whether the name, history and existing memberships still work after the host changes. Signatures establish authority; available data and independent checks make the move usable.

Reading the design

Start with the Protocol overview, then Directory, Log and epochs, and Delegation and switching.

For the paid relationship, read Memberships, Payments, and Content sealing. Verification explains the evidence behind an access decision.

Signatures and encoding and Signed records describe the technical foundations without requiring implementation details. Privacy, Misbehaviour, and Limits state the boundaries.

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

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

1. The client resolves the creator’s name and verifies the directory evidence.
2. The creator record identifies the authorised services and commits to the membership offering.
3. An authorised payment provider confirms payment. The host validates the receipt and records the resulting membership within its delegation.
4. Witnesses attest to the updated history. The member receives evidence tied to their identity for that creator.
5. The creator’s client delivers the material needed to open member content, encrypted individually for the eligible member.
6. 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.

Signatures and encoding

A signature must bind one meaning to one representation. Glimpr uses canonical encoding and purpose separation so that a record cannot acquire a different meaning when it passes between services.

Domain separation

Every structure that gets signed or hashed is tagged with what it is, and the tag sits inside the signed bytes rather than alongside them.

Consequences:

• Bytes signed for one purpose cannot be replayed as another purpose. A delegation cannot be presented as a receipt, even by an attacker who holds both.
• Two structures with identical values but different kinds produce different hashes and different signatures.
• Field order within a structure is part of the encoding. Reordering fields is a breaking change, not a cosmetic one.

Canonical bytes

Each structure has exactly one valid byte representation. There is no whitespace, no field reordering, and no optional formatting — two conforming implementations encoding the same values produce identical bytes.

Human-readable formats appear only in transport framing and display. Nothing verifies against them: a verifier that needs to check a signature reconstructs the canonical bytes from the decoded values and checks against those.

Identity

A creator is identified by their root public key. A member uses a different public identity for each creator relationship.

Names are discovery labels attached to creator records. They are not an additional authority above the creator’s signing identity. Likewise, the protocol does not require one public member identifier shared across every creator.

Separate identities prevent direct matching by that identifier alone. Payment information, network activity and information members publish can still correlate relationships. See Privacy.

Signed record families

The design distinguishes the following signed records. Their names describe their roles; reading this book does not require source-code names, field layouts or wire tags.

Their meaning and authority are described in Signed records. The log head is described in Log and epochs, and the directory root in Directory.

Sealed blobs

Member content is sealed before upload, into an envelope addressed to a recipient key.

A blob is identified by the hash of its sealed bytes, uniformly for every content class. A host can therefore address, store and serve a blob without being able to open it. See Content sealing.

Cryptographic primitives

Signing and verification use Ed25519. Hashing uses BLAKE3. Key agreement uses X25519, and sealed content uses XChaCha20-Poly1305.

These are established cryptographic primitives. The security of their composition still depends on the record bindings, key handling and verification rules; the choice of primitives alone is not a security review.

Signed records

Signed records state who authorised an action, what it applies to and where it belongs in the history. This page describes their meaning and relationships. The representation rules are explained in Signatures and encoding.

Creator record

The routing and policy record a name resolves to. Signed by the creator root.

The provider list is ordered: the first entry is the processor of record and the rest are failover order. A host cannot reorder it, insert itself, or route outside it.

Re-pointing after a host switch means publishing a record with a higher sequence number.

Host delegation

The grant that lets a host sign. Signed by the creator root.

A host action outside its epoch or outside its position range is invalid even when validly signed by that host. See Delegation and switching.

Epoch close and epoch open

A close fixes the position and hash of the last entry in the epoch. An open names the epoch being started, its first position, the close it chains from, and the host taking over.

• An opened epoch is exactly one higher than the closed one, and starts at the next position.
• The chaining commitment means epochs form an unbroken sequence; a gap or an overlap does not verify.
• A normal close is signed by the outgoing host. A forced close is signed by the creator root and needs no cooperation from that host.

Tier schedule

What is on offer. Signed by the creator root, so a host cannot alter pricing or scope.

Each tier carries an identifier unique to the creator, a price in minor units, a currency, a period length, the set of content classes it entitles, and whether it is still active.

Deactivating a tier prevents new issuance under that offering. Existing membership evidence remains part of history, but access to a requested content class also depends on the current schedule and the verifier’s policy. Historical issuance and present access are separate questions.

Entitlement

The membership itself. Signed by the host holding a valid delegation at the time of issuance.

Presentable only by the bound member key. Presentation by any other key returns wrong subject — never a weaker pass. The service must authenticate control of the presenting identity. Comparing a claimed identity with the record is insufficient. Binding prevents a copied credential alone from granting access; it cannot prevent deliberate sharing of account secrets.

Payment receipt

Evidence a payment happened. Signed by a payment provider, and carrying the provider, creator, member, tier, period, amount, currency and an opaque provider reference.

Valid only from a provider in the creator’s current ordered list. A well-formed receipt signed by any other key licenses nothing.

Content item and manifest head

A content item records a publication, a supersession, or a removal. It carries its position in the content chain, a commitment to the previous item, the content class, and the hash of the sealed blob. Supersession and removal name the item being acted on.

Removal is an explicit chained event, never a silent deletion.

The manifest head names the newest content item, so a client can find the end of the chain without walking it.

Share grant

A member authorising one verifier to see one membership. Signed by the bound member key.

It carries a commitment to the entitlement, the grantor, the single verifier key it is for, a human-readable purpose, and an expiry.

• A grant is not bearer material. It names one verifier.
• Expiry is expressed as a log position after which the grant is dead, not as a timestamp.

Invite

An invitation connects an imported audience entry to a single-use claim. It identifies the creator and offering, commits to the claim token, and contains a derived value used to recognise duplicate imports.

Redeeming an invitation still requires valid evidence for the resulting membership. Importing a roster does not transfer payment instruments, recurring-charge authorisations or the previous service’s billing history. See Privacy.

Device certificate

A device certificate describes authority granted to a device under a root identity, including a limited capability where appropriate. Replacing or revoking the certificate changes the grant; it does not erase secrets the device already holds.

In particular, a device that has received account-wide recovery material cannot be made harmless by changing a certificate alone. Devices distinguishes certification from replication of account secrets.

Provenance

A provenance attestation is a third party’s signed statement about a subject. It supplements the evidence without becoming the creator’s root of authority.

A verifier may require particular supporting attestations under its own policy. Missing required attestations cause that policy to fail; a verifier that does not require them can evaluate the underlying membership without them. Attestation policy is therefore part of the trust decision, not a universal endorsement.

Revocation

Ends the validity of a subject. It names what kind of thing is being revoked — a device certificate, a host delegation, a share grant, a membership, or an invite — together with a commitment to the specific object.

Cancel, refund and lapse are all membership revocations and are byte-identical on the log. All three read as revoked, and a verifier cannot distinguish them. This is deliberate; see Memberships.

Directory

Name resolution connects a handle to a creator record and the services that record authorises. The directory must provide evidence for its answer, including an answer that a name is absent.

Data model

The directory holds a sparse Merkle tree whose leaves commit to the current state of each name. The position of a name in the tree is derived from the hash of its text.

The tree commits to current state only, not to per-name history. History is available by replaying the update stream.

Absence versus emptiness

Two distinct situations, which clients must not conflate:

• The name is absent. Nobody has claimed it.
• The name is present with an empty value. Somebody holds it and has published nothing.

Only the first means the handle is available.

Roots

The directory publishes a signed root carrying a strictly increasing sequence number and the tree root hash. It is signed by the directory operator and co-signed by witnesses over identical bytes.

Because the co-signatures cover the same bytes, a witness set holding two different roots at the same sequence number holds a conviction — see Misbehaviour.

Reads

A read returns the record together with a proof against a root the client already trusts:

• Inclusion proof — the name is present, and the record hashes into the tree root.
• Non-inclusion proof — the name is absent, proven positively.

A client:

1. Verifies the root’s operator signature and its witness co-signatures.
2. Checks the root against its own quorum and freshness policy.
3. Verifies the proof against the tree root.
4. Only then decodes and uses the record.

A response failing any step fails the read. There is no fallback where an unverified response is used, and no state in which “the directory returned nothing” is treated as absence.

Registration and updates

A registration or update is signed by the creator root and gated by proof-of-work over the request. The work is paid to nobody. It exists so that sweeping the namespace for every plausible handle is expensive rather than free.

Validation at the directory layer:

• the signature verifies under the claimed creator root
• for a first write, the signer is the record’s own root key
• for an update, the signer matches the current record’s root key
• the sequence number strictly exceeds the current record’s
• the proof-of-work meets current difficulty

Updates are held pending between root commits, so several can be accepted without each waiting for its own commit interval.

Freshness

Root freshness is a quorum and advancement property, never a timestamp:

• enough distinct witnesses from the client’s configured set must have co-signed the root
• the root’s sequence number must be within the client’s configured lag of the newest root the client can establish

A root failing either test is stale, and stale is a failure rather than a weaker pass.

Anchoring

A client’s trust root is an anchored state: the operator key, a witness set with a threshold, a maximum lag, and one specific anchored root.

This is the load-bearing requirement, and the easiest to get subtly wrong:

A client that learns its root by asking the same party it is about to check has verified nothing. That party can supply whatever root makes its own answers check out.

For anchoring to mean anything the anchored state must be published somewhere the party being checked does not control, and the client must pin the anchor reference rather than a root fetched at runtime.

An independently published reference and the client behaviour that checks it are both deployment requirements. The current boundary is stated in Limits.

Name control and disputes

A verified lookup establishes control of a name within the namespace. It does not establish a person’s real-world identity, resolve impersonation or decide a trademark dispute. Registration policy and dispute handling remain responsibilities of the namespace operator.

Log and epochs

Each creator has an append-only history of membership, content and hosting events. Signed checkpoints bind that history to an authorised host; witness attestations make competing accounts of it comparable.

Entries

Every operation of consequence is an entry: a membership issued, renewed or revoked, content published, a manifest head advanced, an epoch opened or closed.

Entries are hash-chained. Each entry’s hash is computed over its own contents together with the hash of the entry before it, so an entry’s position is fixed by every entry that follows. Altering anything at one position changes every hash after it.

Heads

A head is a signed commitment to the whole chain up to a position. It names the stream, the epoch, the position, and the chain hash at that position.

It is signed by the host for the covering epoch and co-signed by witnesses over the same bytes.

Because the chain commits backwards, a head commits to the entire history, not only its last entry. Signing a head whose hash is not the true chain hash at that position is a detectable act rather than an ambiguity.

Time

Verification uses two forms of recorded progress:

• Log position: how far the accepted history has advanced.
• Billing period: the period through which membership has paid coverage, compared with the current period recorded in that history.

The verification calculation does not read wall-clock time. The same verified history and policy produce the same decision regardless of the machine’s clock.

Freshness is nevertheless a policy choice. A verifier specifies its witnesses, the required threshold and the permitted distance behind the latest evidence it can establish. Old evidence does not become current simply because its signatures remain valid.

If the history does not advance, passage of calendar time alone does not change the result. Real payment scheduling must therefore be related explicitly to the progression recorded in the log; the ordinal model is not a completed calendar-billing service.

Epochs

The log is partitioned into epochs. An epoch is opened by the creator naming the host permitted to write during it, together with the range of positions that host may occupy.

An epoch is closed by fixing the position and hash of its last entry. That closing head is the last thing the outgoing host is permitted to have written.

Epochs exist so that authority can end by arithmetic rather than by vigilance. Without them, ending a host’s write access would mean detecting and rejecting its writes indefinitely.

Export and import

A creator’s history moves between hosts as a self-contained export: the entries, the chain linking them, and the signed heads attesting to them.

The receiving host verifies offline before adopting anything:

1. Recompute the chain over the supplied entries.
2. Check every head signature under its claimed signer.
3. Check the final head’s hash equals the recomputed chain hash at that position.
4. Check epoch chaining — each open matches the close it claims to follow.
5. Check every entry falls inside the delegation covering its epoch.

A history that changes without matching the trusted signed commitments fails verification. A shorter, internally consistent history can still be old; completeness and freshness must be checked against the required checkpoint.

The receiving service must validate the export before treating it as its authoritative history. Durable adoption, interrupted writes and restart recovery are additional implementation responsibilities.

What the log is not

• Not a readable archive. Entries commit to content by hash; the content itself is sealed and stored separately.
• Not a public feed. Serving entries is a host function, subject to the same proofs as anything else.
• Not an analytics store. Its purpose is to make a specific set of claims checkable by a stranger.

Delegation and switching

A host serves a creator under an explicit grant. The grant determines which actions clients may accept and how the creator can replace the service.

Bounded grant

A host signs memberships, content items and manifest heads. Its authority to do so is a host delegation fixing:

• the single epoch covered
• the inclusive range of log positions it may occupy

Validating any host-signed object therefore includes:

1. The signature verifies under the host’s key.
2. A delegation for that host exists for the object’s epoch.
3. The delegation names the same creator as the record.
4. The object’s log position falls inside the delegated range.

Failing 2, 3 or 4 means the object is outside the delegation — the signature is real and the object is still invalid. Every party performs this check independently, including member devices.

What that buys is the difference between “the responsible party would notice and intervene” and “it does not verify.” Only the second survives the responsible party becoming the problem.

Switching hosts

Four signed steps, all authorised by the creator root:

1. Close the current epoch. This fixes the last position and hash. A forced close is signed by the creator root and requires no cooperation from the outgoing host.
2. Open the next epoch. The open names the new host and chains to the close. A new delegation fixes the new bounds.
3. Transfer the history. The new host verifies the export offline before adopting anything — see Log and epochs.
4. Re-point the name. A creator record with a higher sequence number and the new delegation commitment is published to the directory.

Witness-held checkpoints support a creator-authorised close without the outgoing host’s permission. Completing the transfer also requires available history, content and creator-held secrets. A forced close cannot reconstruct missing data; a move from an unreachable host requires those materials to survive elsewhere.

What survives

The intended continuity across an epoch boundary is:

• Memberships remain valid, unchanged. No reissuance. Each still verifies, with the same bytes, under the same member key.
• No membership rewrite on member devices. A host change alone does not require a new membership or identity. Clients still need acceptable routing and history evidence for the replacement service.
• Billing continues on the same period ordinals.
• Sealed content stays readable by whoever could already read it. The audience key was never the host’s, so replacing the host removes no access.

Mid-period switching is the case the design has to carry. A host that can only be left at a convenient moment cannot really be left, because the inconvenient moment is exactly when leaving matters.

What the outgoing host keeps

Its copy of the history up to the close, and the sealed blobs it was storing.

Neither is a disclosure: the entries were always its to hold, and the sealed content was never openable by it.

The close ends its authority to extend the accepted history. Clients with sufficient current evidence reject later actions outside that authority and follow the updated directory record. A client with only an old view cannot learn the change without obtaining newer evidence.

Memberships

Membership standing is derived by applying the recorded events for one member and one creator in order. The host cannot establish validity merely by returning a status from its own database.

States and transitions

A membership is subscribed, or revoked. It begins with an issuance, continues through extensions, and ends with a revocation. It may begin again afterwards.

Invalid transitions include:

• The sequence number is not exactly one higher than the previous.
• An extension does not increase the paid-through period.
• The member key differs from the membership’s bound key.
• An issuance arrives onto a membership that is already live.

Periods

Paid coverage is expressed as a billing-period ordinal: an ordered period number, rather than a timestamp. The creator’s current period begins at zero and advances through valid recorded payment events. It cannot move backwards, and an event cannot jump it forward by more than one period.

Standing is evaluated against that recorded progress:

Grace is measured in recorded periods. It is an input to the verifier’s policy; a service may require paid standing and decline grace.

Once grace is exhausted, the host can record a lapse as a revocation. Until then, the membership is already expired. Delaying the lapse entry must not extend access.

For example, a membership paid through period four is active at period four, in grace at period five if one grace period is accepted, and expired at period six. These are positions in the billing history, not dates inferred from a device clock.

Cancel, refund and lapse are indistinguishable

All three are membership revocations naming the same subject, and produce byte-identical entries. A verifier cannot tell which occurred.

This is deliberate. A verifier’s legitimate question is “is this membership currently good?” — not “did this person cancel, get refunded, or have a card decline?” Answering only the first is both sufficient and less revealing.

A completed refund flow must also record the corresponding membership revocation. A verifier that receives history containing that event rejects the revoked membership. Old evidence cannot reveal a refund that occurred after its checkpoint, which is why freshness remains a separate requirement.

Subject binding

A membership binds one member key, and only that key may present it. Presentation by another key returns wrong subject — never a partial or weaker pass. The service checking access must authenticate control of the presenting identity. A copied credential alone should not grant access; deliberately shared secrets remain outside that protection.

Presentation to a specific verifier is authorised by a share grant signed by that same member key, naming one verifier and expiring at a log position.

What a member holds

• Their identity key for that creator.
• The current membership and the receipt it references.
• The material needed to unseal content they are entitled to.

Together with the supporting directory and history evidence, those holdings support offline verification. Moving them to another device requires the account material described in Devices.

The membership identifies one relationship. The host still knows the memberships it records, and the creator needs an audience view to distribute content access. Separate identities limit cross-creator correlation; they do not hide membership from every participant.

Verification

Membership verification is a decision over supplied evidence and an explicit policy. The calculation performs no network request, reads no local clock and consults no hidden state. Obtaining and authenticating those inputs is a separate responsibility.

Inputs

Because the freshness policy and the verifier’s key are inputs, two verifiers with different risk tolerances may return different verdicts for the same material and both be correct. A verifier must also authenticate the presenting identity before relying on a match with the membership. The decision cannot establish control of a secret merely by being handed a public identity.

Verdicts

The decision distinguishes nine outcomes. The ordered checks below determine which failure is reported:

There is no unknown, no “probably fine”, and no path where a verifier proceeds because a check could not be completed. An incomplete check is a failure with a name.

Ordered checks

The decision short-circuits on the first failure. The ordering is normative: two conforming verifiers must agree not only that material failed, but on which failure came first.

1. Evidence well-formedness. Check signatures and the bindings between the membership, creator record, schedule, history and issuance authority. The derived membership state must concern the same member. Any required supporting attestations must also be present and valid.
2. Unknown creator. Directory evidence proves the name absent.
3. Stale head. The head fails quorum or exceeds maximum lag.
4. Outside delegation. The signing host must be the delegated host, and the grant must cover the issuance’s epoch and position.
5. Grant checks, when a grant is present. A grant committing to a different membership is bad proof. A grantor that is not the bound member key, or a named verifier that is not the one checking, is wrong subject. A head past the grant’s expiry position is expired.
6. Wrong subject. No grant, and the presenter is not the bound key.
7. Revoked. The accepted event history ends the membership through revocation.
8. Tier superseded. When a content class is requested, the current schedule must contain an active tier permitting that class.
9. Expired. Standing is beyond grace.
10. Valid. Active, or in grace within policy. A valid verdict carries the standing, so a verifier can distinguish paid coverage from accepted grace.

Missing evidence lands at step 1. Material presented without proof is rejected, not treated as weaker proof — this is what stops a verifier being talked into accepting an assertion by a party that declines to prove it.

Presentation bundles

A presentation bundle carries the material needed to check a membership: the creator record and directory proof, epoch history and delegations, membership evidence, relevant events and a signed checkpoint.

The verifier first checks the directory evidence against its trusted reference. It validates and replays the supplied history, deriving membership standing from accepted events rather than from an asserted status. It then applies the ordered decision under its own policy.

This can be done offline, but the result is bounded by the evidence supplied. A self-consistent bundle may omit later events. The verifier needs an acceptable basis for freshness; a disconnected calculation cannot discover an unseen cancellation, refund or host change.

The calculation itself sends no notification to the creator or host. Software around it can still fetch evidence, log requests or collect telemetry. The privacy property belongs to the local calculation, not automatically to every application that embeds it.

Cross-implementation agreement

With the same verified inputs and policy, conforming verifiers should agree on the result and on the first failing check. Canonical representation and a defined check order make that agreement testable.

A disagreement under those conditions indicates a defect or an ambiguity in the protocol rules. Differences in policy or in the evidence supplied must be distinguished from an implementation disagreement.

Content sealing

Member content is sealed before upload. The host stores and serves encrypted files; eligible members receive the separate material needed to open them.

The audience key

Each creator has one audience keypair generated in a creator-controlled client. Member content is encrypted for that audience before it reaches the host.

The audience secret is shared with eligible members through individually encrypted deliveries. It is not supplied in plaintext to the host, directory or payment provider.

The same audience key survives a host change, so changing storage does not require re-encrypting every published item. Retaining that secret is a separate recovery responsibility; the prototype’s member-account backup does not establish recovery of the creator’s publishing secrets.

Delivering the key to a member

An entitled member receives the audience secret sealed to their own member identity for that creator. The delivery can be prepared from the member’s public identity; it does not require the creator to obtain the member’s secret or ask them to register a second identity.

• Issuance. The creator’s client derives the entitled-member set from the witnessed log, never from a host-supplied count, and posts a sealed copy for each entitled member that lacks one.
• Storage. Hosts store these per member and serve them ungated. Each is sealed to one member and is meaningless to anyone else, including the host.
• Timing. A sealed copy appears when a creator client next syncs. Clients must treat entitled but not yet delivered as a pending state, not an error.

Content classes

The class on a content item selects the recipient.

Public and profile. Served ungated, and readable by everyone including the host. To keep a single sealing path, these are sealed to a publicly derivable recipient rather than left unsealed — the format stays uniform and a blob is identified by the hash of its sealed bytes for every class.

• Profile — exactly one live item, whose plaintext is the display profile. Nothing verifies against profile bytes except the record’s commitment to them.
• Public — preview posts. Tier scopes should not list public classes; the gate never runs for them.

Everything else is member content: sealed to the audience key and served only through the gated route.

The gate

The host applies the membership check before serving member content. It must authenticate the presenter, bind the decision to the requested creator and content class, and use evidence acceptable under its freshness policy.

Encryption and serving policy provide different protections. Encryption prevents a party without the audience secret from opening stored files. The gate determines who may obtain those files through the service.

The current design uses one audience secret across a creator’s member content. Membership tiers are therefore separated by serving policy, not by independent encryption keys. A host that supplies a file outside that policy can defeat the tier restriction for a member who already has the shared secret.

Revoking is not un-sharing

A revoked or expired membership should fail the serving check. Revocation does not erase downloaded content or secrets already delivered.

The audience key is not rotated on revocation. A former member can continue to open files they already possess and may decrypt other files encrypted with the same key if they obtain them later.

The protection is therefore a rule for authorised serving, not cryptographic exclusion from every future publication. Any stronger separation would require a different key-distribution and rotation design.

What a host can still see

Sealing protects payloads, not patterns. A host knows each blob’s size, when it was uploaded, when it was fetched, and by which member.

Traffic analysis over that is available to it. Any description of this design as private without that sentence attached is overstating it.

Payments

Payment providers move the money. Glimpr carries signed evidence of payment so that membership rights can be checked independently of a provider’s dashboard.

The funds flow is member → payment provider → creator. The protocol holds no member balance, creator payout balance or payment instrument.

The provider list

The creator signs an ordered list of authorised providers. The first is preferred; the remainder define fallback order. A host has no authority to insert itself, reorder the list or treat a receipt from an unauthorised provider as valid payment evidence.

Replacing a provider changes the creator’s authorisation for subsequent payment processing. It does not transfer captured funds, disputes or payment mandates out of the previous provider.

From payment to membership

1. A charge is attempted through an authorised provider under the creator’s ordering and retry policy.
2. The provider confirms the outcome and signs a receipt. An unconfirmed charge remains pending.
3. The host validates the provider’s authority and the receipt’s relationship to the creator, member, offering and billing period.
4. The host issues or extends the membership within its delegation and records the event in the creator’s history.
5. The resulting evidence is made available with the history needed to verify it.

A receipt records what was actually paid, including amount and currency. Where a payment rail uses a different currency from the advertised offering, conversion and charging belong to the provider’s payment process; the receipt must not describe a payment that did not occur.

Payment confirmation, membership recording and witness acknowledgement can fail at different stages. Reliable operation requires reconciliation of uncertain outcomes and protection against duplicate charges. A retry is not evidence that the first attempt failed.

Failover

The reason for failure determines the next action.

Fallback requires another usable provider and a valid way to pay through it. A card authorisation is not automatically portable between providers. Seamless switching is an integration requirement, not something the ordering of provider keys alone guarantees.

The design includes an alternative payment rail through Mel for cases where conventional providers are unavailable. Live provider integrations and that fallback rail remain outside the prototype’s established deployment claims.

Renewal and refunds

A renewal combines fresh payment evidence with a membership extension for the same member and creator. The extension advances paid coverage and continues the existing history.

A refund has two effects in different systems: the provider returns money, and a revocation changes membership standing. Neither action performs the other. Once a verifier has accepted history containing the revocation, the membership reads as revoked. See Memberships.

What payment independence means

Providers retain authority over settlement, fees, disputes and funds they hold. A replacement may serve future payments; it cannot release money frozen by its predecessor.

Glimpr’s contribution is to keep the membership relationship and provider choice under creator authority. It cannot compel any provider to serve a creator or guarantee that an alternative exists.

Devices

A member’s account is held on their devices. It contains the authority to use their memberships and the information needed to recognise those relationships after recovery.

There is no central email-and-password account in the membership protocol. A payment provider may separately require billing or account information.

Separate identity per creator

The account derives a distinct membership identity for each creator. A credential for one creator therefore carries a different identifier from a credential for another.

Comparing those identifiers alone does not reveal a shared member. This does not conceal other correlations: payment information, reused contact details, network activity or a member’s own disclosures. The account root remains sensitive because control of it can expose or recreate the derived identities.

Adding a device

Pairing transfers account authority to another device through an encrypted exchange. The existing device approves the recipient, and the person pairing them compares the displayed confirmation before accepting the exchange.

The comparison binds approval to the intended device. An encrypted transfer to the wrong recipient is still a disclosure.

The transferred account material lets the new device recover the membership identities and holdings available to it. Further evidence or content may still need to be obtained from the relevant services. Pairing an account does not replicate every remotely stored file.

Device certificates and shared secrets

The design also defines certificates that grant a device a limited capability under a root identity. A limited certificate and a copy of account-wide secrets are different forms of authority.

Revoking a certificate can end the grant it describes. It cannot make a device forget a root secret already copied to it. The prototype’s device replication must therefore not be described as cryptographically safe removal of a compromised root-holding device.

Backup

A member backup encrypts account and subscription material under a recovery code held by the member. Restoration requires the usable backup data and its code.

Losing one device need not lose the account if another authorised device or a usable backup survives. Losing every usable copy loses the ability to act as the original membership identity. There is no central reset service that can recreate it from an email address.

Possession is the other side of recovery: someone who obtains sufficient backup material may gain the account’s authority. A backup is part of the account’s security boundary, not merely a list of subscriptions.

Creator recovery

Creators also depend on their signing authority, audience encryption secret, publishing state, history and content files. Restoring a member account does not establish that all of these have been restored.

Creator recovery must preserve both authority and data. A valid signing identity cannot decrypt content whose audience secret has been lost, and a valid history cannot recreate unavailable files.

Member-facing vocabulary

The member-facing vocabulary is account, devices and backup. The documentation explains the underlying authority where it matters; subscribing to a creator should not require knowing a cryptographic key format.

Privacy

The privacy model separates membership records, account secrets and payment instruments. Its purpose is to minimise what accumulates at the membership host while making the remaining exposure explicit.

What a host holds

Keeping unnecessary personal data out of the protocol reduces the material exposed by a host breach. A record format cannot prevent an operator from collecting additional request logs or running separate support and analytics systems. Deployment claims must cover those systems too.

Derive then discard

An audience import may begin with contact details so invitations can be delivered. The intended flow derives a value for duplicate detection and discards the original address from the membership-side import state.

A derived email value is not anonymity. Addresses are guessable, and resistance to matching depends on the derivation, salt handling and the information available to an observer. Source rosters, invitation delivery and retained copies remain separate sources of personal data.

Invitations are single-use claims. A successful claim establishes a new membership under Glimpr’s payment and issuance rules; it does not transport a previous service’s stored payment instrument or recurring authorisation.

No phone-home

The verification calculation performs no network operation and need not notify either the creator or the host when a membership is checked.

The application around that calculation may still communicate with services to obtain evidence, fetch content or record activity. Offline verification permits a private local decision; it does not certify the surrounding software as free of telemetry. See Verification.

What is not private

An honest account includes the other side.

• Traffic is visible to the host. Which member fetched which item, when, and how large it was. Sealing protects payloads, not patterns.
• The fact of a membership is known to the host. It accepted the write.
• Providers see payments. They receive the transaction information needed by their service and may require billing identity. Separating that information from membership hosting does not make it disappear.
• Public content is public, permanently, including to people who were never members.

The cost

Because member content is sealed, a host cannot inspect what it serves. That is the intended property, and it is also the limit: a host in this design cannot review member material.

Operators can still act on public material, reports and their service relationship with a creator. The protocol does not define a complete moderation or abuse-response policy, and encryption does not remove the need for one.

Misbehaviour

Signed contradictions can become portable evidence. Glimpr defines checks for an operator or witness attesting to incompatible versions of the same history position.

Conflicting heads

A host that rewrites history must publish a chain that disagrees with one it already attested. Because heads are signed, and witnesses retain what they co-signed, the result is two signed statements about the same position that cannot both be true.

A conviction is that pair: two heads for the same stream at the same position, with different chain hashes, both signatures verifying under the same signer.

Checking it requires trusting neither the party that produced it nor the party presenting it. Both signatures verify or they do not.

Conflicting roots

The same shape applies to the namespace: two directory roots at the same sequence number, committing to different namespace states, both signatures verifying under the same signer.

A directory that shows one answer to one party and a different answer to another has signed exactly that pair.

Both forms convict operators and witnesses alike. A witness that co-signs two conflicting heads has equivocated exactly as an operator would have, and the same evidence establishes it.

Detection requires plurality

Producing a conviction requires that two views actually get compared. That is what witnessing across parties is for, and why witnesses sharing an operator provide so little — a party consulting only itself will always find itself consistent.

Witnesses retain what they signed, so a conviction remains assemblable after the fact rather than only at the moment of divergence.

Bounded ambition

A conflicting-head proof establishes a specific act: one signer attested to different hashes for the same creator history at the same position. A conflicting-root proof establishes the analogous act for the directory.

These proofs do not establish every kind of misconduct. Going offline, refusing a request or withholding a file does not necessarily produce two contradictory signed statements. An isolated client may also see only one branch of a fork until views are compared.

The value is precision. Where the contradictory statements are available, another party can check them without access to the operator’s database or trust in the person reporting the conflict.

Removing a misbehaving host

The creator can use the ordinary host-switch procedure to close the outgoing host’s authority and authorise a replacement. Witness-held evidence supports the close, while available history and content support the transfer.

Clients with acceptable current evidence reject writes outside the closed delegation. A successful move still depends on the recovery materials being available; the proof of misconduct does not supply them.

What conviction does not do

It produces a checkable fact, not a penalty. The proof check does not itself recover funds, delete data or administer a penalty. Rejecting a key from future delegations or witness policy requires that the evidence reach the parties enforcing those decisions.

What the evidence supports is a decision made by people — members declining to trust a host, creators declining to hire it, operators declining to work with it. The contribution is that the decision can rest on something checkable rather than on an accusation.

The honest boundary

All of the above assumes the parties holding the evidence are independent of the party the evidence concerns.

Where witnesses share an operator with the host, or where the anchor a client pins comes from the party being checked, the mechanism is present and the guarantee is not. That gap belongs to a deployment, not to a design, and no amount of correct design closes it. See Limits.

Limits

A design can only offer what its participants can establish. Cryptographic mechanisms, independent operation and available data are different requirements. None substitutes for the others.

Independence is a deployment property

A directory proof establishes consistency with a particular root. A witness signature establishes that a particular witness attested to a checkpoint. Their value as independent checks depends on who controls the root, the witness and the information the client accepts.

• A directory anchored only to its own operator’s reference demonstrates internal consistency.
• Several witnesses controlled by one operator do not provide independent oversight of that operator.
• Conflicting views become evidence only when they can be obtained and compared.

Glimpr’s intended deployment requires an independently established anchor and independent witnesses. These are properties to demonstrate in operation, not consequences of assigning separate names to services.

Current stage

The implementation is private and remains a prototype. Controlled exercises cover membership history, content sealing, verification, payment-provider fallback and switching hosts. They do not establish the same properties under arbitrary production failures.

The pilot combines service roles under one operator and uses a directory reference without an independent deployed anchor. An independent anchor and at least two independent witness operators remain necessary for the intended independence claims. They would not, by themselves, complete the security or availability argument.

Live payment integrations, durable recovery, exposed-service authentication, interrupted-operation handling and complete creator recovery still require production validation. The documentation makes no claim that these are ready for real funds or public operation.

Boundaries of the design

Claims that need backing

Glimpr does not describe the prototype as trustless or promise that a creator cannot be deplatformed. Clients, hosts, directories, witnesses, networks and providers can fail or refuse service. The design aims to preserve creator authority and make important claims independently checkable.

It does not create an audience or guarantee a business. It changes the control of a relationship that a creator still has to build.