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
| Item | Held | Note |
|---|---|---|
| Member email address | Not required | Excluded from the intended membership record; imports and delivery systems need separate handling |
| Member name, address | Not required | Payment or support services may separately collect them |
| Card or payment instrument | No | Never seen by the protocol |
| Member private keys | No | Held on member devices |
| Member content | Sealed | Stored and served; not openable by the host |
| Public and profile content | Readable | The shop window, deliberately |
| Log entries and heads | Yes | The history it exists to keep |
| Sealed audience material | Yes | Each sealed to one member; meaningless to the host |
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.