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.
| Kind | Purpose | Signed by |
|---|---|---|
| Creator record | Routing and policy a name resolves to | Creator root |
| Host delegation | The grant that lets a host sign | Creator root |
| Epoch close | Fixes the last entry of an epoch | Outgoing host, or creator root on a forced close |
| Epoch open | Starts the next epoch at a named host | Creator root |
| Tier schedule | What is on offer, at what price | Creator root |
| Entitlement | A membership | Delegated host |
| Payment receipt | Evidence a payment happened | Payment provider |
| Content item | A publication, supersession or removal | Delegated host |
| Manifest head | The current end of the content chain | Delegated host |
| Share grant | A member authorising one verifier | The bound member key |
| Invite | Single-use migration of an existing audience | Creator root, or an invite-scoped device key |
| Device certificate | Certifies a device under a root identity | Root identity key |
| Provenance | Optional third-party attestation | Each attester individually |
| Log head | A signed commitment to history so far | Epoch host, co-signed by witnesses |
| Directory root | A signed commitment to namespace state | Directory operator, co-signed by witnesses |
| Revocation | Ends the validity of a subject | The authority over that subject |
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.