sizuq protocol

1. Protocol layers

The architecture is easier to reason about as four layers. Only the first three are defined by the current protocol family; the application layer consumes them.

┌─────────────────────────────────────────────┐
│ Application layer                           │
│ profiles · posts · feeds · moderation · UI │
├─────────────────────────────────────────────┤
│ Resource layer — sq:                        │
│ durable resource name → current service     │
├─────────────────────────────────────────────┤
│ Identity layer — did:sizuq                  │
│ signed operation history → current DID state│
├─────────────────────────────────────────────┤
│ Distribution / transport                    │
│ directories · mirrors · HTTPS · caches      │
└─────────────────────────────────────────────┘

This layering prevents a delivery mechanism from acquiring more meaning than it should. HTTPS is used to move operation records and resource representations. It does not become the canonical identity or resource name merely because it is the current transport.

2. Component roles

Role	Responsibility	Does not imply
Controller	Holds the private key material that can authorize identity operations.	Hosting a directory or resource server.
Writer	Constructs canonical operations, signs them, and submits them to a directory.	That the writing application owns the DID.
Directory	Accepts valid operation records, preserves accepted history, and exposes ordered operations through the read profile.	Authority to forge valid state transitions.
Mirror	Replicates operation records so resolvers can retrieve or compare history independently.	Permission to alter the signed records it mirrors.
Resolver	Validates genesis, signatures, sequence, hash links, and state transitions, then emits current DID state.	Trusting a directory-provided materialized DID Document.
Resource service	Serves resources addressed beneath an identity root.	Ownership of the canonical `sq:` identifier.
Gateway	Optionally translates access for environments without native protocol support.	Becoming the canonical identifier or verification authority.
Application	Uses resolved identity and resources to provide a user-facing product.	One required feed, moderation, storage, or economic model.

3. Identity write path

Creation and later state changes originate from controller-held keys. The writer is responsible for producing exactly the bytes and data model that interoperable resolvers will later verify.

Controller keys
      │
      ▼
Writer
  1. build complete next-state payload
  2. JCS-canonicalize signing input
  3. sign with authorized key
      │
      ▼
Directory
  4. validate before acceptance
  5. append accepted record
      │
      ├────────► Mirror A
      └────────► Mirror B

For sequence 0, the DID itself is derived from the canonical genesis payload. For later operations, the envelope references the digest of the immediately preceding accepted record. An update uses a current rotation key; recovery and deactivation require a current recovery key.

A directory can apply operational controls to submissions, but it cannot make an invalid signature valid. That distinction lets write availability remain an infrastructure concern while authority remains cryptographic.

4. Identity resolution path

Resolution is a verification pipeline, not a lookup of a trusted current row.

did:sizuq:z...
      │
      ▼
Configured directory / mirror
      │ operations[]
      ▼
Resolver
  ├─ validate identifier syntax
  ├─ recompute genesis digest
  ├─ validate creation proof
  ├─ validate every successor signature
  ├─ validate sequence + previous hash
  ├─ apply state transition rules
  └─ detect deactivation / conflicts
      │
      ▼
Derived DID Document + resolution metadata

A resolver may retrieve from one endpoint, compare several mirrors, or cache previously verified state. Those are deployment choices. The invariant is that a resolver does not substitute transport trust for protocol verification.

Network failure and notFound are distinct conditions. Likewise, a valid but conflicting history is not silently resolved by arbitrary branch choice; the method defines an explicit conflictingHistory failure.

5. Resource dereferencing path

An sq: request composes the identity and resource layers. The stable identifier stays unchanged even when the network destination changes.

sq:z.../post/123
      │
      ├─ parse root + path
      ▼
did:sizuq:z...
      │
      ├─ resolve + verify operation history
      ▼
current DID state
      │
      ├─ select SizuqResourceService
      ▼
current service endpoint
      │
      ├─ GET /post/123
      ▼
resource representation

Canonical identity throughout: sq:z.../post/123

The resource service is discovered only after the identity state has been resolved. Redirects or gateway URLs may alter how bytes are delivered, but they do not rewrite the canonical sq: URI.

Applications still need content-level policy. A cryptographically valid identity can intentionally publish malicious content, and a controller can intentionally point at a hostile service. Identity verification answers control questions; it is not a general safety verdict.

6. Deployment topologies

6.1 Integrated application

A single product can operate its own directory, resolver, resource service, and gateway. This is the simplest way to ship an initial implementation. The application should still store and expose protocol records in conforming formats so other resolvers or mirrors can independently consume them.

6.2 Independent resolver or mirror

A third party can mirror signed operation records and run a resolver without hosting the corresponding social application. This creates an independent verification path and can improve resilience against omission or rollback from one directory view.

6.3 Multiple applications, shared identity

Different applications can recognize the same DID while maintaining separate account databases, interfaces, moderation systems, and application-specific resources. The identity layer creates continuity; it does not merge those products into one service.

6.4 Migrated resource service

A controller can validly update the SizuqResourceService endpoint. New dereferences discover the new endpoint through current DID state while existing sq: identifiers remain stable.

7. Trust boundaries

Private keys: security-critical authority. Compromise has protocol-level consequences.
Directories: untrusted for cryptographic authority, but important for availability, completeness, append ordering, and write admission.
Mirrors: useful independent views; still verify the records they serve.
Resolvers: part of the trusted computing base of the consuming application. Incorrect canonicalization or transition logic can accept invalid state.
Service endpoints: attacker-controllable network destinations. Server-side dereferencers need SSRF, redirect, TLS, and response-size defenses.
Gateways: compatibility infrastructure, not an identity root. They may observe requests and can misrepresent content if clients do not verify relevant identity claims.

The architecture therefore aims for verifiable control with replaceable infrastructure, rather than the stronger and usually unrealistic claim that no infrastructure needs to be trusted for anything.

Next: Implementer Guide → · Mental model: Concepts.