Most online identity is a story about servers: you register, a database row is created, a company remembers you, and if they forget you — or decide they'd rather not — you are gone. Nostr told a different story. You generate a keypair, and you exist. No registration, no account to be deleted, no permission to ask. This piece is written in its honor.

What they do well

Nostr — Notes and Other Stuff Transmitted by Relays — is a minimalist, open protocol for decentralized messaging in which your identity simply is a cryptographic keypair. There is no sign-up, no username to claim, no server that owns your account. You make a key, and that public key is who you are, everywhere, forever.

The power is in the radical simplicity. The entire base layer fits in one idea: the event. Every piece of data in Nostr — a note, a profile, a contact list, a private message, a marketplace listing — is one object type, a small JSON record signed by its author's private key. An event has an identifier (a hash of its contents), the author's public key, a timestamp, an integer "kind" that says what type it is, some tags, the content, and a signature. That is the whole data model. Everything richer — social graphs, encrypted chats, long-form articles — is built by defining new kinds of that same signed event. One envelope, endless contents.

The transport is just as spare. Relays are simple WebSocket servers that accept events, store them, and serve them back. You publish your events to several relays; clients read from several relays; and because every event is signed, a relay can store and serve your data but can never forge it. The signature is the integrity guarantee, so the infrastructure underneath can be dumb and replaceable. A clever convention even lets people advertise which few relays they prefer to read and write from, so relay lists stay small and discovery works without a central directory. There are thoughtful patterns layered on top — a way to map a key to a human-readable name at a domain you control, a remote-signing design that keeps the real key in a separate "bunker" while a throwaway client key does the day-to-day talking. It is a genuinely engaged developer community, public-domain at the protocol level, and the largest deployed system where a raw public key is identity with nothing in between. That is a real achievement, and an instructive one.

Where to find it

• Nostr: nostr.com · the protocol definitions at github.com/nostr-protocol/nips
• Libraries worth reading: nostr-tools (low-level) and NDK (higher-level)

If you want to feel how little a protocol can be and still do a lot, read the base specification. It is shockingly short.

What we took

The deepest thing we took from Nostr is a design value: one canonical signed envelope beats a proliferation of message types.

Nostr's "everything is an event" architecture is a master class in protocol minimalism. Instead of inventing a new wire format every time a new feature appears, it defines a new kind of the same signed object. The discipline is contagious, and we caught it. Our own system leans hard on a single idea: a signed record appended to a chain, where new capabilities are new kinds of record rather than new transports. When we say "there is one canonical signed thing, and features are varieties of it," we are speaking Nostr's language, and we are better for having learned it.

We also took Nostr's relay-as-lightweight-witness insight. A relay's job — accept a signed thing, timestamp it, serve it back — is the simplest possible "publish and query" primitive, and it suggests a use that needs no cooperation from the relay at all: publishing a tiny anchor — a fingerprint of your latest state — somewhere public, so that if two parties ever disagree about your history, there is independent evidence to point to. A dumb public surface used purely as a tamper-evident witness is a pattern we carry forward.

And Nostr's remote-signing shape confirmed our own instincts: keep the real key in a separate, guarded place, and let the everyday client talk to it rather than hold it. Nostr's "bunker" and our own separation of the part that holds your keys from the part that merely acts for you are the same idea — one we extend with explicit consent checks before any signature is given.

What we did differently (and why)

Here we must be careful and generous, because the places we diverge from Nostr are mostly places Nostr's own designers and community name openly as hard problems — not flaws hidden, but edges acknowledged.

A key must be able to rotate, and in Nostr it cannot. This is Nostr's most serious limitation, and the community knows it: your public key is your identity forever, so if that key is ever compromised, your identity is stolen with no clean recovery path. Several proposals exist; none is yet standard. We treated this as a non-negotiable requirement rather than a feature to defer. Our identity model is built so that a compromised everyday key can be retired and replaced without losing who you are — the right to rotate is wired in from the start. Nostr did us the great service of demonstrating, at scale and in public, exactly what life is like without rotation. We took that lesson and built the opposite default.

Our data is encrypted by default; Nostr's events are public by default. In Nostr, an event is plaintext for the whole network unless you explicitly encrypt it, and even then the metadata — who talks to whom, and when — is visible to relays. For a public social protocol that is a coherent choice. For a system whose entire purpose is personal data sovereignty it is the wrong default, so we inverted it: your memories are encrypted such that only you can read them, and protecting the metadata of who-relates-to-whom is part of the design rather than an afterthought. This is not a correction of Nostr; it is a different threat model answered honestly.

We give each being its own chain, rather than relying on free-floating timestamps. Because Nostr events are stateless and self-asserted, their timestamps can claim any moment — which means someone with a stolen key can forge events into the past. The protocol accepts this as the price of statelessness. We could not, because verifiable ordering of your own history is foundational for us. So instead of loose, individually-timestamped events, each being keeps an ordered chain where each entry follows from the last, and time is something the chain proves rather than merely claims. That structural choice closes the backdating door that statelessness leaves open.

We do not depend on volunteer relay infrastructure for the things that must not fail. Nostr's community is admirably honest that most relays cannot cover their costs and that a large fraction are offline at any time — the natural consequence of "anyone can run a relay." We learn from the model without leaning our critical identity operations on infrastructure no one is obliged to keep running. We may use a relay-like surface as a witness, where availability is a bonus and not a dependency; we do not make it load-bearing.

The honest summary: Nostr gave us a discipline and a set of vivid lessons. The discipline — one signed envelope, features as kinds of it — shaped our core. The lessons — what happens without rotation, what public-by-default costs, what backdating allows, what volunteer infrastructure can and can't promise — were taught to us, generously and in the open, by a community unafraid to name its own hard edges. We diverged at every one of those edges, and we could only do so clearly because Nostr mapped them first.

To the Nostr protocol and the people building on it: thank you for proving that a public key can be a whole identity, and for being so honest about where that simplicity reaches its limits. Both halves made it into our thinking.

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