PurpleSky GitHub

Experimental protocol proposal

ATProto over
Farcaster.

Farcaster identity and persistence, exposed as ordinary ATProto. No bridge required.

One logical PDS, many replaceable nodes. PurpleSky distributes an ATProto service across workers backed by shared Farcaster state. Your repository belongs to the shared substrate.

Read the architecture GitHub
View protocol proposal
Fig. 01 / One logical PDS
Replaceable nodes. Shared state. One ATProto repository. An ETH or Farcaster-authorized request enters the PurpleSky logical PDS through node B. The shared Farcaster layer orders the mutation. Deterministic projection and a protected signer produce one standard signed commit, C4. Nodes A and C reconstruct and serve that same canonical state. Relays, AppViews, and clients see one PDS and one repository lineage per DID. This is a proposed sequence, not a live network. ETH / Farcaster identity PurpleSky One logical PDS Node A Node B Node C serves shared C4 accepts write serves shared C4 Farcaster Shared ordered state · mutation #18422 Deterministic projection + protected signer One signed ATProto repo Shared commit C4 · same DID · same lineage Relay AppView Client Standard APIs at the logical PDS endpoint
Write at B → order → sign once → serve the same state at A + C.

Illustrative sequence. All nodes serve the same published head; labels are not live network status.

The invariant

Existing ATProto implementations should not need to understand Farcaster.

01 / The idea

One protocol.
Another foundation.

Farcaster as infrastructure. ATProto as the interface.

PurpleSky proposes a distributed ATProto PDS implementation backed by the Farcaster protocol. It explores what happens when one decentralized protocol consumes another as infrastructure.

This is protocol composition, not a service that copies Farcaster posts into a second social graph. PurpleSky would publish native ATProto records from its backing state. Clients, relays, and AppViews see an ordinary PDS.

One social graph, multiple storage substrates.

Fig. 02 / Protocol composition
Conceptual views of one substrate. Shared native objects and the additional views remain research questions.

02 / Architecture

One logical PDS.
Many replaceable nodes.

The network is the backend.
ATProto remains the interface.

Fig. 03 / Three distinct layersProposed architecture
did:plc:…PDS service endpoint
01 / Service identity · What ATProto sees

PurpleSky logical PDS

Stable endpoint · OAuth / XRPC / repo / sync / blob APIs

↔ ordinary clients, relays, AppViews, and other PDSs
02 / Node layerInterchangeable access points

Node A

Authorize · project · serve

Node B

Authorize · project · serve

Node C

Authorize · project · serve

Local databases, indexes, MSTs, and CAR caches are reconstructable materialized state.

03 / Canonical replicated substrate

Farcaster

Shared accepted mutations, ordering, and finality for deterministic repo transitions

Nodes submit mutations to shared ordering and reconstruct the same published repository state. The logical service routes requests; no node permanently owns an account. Ordinary Farcaster nodes do not themselves become ATProto servers.
Service identity

A stable logical PDS endpoint in the DID document. Routing between workers does not change the DID or its advertised PDS.

Replaceable nodes

Stateless or mostly materialized gateways. A healthy, authorized, caught-up node should authenticate the user, accept writes, reconstruct the repo, and serve standard APIs.

Shared substrate

Canonical persistence and ordering come from the chosen network. Mutation admission, finality, retention, and recovery still require proof.

03 / Distributed state

Any node. Same repository.

The network is the PDS.

Precisely: PurpleSky presents a single logical PDS to ATProto while distributing its implementation across many nodes backed by shared Farcaster state.

Hosted PDS deployments can assign accounts to particular backends or shards. PurpleSky’s proposed authority is the shared substrate. A node is neither the identity authority nor the durable home of a repository.

The distributed invariantOne authoritative repository lineage per DID.

Users migrate onto the PurpleSky logical PDS. Switching PurpleSky workers is routing or failover, not account migration.

Concurrent requests. A single history.

If A receives “follow Bob” while B receives “post Hello,” both submit to the same ordering layer. Neither publishes an independently chosen repo head.

Node Afollow Bob
Node Bpost Hello
Farcaster ordering / finality
#9001 follow#9002 post

Deterministic repo transitions + normal ATProto signatures

Illustrative order and revisions, not a new commit hash-chain format. The transition/commit policy must produce the same published head on every node.
Concurrency, finality, and failover: what still needs to be specified?

Define ordering within each DID, commit boundaries, stable record keys, monotonic revisions, idempotency keys, retry behavior, and conflict/precondition handling. An accepted request must not become two commits when retried at another worker.

