Nostr: the protocol that shifts control from users to platforms

Nostr is a protocol for social networks that has no company behind it and no central server. It was born from a simple observation: social networks have a structural problem, and it cannot be solved by adding features.

The problem is this: your account is not yours. The content is yours, but the ability to publish it depends on a company that can close the account, censor the content, sell the data or simply go under. No setting in the menus changes the structure.

Nostr shifts control. But — and this is the part that almost all articles about Nostr omit — the control it shifts is over your data, not over your identity. The privacy it promises is real, and it has precise limits that should be stated before you use it.

What it is, in one sentence

Every user has a key pair. You sign events with the private key, publish them to several independent relays, and sign them in such a way that nobody can pretend to be you.

Three words to define, and the others derive from these.

Keys. Like RSA, a public and private pair. The public one identifies the user, the private one proves it is you. The difference from a platform is that the private key never leaves your device: no administrator sees it, because they do not have it.

Events. The only object that exists in Nostr. Literally: the NIP-01 specification says that there exists a single type of object, event. This is the most elegant and most important part of the protocol.

{
  "id":        <32 byte, sha256 dei dati serializzati, hex>,
  "pubkey":    <32 byte, chiave pubblica dell'autore, hex>,
  "created_at": <timestamp unix in secondi>,
  "kind":      <intero da 0 a 65535>,
  "tags":      [ [<stringa>...], ... ],
  "content":   <stringa arbitraria>,
  "sig":       <64 byte, firma Schnorr secp256k1, hex>
}

Seven fields. There is no username field, there is no email field, there is no progressive numeric id_utente. Identity is the public key.

Relays. They are the servers. But they are not "the server": they are independent and interchangeable relays, and you connect to as many as you want, in parallel. The protocol prescribes that the client keeps one WebSocket connection per relay and uses it for all subscriptions.

The point is that if one relay closes, the others carry on. That is not resilience, it is structure: there is no single point of failure because there is no single point.

Event kinds, which is where the simplicity lies

The kind values are integers, and the ranges have a meaning that the specification defines precisely. It is the part that makes the protocol extensible without having to be designed in advance.

The ranges are not a decoration: they are a storage space reduction mechanism. In a normal social network you cannot write "this is my bio" without creating a new record; in Nostr you publish a kind 0 and the relay throws away the previous one. The result is that an active user takes up little space, and the relay does not have to grow endlessly.

The most used type is kind 1, the text note, defined in NIP-10 rather than in NIP-01. Kind 0 is the only one defined in the base specification: it contains a JSON with name, about and picture.

Tags are arrays of strings and are the referencing mechanism. There are three standard ones: e points to another event, p to another user, a to a replaceable event. All the letters are indexable, and only the first value of each tag is.

["REQ", <id_sovscrizione>,
  { "kinds": [1], "authors": ["<pubkey>"], "limit": 20 }]

This is a subscription request: send me that user's notes, at most 20, and keep me updated. The client communicates with the relay in only three messages: EVENT to publish, REQ to ask and subscribe, CLOSE to close.

Why it matters, and where it is wrong

So far it all looks better. The honest point is another one, and I raise it before the benefits because without this the article is propaganda.

Nostr does not hide who you are. The public key is public by definition, and every event you publish is signed. Anyone who reads one of your events can know which account wrote it, in a verifiable and permanent way.

So Nostr is not anonymity. If you publish what you think, and then you make a contact who knows where you live, your router's IP address links the connection to that pubkey of yours. You do not need special software: you need the habit of correlating.

The privacy Nostr offers is of a different kind, and it is real nonetheless:

• no account can be closed by the provider, because there is no provider that owns it;

• no centralised profiling, because nobody has the complete picture: each relay sees one piece, and the pieces belong to different users;

• deletion is your decision, with a kind 5 that asks the relays for removal. It is not automatic and it is not guaranteed: it is a request;

• your content is yours, regardless of whether there is someone hosting it.

And there is a property that platforms cannot replicate by constitution: portability. Your pubkey and your events are yours everywhere. No platform can ask you to start from scratch because you changed service. It is the same property that applies to the Git repository, and for the same reason.

The three ways it can be compromised

I write them explicitly because they are the real weak point, and anyone who sells them to you as a protocol "that cannot violate privacy" is ignoring them.

1. The relay that sees everything. A single relay that is faithful and has a lot of traffic sees all the events that pass through it, with the IPs of the connected clients. It is the worst case, and it is the reason why using a single relay is a mistake. It is fine to know three or four trusted ones, not just one.

