How Nostr Works and Why a Social Network Without a Single Server Functions at All

Almost every decentralized social network protocol eventually turns into a monster. ActivityPub drags along heavy Mastodon servers, where a ban on one node cuts you off from half the audience. P2P networks like Scuttlebutt run into synchronization problems on mobile devices and drain the battery in half a day.

The creator of the Nostr protocol (which stands for Notes and Other Stuff Transmitted by Relays) took the opposite approach: dropped blockchains, dropped complex P2P protocols, and left only cryptography and simple WebSocket relays.

The Core Idea

Nostr is not a ready-made social network or a standalone application. It's a specification for network interaction that fits into a couple dozen short documents (NIPs, Nostr Implementation Possibilities).

You don't have a login, password, or phone number binding. An account is a pair of cryptographic keys: private (secp256k1) and public. Your public key serves as your identifier, and you sign every action with your private key.

Any message, article, reaction, or avatar change is called an event in protocol terminology. Essentially, it's a regular JSON object:

{
  "id": "4376c65d2f23493d6050d0c393d01f50252a607d58eab305699c6811ea70017d",
  "pubkey": "9fe415e4177d13521649f80e4293097b540e555d34a14f4e2454b62412f93008",
  "created_at": 1672531199,
  "kind": 1,
  "tags": [],
  "content": "Привет, это тестовый пост в Nostr!",
  "sig": "250e938424f...подпись...4e8f9b"
}

The client forms such a JSON, signs it with your private key, and sends it via WebSocket to one or several relay servers.

How Relays Work

A relay is a dumb server. It doesn't know who you are and doesn't care about your application's logic. Its tasks are:

• Accept JSON over WebSocket.
• Verify the author's signature.
• Store the event in a database (usually SQLite or PostgreSQL).
• Distribute the event to subscribers who requested a filter by your pubkey.

If the owner of a specific relay decides to ban you, you simply switch your client to five other relays. Your subscribers will find your posts there, because the author's signature is still there, and the relay cannot forge the message text without the private key.

At the same time, relays can be paid (anti-spam via subscription or micropayments), private (only for company employees), or public.

The Main Engineering Problem

In theory, everything looks great: many relays, no censorship. In practice, a question arises: how does the reader's client know which exact relays the author sends their posts to?

If you subscribe to 500 people, polling thousands of existing relays is expensive. The community adopted the Outbox model (NIP-65). The author publishes a list of relays they write to (write relays). The subscriber requests this list and connects only to them. For optimization, clients find intersections and keep connections open to just 10-15 servers.

What Developers Build on Nostr

Due to the simplicity of the specification, people started building things on Nostr far beyond regular microblogging:

• Clients like Damus (iOS), Amethyst (Android), or Coracle (Web) for Twitter-style communication.
• Platforms for long-form articles (NIP-23), where posts are stored in Markdown.
• P2P messengers with message encryption using the conversation partner's public key.
• Website authentication systems (NIP-07), where a browser extension signs the request instead of entering login and password.

Libraries for working with the protocol exist for practically any stack: Go, Rust, TypeScript, Python, Dart. Writing a minimal client that connects to a relay and listens to a stream of posts can literally be done in 30-40 lines of code.

Is It Worth Digging Deeper

Nostr is not perfect. It's difficult to organize search without third-party indexers, there's no built-in data deletion (a deleted post can forever remain on a stubborn relay), and synchronization between multiple clients sometimes fails.

But if you're interested in clean, minimalist network design without overengineering, the repository is definitely worth exploring. Start with the basic events specification in NIP-01, and you can try out ready-made clients through the catalog at nostrapps.com.