NAOMS Devlog

Building a sovereign, local-first memory & identity system โ€” in the open, honestly.

Honoring ATProto: An Account You Can Actually Carry

The protocol behind Bluesky made leaving a host a right, not a favor โ€” what it taught us, and where sovereignty led us elsewhere

Vision Fellow Travelers free May 25, 2026ยท6 min readยทmeta
TL;DR Every social network promises you can leave and take your stuff; almost none keep it. A tribute to the AT Protocol behind Bluesky, which made it real โ€” you can move your whole account to a new host even if the old one would rather you didn't โ€” and an honest account of what we took from it and where we went our own way.

The promise that every social network makes and almost none keeps is: you can leave whenever you want, and take your stuff with you. The AT Protocol is one of the very few that made that promise real โ€” real enough that you can move your entire account to a new host even if the old host would rather you didn't. This piece is written in its honor.

What they do well

The AT Protocol โ€” ATProto, the system underneath Bluesky โ€” is a federated protocol for large-scale social applications, and by early 2026 it carries tens of millions of users and a thousand-plus third-party apps, with standardization work underway at the internet's standards bodies. The name means "Authenticated Transfer," and that is the heart of it: every piece of your data is cryptographically signed inside a Merkle tree, so it can be verified no matter where it is hosted or who is passing it along.

That signing is what makes the headline feature possible โ€” genuine portability. Your whole account lives in a single signed repository: your posts, your follows, your profile, all of it, structured as content-addressed records under one root hash. You can export that entire repository as one archive file and import it somewhere else, and because it is signed, its authenticity survives the move. This is not "we promise to let you leave." It is adversarial portability: the design separates your everyday signing key from a rotation key, and the rotation key โ€” which you hold, not your host โ€” is what updates where your identity points. So you can move to a new host even if your old host is uncooperative or offline. Leaving is a protocol operation, not a favor.

The identity model is a clean two-layer affair: a human-readable handle that can change, resolving to a stable, permanent identifier that doesn't, which in turn points to your keys and your current host. And the moderation design is the most architecturally novel part: composable labeling. Anyone can run a "labeler" โ€” a service that publishes signed, typed assertions about content โ€” and users subscribe to the labelers they trust and combine their outputs. Moderation is decoupled from hosting and from identity, so hosting your data does not grant the power to silence you, and no single authority owns the verdict. There is even a clean philosophical frame underneath it all: separate "speech" (the permissive layer that stores data) from "reach" (the layer that aggregates and curates it). It is dual-licensed under the most permissive terms, built largely in TypeScript, and uses one small database per account. This is serious, generous, large-scale engineering.

Where to find it

If you want to see what data portability looks like when it is built in from the start rather than bolted on under pressure, read how an account moves hosts.

What we took

The deepest thing we took from ATProto is a standard for what "portable" has to mean: you can leave even if the host would rather you didn't.

The rotation-key idea is the crux. By separating the key you use every day from the key that controls where your identity points, ATProto made migration a right rather than a courtesy โ€” the host cannot hold your identity hostage, because the host never held the key that matters. We took that separation seriously. In our own identity model, the ability to retire and replace your everyday key, and to relocate without anyone's permission, is wired in from the start. ATProto proved at tens-of-millions of users that this is not just theoretically nice; it works, at scale, in adversarial conditions.

We took the signed-repository discipline, too โ€” the conviction that your data should be content-addressed and signed so its authenticity is carried in the bytes themselves rather than asserted by whatever server happens to be holding them. A record made in one place and moved to another keeps its proof of authorship โ€” exactly the property our own signed history depends on, and one ATProto demonstrates in production.

And we took real inspiration from composable moderation. The pattern โ€” governance verdicts as signed, typed, subscribable assertions, decoupled from who hosts you and combined by your own choice rather than imposed โ€” maps beautifully onto a consent-and-trust-driven model, where the relationships you actually have shape whose judgments you weight. ATProto's labelers showed that "moderation" need not mean "a single authority with a delete button." It can mean a marketplace of signed opinions you assemble for yourself. We carry that idea forward.

What we did differently (and why)

Here we want to be precise and generous, because where we diverge from ATProto is not where ATProto fell short โ€” it is where ATProto answered a different question. ATProto is, by design, a system for large-scale public social networking. We are building for personal data sovereignty. Those goals point in genuinely different directions, and ATProto is admirably explicit about its own choices.

ATProto is public by default; we are private by default. Every record in an ATProto repository is public โ€” your posts, and even your blocks and follows, are signed plaintext that anyone running the right infrastructure can read. Private state is a thin layer off to the side, not part of the authenticated data structure. For an open social network that is coherent and even admirable in its transparency. For us it is the wrong default, so we inverted it: your data is encrypted such that only you can read it, and who-relates-to-whom is protected rather than broadcast. This isn't a fix for ATProto; it's a different threat model, chosen on purpose.

ATProto is server-hosted; we are local-first. ATProto chose server-based federation over peer-to-peer or local-first, explicitly, for reliability and convenience โ€” your data is portable, but it lives on a host, and if that host is down, the network can't reach it. We chose the other trade: your data lives on your device first and works offline, because sovereignty, for us, means it keeps working when no server will. ATProto's model is "portable but hosted"; ours is "sovereign and local." Both are honest answers; they answer different questions.

ATProto's identity leans on a shared directory; ours is self-certifying. The large majority of ATProto identities resolve through a single, auditable directory service. Auditable is genuinely good, and far better than opaque โ€” but it is still one shared point of trust. Our identity is designed to resolve without depending on any central resolution service, so that no operator, however well-behaved, sits in the path of proving who you are.

ATProto broadcasts everything to everyone who asks; we route by trust. ATProto's relays stream every public update to every subscriber โ€” wonderfully efficient for a public network, but it means anyone running that infrastructure sees all public activity. Because our data is private and ours, our discovery is the opposite shape: queries travel along trust relationships and computation comes to the data rather than the data being broadcast out. Again โ€” not a flaw in ATProto, but the natural consequence of building for sovereignty rather than for reach.

The honest summary: ATProto handed us a definition and a set of proven patterns. The definition โ€” that "portable" must mean "you can leave even over the host's objection," guaranteed by a key the host never holds โ€” is now part of our own bones. The patterns โ€” signed content-addressed repositories, and moderation as composable subscribable assertions โ€” taught us how to do things we needed to do. Where we went elsewhere, it was because sovereignty asked a different question than public social networking does, and ATProto was scrupulously clear about which question it was answering. That clarity is exactly what let us choose well.

To the Bluesky and AT Protocol teams: thank you for making an account you can actually carry, and for proving that portability can be a right rather than a promise. We took the part about never being able to be held hostage, and we built it into a sovereignty you keep on your own machine.


Written by AI agents from real project logs; owned and edited by Mujo.

โ† more in Vision   home โœฆ   all โ†’