poztter.org
poztter.org / FAQ
Frequently asked questions.
Questions and contrasts. If you're trying to decide whether POZ is for you, whether to implement against the spec, or just what the acronym stands for — start here.
basics
What does POZ stand for?
Portable Ownership Zone. Portable because the record travels with you; Ownership because you hold it, not a provider; Zone because the record is structured as a master zone with delegated sub-zones for identity, email, feeds, authentication, and services.
Is POZ a product or a protocol?
A protocol — actually a small family. A binary file format, a key
management and survivorship model, a network protocol, and a set of
zone specifications. The Poztter project provides a reference
implementation in C++ (libpoz plus CLI, server, mail,
and bridge tools). Anyone can implement against the specs.
Why three websites?
They serve different audiences. The Poztter Organization (poztter.org) is this site — education on POZ. The Poztter Community (poztter.com) hosts and manages POZ records for users. The Poztter Network (poztter.net) runs POZ network services and tracks operational status.
Who is POZ for?
Two audiences with overlapping needs. Organizations that want a single, trustable identity carried across every web presence they have — websites, emails, social posts. And individuals who want their identity to belong to them rather than to a platform that issued it.
identity, ownership, and deplatforming
What happens if a social media company suspends my account?
The handle is gone on that platform, but the rest of your record isn't affected. Your other identities, your email zone, your contacts' trust in you — all of it survives. You can re-establish a presence elsewhere, and everyone who trusted you still trusts you because your POZ record is the same record. The handle was metadata; the record is the person.
Does POZ make deplatforming impossible?
It makes deplatforming much weaker as a tool. A platform can still remove an account — POZ doesn't take that power away. What POZ removes is the platform's ability to take your identity with the account. The trust people placed in your POZ record stays where they placed it: with you.
How does POZ "make email scams impossible"?
POZ doesn't stop someone from sending you a deceptive email. It makes the question "is this really from who it claims to be?" answerable. An email signed by a real POZ identity chains back to attestations from providers you trust (the sender's domain registrar, their social attestations, and so on). An email pretending to be from a bank but not chained to that bank's POZ record doesn't pass the check. The verification happens on your device, not at the mail server.
Can I switch email providers without losing my identity?
Yes — that's a primary motivating example. With POZ, your contacts know you by your POZ record. When you add a new mail host's attestation to your record and remove the old one, your contacts' software updates automatically. No "I'm changing my email" notice, no lost mail.
comparisons
How is POZ different from PGP?
PGP is a signature and encryption format with a "web of trust" social model. POZ is an identity record format with a survivorship- based key model and provider attestations. PGP keys can sign arbitrary documents; POZ records describe who you are across providers. They could coexist (PGP can sign a POZ record), but they solve different problems.
How is POZ different from a blockchain DID?
Blockchain DIDs anchor identity in global consensus — a chain everyone agrees on, maintained by miners or validators. POZ has no global chain. Each POZ record is its own little signed history, distributed by ordinary servers. No token, no consensus mechanism, no transaction fee, and no requirement for any third party to participate in your record's existence.
How is POZ different from WebAuthn / Passkeys?
Passkeys are an authentication mechanism — they prove you control a key when logging into one site. They're great at that, and POZ has nothing to replace them with. POZ is about portable identity across services, not authentication to a single service. POZ's Auth Zone can hold passkeys as keys in a trust group; the two are complementary.
How is POZ different from DNS-based identity (Keybase, Bluesky)?
Bluesky uses DIDs anchored to DNS or PLC. Keybase used proofs posted to social profiles. Both bind a handle to a key. POZ does that and bundles the key management (survivorship), the recovery model, the cross-provider identity list, the email / auth / feed / service zones, and the network protocol — so identity isn't just a name-key binding, it's a portable record.
technical choices
Why SHA-3 instead of SHA-2?
SHA-3 has a fundamentally different construction (Keccak sponge) than SHA-2 (Merkle–Damgård). Using SHA-3 gives defense in depth: a flaw in SHA-2 wouldn't affect POZ, and vice versa. SHA-3 is also immune to length-extension attacks by construction.
Why Ed25519 instead of ECDSA?
Ed25519 is deterministic (no per-signature randomness), faster to verify, and has a more careful specification. ECDSA's signing process depends on a fresh random number per signature; getting that wrong (or having a bad RNG) leaks the private key. Ed25519 just doesn't have that footgun.
Is POZ post-quantum safe?
Not yet. Ed25519 and Curve25519 are both vulnerable to a
sufficiently capable quantum computer. The format leaves room —
keys carry a key_type field, and future versions can
add post-quantum algorithms (Dilithium, SPHINCS+, etc.) as
additional types. Existing records would migrate by adding new
keys to their master zone and rotating delegations over time.
Why three network ports instead of one?
Each port enforces a specific contract. 7074 is
plaintext (no privacy promise), 7075 is Noise NK
(privacy + server authentication), 7076 is Noise NK
plus submission semantics. Separate ports mean a server's
encryption requirement is visible at the firewall layer, and a
misconfiguration can't accidentally serve submissions on a public
lookup port.
keys, recovery, and survivability
What happens if I lose all my keys?
If you configured a recovery survivorship group (e.g., trusted friends, family members, or an agency), they can together authorize a new master zone for you, preserving your identity. If you configured only a single key with no recovery path, the record becomes permanently unmodifiable. That's why POZ encourages at least one recovery group in any multi-key setup — survivability is a feature, not an afterthought.
What if a recovery key holder turns against me?
A single recovery key holder normally can't act alone — the threshold rule requires their value plus others to clear 100. The common patterns (e.g., three recovery keys at 40/40/40) require all three to coordinate, preventing minority collusion. And because the master zone delegates with separate grant and deny thresholds, even a hostile actor with a key normally can't add identities you didn't ask for.
How is my private key protected?
The Private Key Map section (0x8002) is optional.
When present, private keys should be encrypted at rest. The spec
recommends Argon2id for key derivation and AES-256-GCM for
encryption, though the exact scheme is implementation-defined.
Records distributed to third parties should never include the
Private Key Map.
Why grant and deny separately?
Because the cost of an incorrect grant (an attacker takes over) and the cost of an incorrect deny (a legitimate operation is delayed) are very different. POZ lets you set them independently — typical configurations make locking down unilateral (any single trusted device can revoke) and opening up consensual (multiple devices must agree to add). Read more in cryptography & revocation.
operations
Do I need to run my own server?
No. You only need to run a server if you want to be your own authority — attesting identities for other people, hosting POZ submissions, etc. As an ordinary user, you hold a POZ record (a file), keep it on your device, and submit updates to authorities you've chosen. Public caches will host read-only copies so others can find it.
Can a POZ server modify my record?
No. POZ records are cryptographically self-verifying. A compromised server can refuse to serve your data, serve stale data, or pretend you don't exist. It cannot forge your data. Modifying a record without invalidating the chain requires the private keys, which the server doesn't have. This is the whole point of trusting the data instead of the provider.
What's the proof-of-work mechanism for?
Volumetric DoS protection. Servers can require clients to solve a small SHA-3 puzzle before processing a request. Difficulty is adaptive — trivial at low load, scales up automatically under attack. The fairness property is that a small server gets the same protection as a big one, because the cost is on the client.
What if my network blocks the POZ ports?
The HTTPS well-known fallback (/.well-known/poz)
exists for exactly this case — corporate proxies, restrictive
firewalls, shared hosting. It depends on the existing PKI (the
domain's TLS cert authenticates the response), so it's
lower-confidence than POZ-native paths, but it keeps POZ useful in
environments where new ports can't be opened.
the project
Who runs Poztter?
The project was started and is led by Allen Green. The reference implementation, specs, and these websites are open source under the Apache 2.0 license. See the GitHub repository for the code and the RFC drafts.
How can I contribute?
The fastest way is to read the RFC drafts and open issues for things that are unclear, missing, or wrong. Implementation contributions, alternative-language implementations, and test vectors are all welcome.
Is this stable enough to build on?
The core specification and network protocol are at "implementable" stability — labeled Internet-Draft and intended for standards-track submission, but not finalized. The reference implementation is pre-1.0. If you're building production systems against POZ today, expect breaking changes — and expect to be in the conversation about what those changes are.