Open protocol · Editor’s draft
Identity that moves.
Links that endure.
sizuq protocol is an experimental, implementation-oriented layer for portable identity and durable resource addressing across independent social applications.
The protocol separates a person’s cryptographic identity from the application currently serving it. A hosted service can disappear, move, or be replaced without becoming the root of identity itself.
Protocol model
Two identifiers, two responsibilities.
did:sizuq establishes who controls an identity. sq: addresses resources beneath that identity. Keeping those roles separate makes it possible to move hosting without redefining the identity or every link attached to it.
did:sizuq
A self-certifying DID method with signed, hash-chained operations for creation, resolution, key rotation, recovery, and deactivation.
Read method specification →Resource layersq:
A compact URI scheme that binds a durable resource path to a portable identity root instead of to a particular host name.
Read URI specification →Resolution
Resolve, verify, then dereference.
The protocol does not ask clients to trust a gateway merely because it answered a request. Identity state is derived from signed operations; resource delivery happens only after that identity root has been resolved and verified.
Read sq:<root>/post/<id> and preserve the canonical identifier.
Resolve did:sizuq:<root> from a conforming directory or mirror.
Validate the genesis digest, signatures, sequence, and hash chain.
Use the current declared resource service without treating the host as the identity.
What this enables
Continuity across applications.
The initial scope is deliberately narrow, but the primitives are intended to support several common portability problems without defining a social network’s feed, ranking model, or business rules.
A controller can update service endpoints while keeping the same identity root and resource identifiers.
Profiles, posts, collections, and application-defined resource types can retain stable identifiers even when their delivery location changes.
Signed operation history can be mirrored and checked by more than one resolver, reducing dependence on a single hosted directory.
Design boundaries
Infrastructure, not a social contract.
sizuq protocol defines identity control, state transitions, resolution, and durable addressing. Applications remain free to choose their own moderation, discovery, ranking, presentation, storage, and economic models.
Rotation and recovery keys are independent from any one app session, account database, or domain name.
State changes are signed and chained so a resolver can audit how the current document was derived.
Identifiers do not directly encode names, email addresses, demographics, or other human-readable personal data.
Documentation
Understand it before reading every MUST.
The specifications remain the source of normative behavior. The documentation layer gives implementers a path from the mental model to system architecture, code, and conformance testing without duplicating the specifications line by line.
Concepts
Identity versus account, verified history, rotation and recovery, service endpoints, durable resources, and trust boundaries.
Build the mental model →Guide 02Architecture
Controllers, writers, directories, mirrors, resolvers, resource services, gateways, applications, and their request flows.
Follow the architecture →Guide 03Implementer Guide
A staged implementation path from deterministic cryptographic primitives through resolution, writing, directories, and sq:.
Conformance
Profiles, deterministic vectors, negative cases, URI fixtures, state-machine tests, and interoperable reporting.
Verify behavior →Specification status
Published early for implementation and review.
Version 0.1 is an Editor’s Draft. The method and URI scheme are documented publicly so implementations can test the same syntax, cryptographic rules, failure behavior, and resolution model before the protocol is treated as stable.
Status
See the current relationship to the W3C DID Extensions registry and the IANA URI Schemes registry, including what registration does — and does not — imply.
View standards status →