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
| Boundary | Consequence |
|---|---|
| Data must remain available | Authority to leave a host cannot reconstruct missing history or content. Recovery requires usable copies and the secrets that make them accessible. |
| Revocation cannot retract shared secrets | Downloaded content remains with its recipient. Without audience-key rotation, other files encrypted with the same key may also remain decryptable if obtained later. |
| Tiers share an audience secret | The host’s serving policy enforces tier access; encryption does not independently separate those tiers. |
| Freshness depends on observed evidence | An offline verifier cannot discover events newer than the material it receives. A consistent older view may still be unacceptable under current policy. |
| Metadata remains visible | Sealing hides payloads from parties without the secret, while requests, timing, sizes and payment relationships can remain observable. |
| Recovery material carries authority | Lost devices and backups can mean a lost identity. Copied account secrets cannot be revoked merely by removing a device from a list. |
| Payment providers retain control of funds they hold | Fallback may support future charges but cannot release a frozen payout or guarantee another provider will accept the creator. |
| Names require governance | Proof of name control does not determine real-world identity, entitlement to a name or resolution of a dispute. |
| Encrypted content limits host inspection | Storage operators need abuse-handling policies that do not assume routine access to member-content plaintext. |
| Evidence is not remediation | A signed contradiction can establish misconduct without restoring service, repairing history or compensating an affected member. |
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.