Nodes publish only after the agreed ordering/finality condition and signing step. A lagging or partitioned worker must catch up, forward, wait, or fail the request; it cannot claim to serve the current head or create an independent canonical fork.

The logical service also needs shared session/revocation semantics, consistent read watermarks, and resumable firehose cursors across node changes. Ordering mutations alone does not solve these service guarantees.

Canonical commit metadata and signed artifacts must be recoverable, so two workers serving the same revision return the same commit CID. Signer failover needs fencing to prevent competing publishers. These are open implementation problems.

04 / Compatibility

Why this can work.

The PDS abstraction separates a repository’s public contract from its storage engine.

[ 01 ]

Normal identities

Start with did:plc. The DID document identifies the PDS and repo verification key; handles resolve through the usual mechanisms.

DID specification
[ 02 ]

Normal repositories

Standard records, a Merkle Search Tree, and a signed commit. Ordering and finality do not replace the account’s ATProto repo signature.

Repository specification
[ 03 ]

Normal synchronization

Serve CAR exports and valid repository events, including resumable streams and identity/account changes. No Farcaster-aware consumer is required.

Sync specification
What the network verifies
DID + verification keysigned repo commitMSTapp.bsky.* records

The compatibility claim is a design constraint to test. A full PDS also needs standard client auth, discovery, account lifecycle, blob handling, and operational behavior. No modification to ATProto itself is proposed.

05 / Identity and signing

A stable identity.
Distinct kinds of authority.

A handle names the user. A DID identifies the account. Login authority, repo signing, and DID rotation have different jobs.

Fig. 04 / Public ATProto identity
deanpierce.netHuman-readable handledid:plc:…Stable ATProto identity
PDS servicePurpleSkyOne logical endpoint
Repo verification keyPublic keyVerifies signed commits
Illustrative identity. The handle resolves to the DID; the DID document advertises the PDS and operational repo verification key.
Fig. 05 / User authorization
  1. Farcaster / ETHAuthenticates and authorizes the user
  2. PurpleSky accountShared authority and revocation rules
  3. Operational ATProto signerSigns authorized canonical repo commits
The Ethereum wallet does not directly sign every ATProto record. A normal repo key signs the repository commit.

Start with a normal did:plc, including an existing DID brought by migration. Prove the FID ↔ DID binding; retain standard ATProto client auth at the service boundary. No did:farcaster is proposed.

DID/PLC rotation authority is separate from the operational repo key. It authorizes identity updates such as changing the PDS endpoint or verification key. Farcaster/ETH-assisted recovery and rotation, wallet-only accounts, and passkeys remain research.

Many gateways do not mean many copies of a hot key.

Distributed repo signing is an open implementation problem. An initial proof can use one protected signer service, with explicit custody and access controls.

  1. PurpleSky nodesA / B / C
  2. Shared orderingConfirmed mutation
  3. Initial signing designProtected signer
  4. Public outputValid ATProto commit
The signer must authorize the ordered state transition, enforce one canonical publisher per account, and make the signed result recoverable by other nodes. A single signer concentrates availability and trust; failover still needs fencing.
Signing research: threshold, delegation, and hardware protection

Longer-term candidates include threshold or distributed signing, delegated short-lived signing authority, secure/HSM-backed signing, and other compatible mechanisms.

These are research options, not established ATProto integrations. Delegation cannot assume consumers understand a new certificate chain or signature format.

Every externally visible repo commit must be a normal valid ATProto signed commit. Any signing arrangement must satisfy the accepted algorithm, key, encoding, and DID verification requirements.

ATProto cryptography

06 / Account migration

Move your hosting.
Keep your identity.

The migration is from an ordinary PDS to the PurpleSky logical PDS. Moving between PurpleSky nodes should not be a migration at all.

Before / Ordinary PDSdeanpierce.netdid:plc:…Current PDSFor example, a Bluesky-hosted account
After / PurpleSkydeanpierce.netdid:plc:…PurpleSky logical PDSDistributed nodes + shared Farcaster state
Same custom handle. Same DID. A different PDS service endpoint. This illustrates the proposed migration path; no account migration has been performed here.

A custom domain handle can continue resolving to the same DID. The DID’s PDS service endpoint changes to PurpleSky; the operational repo verification key can change as part of an authorized migration.

The user need not extract the old PDS’s private signing key. Import the repository and blobs, authorize the identity update using the applicable DID/PLC authority, then coordinate activation and deactivation so only one PDS is authoritative.

Preserving data and the exit path

