Pds: federation support (PLC registration, MST/signed commits/CAR, com.atproto.sync + firehose, handle resolution) #40

New issue

Open

opened 2026-06-11 23:16:17 +00:00 by Grandiras · 0 comments

Grandiras commented

2026-06-11 23:16:17 +00:00

Owner

ATProtoNet.Pds (0.4.0) can host accounts and serve repo CRUD, but a PDS built on it cannot federate with the Atmosphere network. The gaps, in dependency order:

Real identities — CreateAccountAsync generates a placeholder did:plc:<random13> without registering it (no PLC genesis operation, no signed op chain, no PDS_DID_PLC_URL equivalent). Nothing on the network can resolve these DIDs. did:web support + well-known endpoints (/.well-known/did.json, /.well-known/atproto-did per handle host) would be a useful intermediate step.
Real repo structure — records are stored as opaque values with pseudo-CIDs ("bafyrei" + hex(sha256)[..32] — not a valid CID). Federation requires DAG-CBOR records in a Merkle Search Tree with signed commits (the SDK already has DAG-CBOR/CAR/MST consumer code in the firehose/repo modules that could be reused for the producer side).
Sync surface — com.atproto.sync.getRepo / getLatestCommit / listRepos / subscribeRepos (firehose with sequenced events), plus requestCrawl toward relays. Without these, relays can't crawl the PDS.
Handle resolution — serving /.well-known/atproto-did for handle subdomains.

Context: Updraft initially shipped a PDS on ATProtoNet.Pds (see issues #36–#39), but switched to the official ghcr.io/bluesky-social/pds container when federation became a requirement — the gaps above are SDK-level, not app-level. Happy to be an early adopter again once ATProtoNet.Pds can federate; the invite-store work (#36) and EF stores (#38) remain relevant for that future.

`ATProtoNet.Pds` (0.4.0) can host accounts and serve repo CRUD, but a PDS built on it cannot **federate** with the Atmosphere network. The gaps, in dependency order: 1. **Real identities** — `CreateAccountAsync` generates a placeholder `did:plc:<random13>` without registering it (no PLC genesis operation, no signed op chain, no `PDS_DID_PLC_URL` equivalent). Nothing on the network can resolve these DIDs. did:web support + well-known endpoints (`/.well-known/did.json`, `/.well-known/atproto-did` per handle host) would be a useful intermediate step. 2. **Real repo structure** — records are stored as opaque values with pseudo-CIDs (`"bafyrei" + hex(sha256)[..32]` — not a valid CID). Federation requires DAG-CBOR records in a Merkle Search Tree with signed commits (the SDK already has DAG-CBOR/CAR/MST *consumer* code in the firehose/repo modules that could be reused for the producer side). 3. **Sync surface** — `com.atproto.sync.getRepo` / `getLatestCommit` / `listRepos` / `subscribeRepos` (firehose with sequenced events), plus `requestCrawl` toward relays. Without these, relays can't crawl the PDS. 4. **Handle resolution** — serving `/.well-known/atproto-did` for handle subdomains. Context: Updraft initially shipped a PDS on `ATProtoNet.Pds` (see issues #36–#39), but switched to the official `ghcr.io/bluesky-social/pds` container when federation became a requirement — the gaps above are SDK-level, not app-level. Happy to be an early adopter again once `ATProtoNet.Pds` can federate; the invite-store work (#36) and EF stores (#38) remain relevant for that future.