verifying the trust chain#

since the last devlog (firehose benchmarks), zat picked up a bunch of correctness work — interop test suites, signature fixes, a full MST implementation — and now ties it all together: given a handle, verify everything about a repo from scratch.

what happened since last time#

correctness first (0.1.8)#

we joined the atproto interop test suite. this is bluesky's official cross-implementation test vectors — the same fixtures that the TypeScript SDK, Go SDK, and others validate against. zat now passes all of them:

• syntax: 6 types (TID, DID, Handle, NSID, RecordKey, AT-URI), valid + invalid vectors
• crypto: 6 signature verification vectors (P-256 and secp256k1)
• MST: 9 key height vectors, 13 common prefix vectors, 6 commit proof fixtures

this also surfaced two bugs:

• NSID parser wasn't rejecting TLDs starting with a digit (1.0.0.127.record should fail)
• AT-URI parser wasn't validating its components (authority, collection, rkey) — it was just splitting on /

and a spec compliance issue: ECDSA signature verification wasn't rejecting high-S values. atproto requires low-S normalization (BIP-62 style), and we were accepting both. fixed with explicit half-order checks in verifyP256 and verifySecp256k1.

MST and crypto signing (0.1.9)#

the merkle search tree is the core data structure of an atproto repo. each key's tree layer is derived from the leading zero bits of SHA-256(key), and nodes are serialized with prefix compression. mst.Mst supports put, get, delete, and rootCid (serialize → hash → CID).

alongside that: ECDSA signing (signSecp256k1, signP256 with RFC 6979 deterministic nonces), did:key construction, and multibase encoding. these round out the crypto layer — zat can now both sign and verify.

code organization (0.2.0)#

22 files in a flat src/internal/ was getting unwieldy. we reorganized into domain subdirectories following bluesky's own boundaries (from the TypeScript SDK):

internal/
  syntax/     — tid, did, handle, nsid, rkey, at_uri
  crypto/     — jwt, multibase, multicodec
  identity/   — did_document, did_resolver, handle_resolver
  repo/       — cbor, car, mst, repo_verifier
  xrpc/       — transport, xrpc, json
  streaming/  — firehose, jetstream, sync
  testing/    — interop_tests

the groupings aren't arbitrary. the TypeScript SDK has syntax, crypto, identity, repo, and xrpc as distinct packages — syntax is pure parsing with zero deps, identity handles network resolution, crypto is P-256 + K-256, and repo contains the MST, CAR, and CBOR together (CBOR isn't a standalone package — it lives with the types that need it).

the repo verifier#

verifyRepo(allocator, "pfrazee.com") exercises the entire trust chain in one call:

handle → DID → DID document → signing key
                                    ↓
repo CAR → commit → signature ← verified against key
                ↓
         MST root CID → walk nodes → rebuild tree → CID match

the pipeline:

1. resolve handle — HTTP well-known or DNS TXT → DID string
2. resolve DID — did:plc via plc.directory, did:web via .well-known/did.json → DID document
3. extract signing key — find the #atproto verification method, multibase decode, multicodec parse → key type + raw bytes
4. extract PDS endpoint — find the #atproto_pds service
5. fetch repo — HTTP GET {pds}/xrpc/com.atproto.sync.getRepo?did={did} → raw CAR bytes
6. parse CAR — extract roots and blocks
7. find + decode commit — the root block is the signed commit (DAG-CBOR map with did, version, rev, data, sig)
8. verify signature — strip sig from the commit map, re-encode to DAG-CBOR (deterministic key ordering), verify with the signing key
9. walk MST — starting from the commit's data CID, recursively decode MST nodes with prefix decompression, collect all (key, value_cid) pairs
10. rebuild MST — insert every record into a fresh mst.Mst, compute root CID, compare against the commit's data CID

if any step fails, you know exactly where the trust chain breaks.

what this exercises#

every major module in zat participates:

it's the first feature that crosses all the domain boundaries — identity, crypto, repo, and network all working together.

the integration tests#

two accounts, two PDS backends:

• zzstoatzz.io — self-hosted PDS (pds.zzstoatzz.io), ~12k records. verifies the self-hosting path works.
• pfrazee.com — bluesky CTO, hosted on bsky.network, ~192k records. verifies against the canonical infrastructure.

both use the graceful-catch pattern: if the network isn't available (CI, offline), the test prints a message and passes. when the network is there, it runs the full chain and asserts on the DID and record count.

what's next#

this is the first "full pipeline" feature — it validates that the primitives compose correctly end to end. from here, the natural next steps are incremental: repo diffing (compare two commits), record-level verification (check a specific record's inclusion proof), or sync protocol support.

but following the pattern: we ship when something real needs it, not before.