2. The client model. Here privacy depends on how well the client you use is written. The scheme is private-by-design, but a client can do things that make it less private: saving locally everything it sees, sending telemetry, showing advertising. Privacy is a property of the implementation, not of the protocol. It is the most important point of all.

3. The damage is permanent. A deleted event remains in the history of all the relays that received it. There is no rollback, there is no transaction, there is no "we are restoring the backup": there is an append-only log replicated across independent servers. This is the price of immutability, and it is the reason why you do not write on Nostr the same thing you would not write on a Telegram channel.

A bit of history

The context. Nostr was born from the frustration of a Brazilian developer known only as fiatjaf, who in 2020 describes the problem clearly: social networks are centred on accounts that can be revoked, and anyone can be banned without appeal. The proposal was not to have users: only keys and events.

The precedent existed and had been tried: ActivityPub, the protocol behind Mastodon, and Secure Scuttlebutt. Both solved the problem of censorship, but fiatjaf considered them wrong for technical and cultural reasons. ActivityPub is complex to federate and leaves control to individual server administrators; Secure Scuttlebutt is heavy to manage. His design choice was radical simplicity: keys, events, relays.

The name. Nostr stands for Notes and Other Stuff Transmitted by Relays — notes and other stuff transmitted by relays. It is the acronym that appears in the official documentation.

2020-2022: the specification. The first version of the protocol is published and takes the name we know. NIP-01 is the founding document and remains the one that defines the basic operation: if you want to understand Nostr, its one hundred and eighty lines are the starting point, and they are a short document.

2023: adoption. It is the year in which the protocol leaves the narrow circle and reaches the wider public. The project takes the shape it has now: the specification lives in a public repository of improvement proposals, each numbered, called NIP.

The repository as a source of truth. It is a choice worth noting: there is no company publishing the rules, there is a repository with open proposals that anyone can read and propose to change. Anyone who designs free software knows the model, and it is the reason why the article on Open source: why paid software benefits from it applies here too.

Schnorr signatures. The specification uses Schnorr signatures on the secp256k1 curve, the same standard as Bitcoin's BIP-340. The choice is not random: Schnorr produces smaller signatures that can be verified more efficiently, and on a network where every relay verifies every event the cost difference is felt.

The virality of 2023. The case that takes Nostr out of the narrow circle is linked to a very high-profile account that joins the protocol, and the reason it stays in history is that it cannot be banned: there is no button. This is the argument that made the protocol known, and it is also its limit. The demonstrated use case is "publishing without being able to be censored", not "communicating in private".

2024 onwards. The NIPs begin to have sub-specifications, such as NIP-05 for human-readable identifiers and NIP-09 for deletion requests. It is the signal that the protocol has entered the phase in which standards are needed, not ideas.

What it means for those who work in security

Here the conversation changes, and it is worth making it explicit.

The signature is the solid part. A signed event is non-negotiable and verifiable: nobody, relays included, can show one of your events with a false signature. It is a stronger guarantee than the one given by any commercial social network, where the "verified" badge is a label from the provider.

Traceability is the weak point. An attacker who connects to a relay and sees the events signed by a certain pubkey has built a profile of that identity. They cannot impersonate it, but they can know when it is active and what it is about. It is the direct opposite of anonymity, and it is the reason why the protocol is suited to those who fear censorship and unsuited to those who need to disappear.

The absence of moderation is a security problem, not a freedom. In a protocol without authority there is no channel to report unlawful content, and there is nobody who forces you to remove it. For a platform it is a design choice; for a company that exposes personal data to third parties it is a regulatory problem, before a technical one.

The implications are valid only after verifying the implementation. The point on which most comments get it wrong is this: saying "I use Nostr, therefore I am private" without having read the client's code is a declaration of trust, not a guarantee.

The rule we use

CYBER ONIONS' reasoning about Nostr is brief, and it is not approval:

A protocol that gives you back control of your data is a good protocol. A protocol that gives you back control of your identity too, is not — and it is not that it is technically impossible: it is that every advantage of Nostr turns into its cost.

Put another way, with the rules we follow when we use it:

• more relays, never just one: a faithful relay that sees everything is enough to reconstruct what the others keep fragmented together;

• clients with readable code, verified before trusting their data;

• no personal data in events: the signature makes the event permanent, and deletion is a request that may not be honoured;

• Nostr for verifiable identity, not for anonymity: if you need to disappear, it is not the right tool.

If only one thing remains from all this: check the client, not just the protocol. The protocol is a public specification and it cannot change underneath you; the client is a program that someone wrote, and that one can change — or it can be buggy — without you knowing it.