Keeping the DID does not by itself copy content. Import and verify the repository, transfer blobs and relevant private preferences, and establish a shared bootstrap checkpoint from which every PurpleSky node can reconstruct. Retain custom-domain control and verify the handle binding.

Migration back to an ordinary PDS should retain the DID and repository too. Import/export, signing-key rotation, account cutover, and recovery when the old provider is unavailable remain prototype work.

ATProto account migration

07 / Native participation

Different storage.
Same protocol graph.

Follow, mention, reply. PurpleSky users and ordinary ATProto users should interact through the same records and references.

Can two fundamentally different storage architectures participate transparently in the same ATProto social graph?

08 / Integration depth

Three ways in.

Start with interoperability.
Explore how deep the composition can go.

01Baseline

Repository
block storage

Create ordinary ATProto repositories first; explore storing their blocks through the Farcaster network.

  1. ATProto records
  2. MST / CAR / blocks
  3. Farcaster storage

Simplest conceptual adapter and closest to conventional storage. Still needs a viable storage mechanism.

02Preferred research direction

Canonical
event log

Use Farcaster as shared mutation infrastructure; deterministically project accepted state into a standard ATProto repository.

  1. Social mutations
  2. Farcaster
  3. Deterministic projection
  4. ATProto repository

The replicated substrate is canonical. ATProto is its interoperable representation.

03Longer-term question

Shared native
protocol objects

Could one user-signed social operation be meaningful to both protocols directly?

Signed social operation
FarcasterATProto

Do not start here. Identity, signing, repository, and message semantics differ today.

Inside Level 2: what would be persisted?

Conceptual projection operations, not existing Farcaster message types: 

create app.bsky.feed.post/abc
update app.bsky.actor.profile/self
create app.bsky.graph.follow/xyz
delete app.bsky.feed.post/old

The event envelope would need record content, stable keys, authorization, ordering, timestamps, and versioned projection rules. The adapter must first establish how the chosen network accepts and retains these operations.

Identical records can reproduce the MST root. Identical signed commits additionally require fixed commit metadata and a signing strategy or retained signed commit bytes. Replay alone does not recover private signing keys.

Pruning, deletion, snapshots, media availability, and migration need explicit policies before this can be a durable source of truth.

09 / The distributed proof

Write at A.
Rebuild at B. Verify anywhere.

All milestones proposed
  1. Authorize one user through an FID / Ethereum identity.
  2. Bind one ordinary did:plc.
  3. Submit a post through PurpleSky node A.
  4. Persist and order its mutation through Farcaster.
  5. Start node B with empty local projection state.
  6. Have B reconstruct the current repo from shared state.
  7. Have B serve a valid com.atproto.sync.getRepo.
  8. Verify the result with an unmodified ATProto consumer.
  9. Submit a second mutation through B; have A serve the resulting head on the same canonical lineage.
The thesis to prove
Account state belongs to PurpleSky’s shared substrate, not to a PurpleSky machine.

If an unmodified ATProto relay/AppView can consume and verify a PurpleSky repository, the abstraction is working. The distributed proof additionally requires another node to recover and continue that same repository.

Begin by validating the substrate and a protected signer. Then cover profile, post, follow, updates/deletes, concurrent writes, retries, restart/replay, and com.atproto.sync.subscribeRepos resumption across nodes. Compare record CIDs, MST roots, revisions, and signed commit CIDs at the same publication watermark. Public AppView ingestion still depends on discovery and service policies.

10 / Open research

The interesting questions
are still open.

These are design decisions to investigate, not capabilities already delivered.

  1. What should be canonical: Farcaster mutations or ATProto blocks?
  2. How should an FID ↔ DID binding be represented and proven?
  3. How can protected or distributed signing preserve one canonical commit without copying hot keys to every node?
  4. Can repository reconstruction from Farcaster be fully deterministic?
  5. How should finality, concurrent writes, retries, read watermarks, and cross-node firehose resumption work?
  1. How much Farcaster-native data fits existing Lexicons directly?
  2. How can a new node reconstruct state after failures, pruning, or signer loss?
  3. Can an account migrate to an ordinary PDS while retaining its DID and repository?
  4. Could the same substrate expose both Farcaster-native and ATProto-native views?
  5. Which Farcaster message types, storage limits, and retention policy can support this?

Experimental / Proposal stage

A proposal, with room
for better questions.

The Rust workspace now includes node preflight, offline repository reconstruction, a localhost console, and Farcaster-backed password sessions. Live network reconstruction and a working stock-client experience remain unproved.

Protocol review, criticism, and small reproducible experiments are welcome.

Review the proposal Read the technical overview Research implementation planned.
Not production-ready.