Concepts

1. Identity is not an account

Most hosted applications make an account identifier meaningful because a particular service says it is. A profile URL, username, database row, and authentication session are all anchored to the operator that currently hosts them.

did:sizuq moves the root of control outside that account database. The identifier is derived from a canonical genesis payload containing public control material. Applications can associate their own accounts, profiles, permissions, or local records with that DID, but they do not create the underlying cryptographic identity by doing so.

2. Current state comes from verified history

A did:sizuq resolver does not simply download a current profile-shaped document and trust it. It retrieves the creation record and subsequent operations, then derives current state by validating the sequence from the beginning.

create (sequence 0)
   ↓ hash + signature
update (sequence 1)
   ↓ hash + signature
update / recover (sequence 2)
   ↓
current DID state

Every accepted successor references the digest of the previous record. A resolver checks the genesis-derived DID, signatures, sequence numbers, and hash links. This turns the operation log into evidence from which state can be recomputed rather than a mutable row that a directory may rewrite invisibly.

The log is still distributed through network infrastructure. A directory can withhold data or present conflicting valid branches, so availability and complete visibility are not magically trustless. The protocol’s response is to make state transitions independently verifiable and to fail explicitly when history is conflicting.

3. Rotation and recovery are different powers

Version 0.1 separates ordinary control from exceptional recovery. Rotation keys authorize normal updates such as replacing rotation keys, verification methods, or services. Recovery keys authorize recovery, replacement of recovery material, and deactivation.

This separation lets an implementation keep everyday signing capability relatively available while protecting recovery material more aggressively. A compromised rotation key is serious, but it does not by itself grant the ability to replace recovery keys or permanently deactivate the identity.

4. Services are locations, not identity

The derived DID state can contain service entries. A service tells software where a capability is currently reachable. For resource dereferencing, sq: looks for a service of type SizuqResourceService.

A service endpoint can change through a valid identity update without changing the DID itself. That is the central portability boundary: the endpoint answers “where now?”, while the DID answers “under whose control?”

Endpoints remain untrusted network locations. A successful HTTPS response is not proof that the server controls the identity root. Clients retain the original identifier, validate identity state independently, and apply ordinary network protections when contacting the endpoint.

5. Resources keep their names when hosting moves

sq: adds a durable resource namespace beneath a did:sizuq identity. The root is the method-specific identifier from the DID; the path is interpreted within that identity’s resource namespace.

did:sizuq:z75o3YCSEJnivnVp76pexncihFSzBTaRJ7jdCtaXURwtM
           │
           └── identity root

sq:z75o3YCSEJnivnVp76pexncihFSzBTaRJ7jdCtaXURwtM/post/123
   └──────────────── identity root ────────────────┘ └ resource path

If the controller changes the current resource service from one host to another, the canonical sq: URI does not need to change. The identifier names the resource relative to the portable identity; DNS and HTTPS remain delivery mechanisms.

The generic scheme does not prescribe the meaning of every path. It reserves a small set of ecosystem segments and preserves unknown segments so applications can define resource profiles without changing the generic URI grammar.

6. What must be trusted — and what can be verified

sizuq protocol narrows some trust relationships; it does not eliminate all of them. Cryptographic rules let a resolver verify that an observed history is internally valid and authorized by the relevant keys. They cannot guarantee that a network server has shown every record that exists or that the human behind an identifier is who an application claims.

7. What the protocol does not define

The protocol is intentionally below the level of a complete social network. It defines identity control and resource addressing primitives, not one universal product policy.

• Feeds and ranking: applications decide how content is discovered and ordered.
• Moderation: applications and services choose moderation policy, labeling, blocking, and enforcement models.
• Storage: the protocol does not require one database, object store, or hosting provider.
• Human names: handles and display names can be layered above the cryptographic identifier.
• Business model: subscriptions, advertising, donations, or other economics are outside the identity and URI specifications.

This boundary is what allows independent applications to share portable identifiers without having to share the same interface, social rules, or infrastructure stack.

Next: Architecture → · Normative detail: did:sizuq specification and sq: specification.