Identity Without Landlords
Why I built SigFed, and what Bluesky's algorithm actually optimises for
"Every online identity you own is a tenancy. Somebody else holds the deeds."
The Itch
I've spent the last few months designing and building SigFed, a federation protocol for cryptographic identity. Specs, schemas, test vectors, a Rust resolver and reference server, the lot. The full explainer, with a plain-English track and a deep-dive track, lives at sigfed.0xbrewentropy.xyz. This post is the part that doesn't fit in a spec: why.
The itch is simple. Every identity I hold online is rented. My Mastodon handle exists at the pleasure of a server admin. My Reddit account exists at the pleasure of a trust-and-safety queue. Even the accounts I "own" are one forgotten renewal, one acquisition, or one moderation false-positive away from evaporating, and everything I built on them evaporates too.
The fix isn't a better landlord. It's ownership. An identity should be a keypair on your device, personas derived from it for each community you join, and a network that can verify all of it without any single operator being able to take it away. That's SigFed in one sentence.
SigFed in Ninety Seconds
- One root key, on your device. An Ed25519 keypair that never leaves you. No account creation, no email, no password.
- Masks, not usernames. Per-community personas derived deterministically from the root via HKDF. All of them provably yours, none of them linkable to each other by outsiders. Your cooking-forum self and your support-group self never have to meet.
- Prove the fact, not the file. Attestations support selective disclosure: show "over 18: yes" without showing a birthday.
- No directory, no operator. Records live in a Kademlia-style DHT under domain-separated hashes of your own key. There is no registry company to subpoena, acquire, or rate-limit you out of existence.
- Loss and theft are survivable. Shamir shares for recovery, and KERI-style pre-rotation for compromise: you publish a hash of your next key in advance, and only a rotation dual-signed by that committed successor can take over. A thief who steals your current key cannot burn your identity; the committed successor dominates.
Worked examples and two live demos (a DHT slot calculator and a commitment checker) are on the site. Show your working, and all that.
The Competition, Honestly Assessed
ActivityPub: identity as a subdomain of someone's hobby
I like the Fediverse. I post there. But @you@instance.social is not your identity; it's a row in a Postgres database on a machine paid for by a volunteer's Patreon. When the instance dies, defederates, or the admin has a bad month, your identity dies with it. Account migration exists and requires the cooperation of the very server you're trying to leave. That's not portability, that's a reference letter from your landlord.
Nostr: correct diagnosis, no aftercare
Nostr got the core instinct right: identity is a keypair, servers are dumb relays. Respect. But it stops there. One npub for everything, so every post, every zap, every 3am take is welded to a single public identity forever. And key management is a shrug: no rotation, no recovery, no revocation story worth the name. Lose the key, you're gone. Leak the key, you're someone else now. SigFed treats "humans lose keys" as a protocol requirement, not a user error.
Bluesky: the interesting one
AT Protocol deserves the longest look, because it's the most sophisticated of the lot and its marketing is the most seductive. Two claims do the heavy lifting: "your identity is portable" and "you choose your algorithm". Both are true the way a brochure is true.
Identity. A Bluesky identity is a did:plc, a mutable operation log resolved through plc.directory, a service operated by Bluesky PBC. Yes, there are rotation keys, and a 72-hour window where a higher-priority key can rewrite a hostile operation, which is genuinely good design. But follow the trust chain to its root and you find a single hosted directory. Your identity is portable the way a car is portable when one company owns the only road. If the directory is down, coerced, or simply decides not to serve your operations, your "self-sovereign" identifier resolves to nothing. SigFed's equivalent lookup is a hash of your own public key in a DHT that anyone can run a node for. There is no plc.directory because there is no plc and no directory.
The Algorithm, or: Choose Any Road, We Own the Tarmac
Bluesky's headline feature is "algorithmic choice": feeds are just services, anyone can build one, you subscribe to the ranking you like. As a rebuke to the engagement-maximising single feed, it's real progress, and credit where due.
Now look at the plumbing. A custom feed generator doesn't run on your device over your data. It's a server that consumes the firehose: the full public event stream produced by a relay, indexed by an AppView. Relays are expensive to operate at network scale, so in practice nearly everyone consumes the one run by Bluesky PBC, and the default Discover feed, the default AppView, and the default moderation labels are all first-party. "Choose your algorithm" cashes out as "choose which third-party query runs over infrastructure one company operates and can shape". Choice of lens, not choice of light source.
The part that actually bothers me is quieter, and it's structural: the algorithm's food supply is your privacy. For any feed generator to rank your world, your likes, follows, blocks, and posts must be public, machine-readable records in a globally crawlable repository. That's not a bug in AT Protocol; it's the load-bearing wall. The protocol makes total behavioural visibility a precondition of its flagship feature. Every like you've ever made is a public API call away, joined to one DID, forever. I wrote a whole post about what joins do to "harmless" data (Twenty-Four Numbers). The AT Protocol firehose is that post, productised.
SigFed's answer is boring on purpose: there is no algorithm, because identity is not a feed. SigFed is the layer underneath. Communities and apps can build whatever ranking they like on top, but the protocol never requires your social graph to be public, never welds your contexts together, and gives the observer of persona A mathematically nothing about persona B. An algorithm can only monetise what the identity layer exposes. So expose less.
Score Card
| Protocol | Identity root | Who can take it away | Recovery | What the network sees |
|---|---|---|---|---|
| ActivityPub | Row on someone's server | Admin, registrar, hosting bill | Migration, if the old server cooperates | Whole graph, per instance |
| Nostr | Raw keypair | Nobody, including you after you lose it | None | Everything, one npub, forever |
| AT Protocol | did:plc op log in a hosted directory | Directory operator at the root; 72h key recovery window helps | Rotation keys, recovery window | All likes, follows, blocks: public and crawlable by design |
| SigFed | Ed25519 key on your device | Nobody; committed successor beats a key thief | Shamir shares + pre-rotation | Per-community personas, unlinkable, selective disclosure |
Closing
I'm not claiming SigFed replaces any of these networks. It's an identity layer, not a timeline; the point is that the next Mastodon, the next Bluesky, and the next thing we haven't imagined yet shouldn't each mint their own tenancy agreement. They should verify keys you already hold.
It's Draft 0.1. The specs, JSON schemas, test vectors, interop harness, and Rust reference implementations are open, and I would genuinely rather you broke it now than politely admired it. Start at sigfed.0xbrewentropy.xyz, pick your track, and bring a crowbar.
Own your keys. Everything else is renting.