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.