poztter.com

poztter.com / your authorities

Your authorities.

Your master zone delegates authority over each sub-zone to a set of delegation keys. Each delegation key carries two values, evaluated independently: grant (add or modify entries) and deny (revoke or remove entries).

the five sub-zones you might delegate

ZoneWhat it controlsTypical delegation keys
IdentityBindings of your handles on providers (Twitter, GitHub, work email).2 personal devices; deny ≥ grant.
EmailInbox definitions and the encryption keys senders use.Same set as Identity, often.
FeedPublic feed anchors and chain checkpoints.Posting key per feed; revocation key.
AuthTrust groups for authenticating to services.Master + recovery keys are usually delegated here.
ServiceWhich servers host your stuff and on which ports.Whoever runs your infrastructure.

configuring grant and deny

The simplest sound configuration uses two delegation keys — usually two devices — and gives each grant=50, deny=100. This means:

Variations: a "primary device + backup hardware key" with the hardware key grant=100, deny=100 means the hardware key can do anything alone. That's fine if you trust it absolutely; less fine if you'd rather any single key compromise be survivable.

A · BALANCED two devices, equal weight Phone grant 50 · deny 100 Laptop grant 50 · deny 100 REVOKE EITHER ALONE GRANT BOTH AGREE SURVIVES · one device theft thief can revoke (annoying) but cannot grant a new one B · PRIMARY-WEIGHTED hardware key dominates Hardware token grant 100 · deny 100 Backup device grant 50 · deny 100 REVOKE EITHER ALONE GRANT HW KEY ALONE RISK · hw key compromise attacker with hw key alone can add new credentials
fig 01 · pattern A makes every new credential a deliberate two-key act. Pattern B trades that for the convenience of one trusted key — at the cost of higher impact if that key is compromised.

how sub-zone updates flow

  1. You draft a change to a sub-zone (add an inbox, attest a new identity, rotate a feed posting key).
  2. Delegation keys sign the change.
  3. If the relevant threshold (grant or deny) is met, the change is finalized and submitted.
  4. Your authoritative server validates the chain — master ➜ authority ➜ zone — and accepts the update.

don't forget the Service Zone

Several zones reference the Service Zone by hash — your inboxes point to mail servers there, your feeds point to feed servers there, your Auth Zone points to a revocation service there. If you don't define a Service Zone, you're effectively saying "use defaults" — which works for read access via public caches, but limits your ability to host your own infrastructure.

For the underlying spec, see sub-zone delegation and the individual zone pages at poztter.org/components.