Nostr

Platform · this deep dive is built from the official pages of the platform itself and of the tools that support it.

Overview

Nostr is not a platform but a protocol. The name stands for Notes and Other Stuff Transmitted by Relays. The site nostr.com describes it as "a free and open network that nobody owns and nobody controls".

The design is simple and everything else rests on it. There are relays — servers that store and serve messages. There are clients — applications through which people read and write. And there are keys: the public key works as a username and the private key as a password; it is the keys, not a company, that give you the right to your identity. Because the identity belongs to the key rather than to the application, you can move between clients while keeping your profile, followers and posts.

Technically it all comes down to a single type of object. The protocol's base document states: the only object type that exists is the "event", signatures and keys use the Schnorr scheme on the secp256k1 curve, and a relay exposes a websocket endpoint to which the client sends three kinds of message: EVENT to publish, REQ to subscribe to a query and CLOSE to close it.

For this guide that means the following: Nostr has no owner, no single audience, no advertising dashboard, no moderation rules and no payout programme. What follows examines what exists instead.

Who's here

An audience figure for Nostr does not exist — and cannot exist in the usual sense. There is no central server that would count users: there is a multitude of independent relays, each of which sees only its own.

You can judge indirectly only from individual relays. The client at nostr.com connects by default to six relays and shows their list right in the interface: relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom and relay.snort.social. The project recommends looking for a relay directory at the third-party service Nostr.watch and a client directory at nostrapps.com (the page about relays, the page about clients).

There is no breakdown by language or country, and there cannot be: the protocol does not store that kind of information about a user. By default a profile contains only a name, a description and a picture.

Getting started

There is no registration in the usual sense: an account is a key pair generated by the application. No e-mail confirmation, no phone number, no review of an application.

From this follows the main risk, of which the project itself warns: the private key gives full access to the account — with it one can post in your name, change the profile and send messages; if the key is lost and there is no copy, no "forgot your password" button exists. The project's practical advice: do not paste your private key into every application in sight — a signing browser extension or a remote signer is safer.

A verifiable name resembling a "check mark" can be obtained: a separate protocol document describes binding a key to a domain. The client takes an address of the form name@domain from the profile, requests https://domain/.well-known/nostr.json?name=name and compares the public key it receives with the key of the post's author. For a company this is precisely the way to confirm that an account really is its own: the confirmation comes from control over a domain, not from a moderator's decision.

There is no separate business account — just as there is no ordinary one. A company's presence on Nostr is a key bound to its domain and, if it wishes, its own relay.

What you can publish

Formats are set by event "kinds", and the kinds are described in separate documents — NIPs (Nostr Implementation Possibilities). Their list is maintained in an open repository and includes, among other things: short notes and discussion threads, long-form material, images and video, live streams and "spaces", polls, calendar events, wikis, torrents, lists, bookmarks and quotes (the list of NIPs).

The protocol has no length or size limits — the relay has them, and the relay is obliged to declare them. The document about relay information describes the fields: max_message_length — the maximum size of incoming JSON in bytes (which in practice also limits the size of an event), max_content_length — the maximum number of characters in the content field, max_event_tags — the maximum number of tags, max_subscriptions — the number of simultaneous subscriptions on one connection, max_limit — the ceiling on the number of events in the response to a single request.

Here is how it looks in practice. The relay relay.damus.io on the check date declares a message limit of 1,000,000 bytes, 200 subscriptions and a query ceiling of 500 events; the relay nos.lol — 131,072 bytes, 20 subscriptions, the same 500 events; the relay relay.nostr.com — 131,072 bytes, 200 subscriptions, 500 events. The numbers belong to each relay individually, and on another relay they will be different.

The protocol has no content bans. There is technical markup: one document describes flagging sensitive content, another — reports about events, a third — a request for deletion. Note the word "request": deletion on Nostr is an ask to the relays, not a guarantee. What exactly to accept and store is decided by the relay's owner.

How to grow

There is no algorithmic feed in the protocol. What to show the user is decided by the client, and which events to serve — by the relay. The client at nostr.com shows this plainly: its interface has the feed options "following", "global" and "your own", and below them a list of the connected relays.

From this follows a practical consequence that the project explains itself: if Nostr feels slow or empty, the relays may be the reason; some relays are fast and reliable, some go offline and do not respond, and adding a few good relays changes a lot. Growth on Nostr is first of all publishing to the relays where there really are readers.

There is no advertising dashboard: the protocol has neither a platform that would sell impressions nor a mechanism for counting them. There are no built-in statistics either; the closest thing is the COUNT request, which the relay executes where possible and approximately.

The protocol offers an unusual anti-spam measure: the proof-of-work document allows a relay to require a given computational difficulty from new events. The second measure is money: some relays are paid, and this reduces spam, because running a relay costs money and users gain a reason to behave decently.

Path to monetization

There is no platform — so there are no payouts from a platform. What there is instead is direct payments between people, and they are described in the protocol itself.

The mechanism is called a "zap" — a payment through the Lightning network. The protocol document introduces two kinds of event: 9734 — the zap request, that is, the payer's approach to the recipient's wallet for an invoice, and 9735 — the receipt, the recipient's wallet confirming that the invoice has been paid. The sequence is this: the client takes the address of the recipient's payment endpoint from their profile, checks that it supports Nostr, sends a signed request there and receives an invoice; after payment the wallet publishes a receipt. The point of the receipt is explained in the same place: it lets clients show payments right in the feed — for fun or as an anti-spam measure.

There is no platform commission in this scheme — the money goes from wallet to wallet. But there are no platform guarantees either: delivery of the payment is the responsibility of the Lightning network and the wallet provider you choose.

Besides zaps, the protocol's list contains other money mechanisms too: zap goals, badges, Cashu wallets and "nutzaps", remote wallet connection and order events between people. Each of them is implemented by a client at its own discretion.

Tools and automation

Nostr has no "official API" for the same reason it has no owner: the protocol itself is the interface. Any program can open a websocket to a relay and work with it directly (the base document). Developer keys, access applications and app review do not exist.

Before building a service, it is worth reading the warning from the list itself: "The NIPs here are not a protocol checklist. Nothing forces any program to implement any NIP. Each application picks the subset it needs for its task". That means you cannot count on a feature merely because it is described: you have to check whether a particular relay supports it. A way of checking is provided: a relay serves over HTTP a document with a list of the NIPs it supports, the name of the software, its version, contacts and a link to its terms of service. The three relays named above declare an identical set: all three run the strfry software and support NIPs 1, 2, 4, 9, 11, 28, 40, 45, 70 and 77.

Among ready-made tools the project names browser extensions for signing and remote signers, as well as its own signer, Pomegranate. Directories of clients and relays are maintained outside the protocol — at nostrapps.com and Nostr.watch (the page about clients, the page about relays).

Limits and rules

• There are no common rules. Not a single document exists that would forbid anything to all participants of the network. The rules are set by the relay's owner; the protocol merely provides for a link to the terms of service in the relay information.
• The relay sets the limits and declares them itself: message size, content length, number of tags, number of subscriptions, query ceiling.
• A relay may require authentication under the auth protocol or proof of work for new events.
• Deletion is not guaranteed: the document describes precisely a "deletion request", and whether to honour it is decided by each relay.
• Losing a key is irreversible. There is no way to restore access.
• The network has no legal framework. Liability rests with the relay's owner and the author; the protocol has no legal entity with which a contract could be concluded. The list of NIPs itself is published in a repository without a stated licence.

Who it's for

It suits projects for which independence from a platform owner matters: the identity belongs to the key rather than to a company, an account cannot be blocked centrally, and if you are unhappy with a relay it is enough to change relays. It suits developers: connecting to the network requires neither an application key nor approval.

It suits projects tied to Bitcoin and Lightning: payments are built into the protocol as zaps, and that is the most developed part of its money mechanics.

It does not suit you if you need predictable reach and reporting: there is nothing to measure here — no platform, no statistics, no advertising dashboard. It does not suit mass mailing and "promotion": a relay is free to demand payment, authentication or proof of work and to cut you off without explanation. And it does not suit you if your organization requires a contract with a service provider: the protocol has no such counterparty.

Verified data

The checked data this deep dive rests on.

About the platform

the platform describes itself as: «Nostr is a free and open-source protocol for social media and other things - controlled by users, not platforms.»

Self-description: this is the platform's claim about itself, not an independent assessment

source, checked 2026-07-28

Nostr (Notes and Other Stuff Transmitted by Relays) is described as a free and open network that nobody owns and nobody controls; relays store and serve messages, clients let people read and write them

This is a protocol, not a platform: it has no owner, no advertising dashboard and no payout programme

source, checked 2026-07-28

the only object type is the event; signatures and keys use the Schnorr scheme on the secp256k1 curve; a relay exposes a websocket endpoint, and the client sends EVENT to publish, REQ to subscribe and CLOSE to close a subscription

The protocol's base document NIP-01

source, checked 2026-07-28

Getting started

the barrier to entry to nostr has no single owner of the rules: «Nostr (Notes and Other Stuff Transmitted by Relays) is a free and open network that nobody owns or controls»; the body of protocol proposals says the same about itself: «NIPs listed here are not a protocol checklist. Nothing forces any software to implement any NIP»

the quotations are verbatim, the source language is English. The second comes from the README of the NIP repository: https://raw.githubusercontent.com/nostr-protocol/nips/master/README.md. The practical conclusion for the reader: there are no single conditions of entry binding on the whole network; the conditions are set by each individual relay and each application, and they differ

source, checked 2026-08-07

a relay may close writing, require sign-in by signature or demand proof of work: the list of limitations in NIP-11 names «auth_required», «restricted_writes», «min_pow_difficulty», «payment_required»; «Your client should expect that requests exceed these practical limitations are rejected or fail immediately»

the quotations are verbatim, the source language is English, the source's spelling preserved. There are no applications, invitations or moderation at the protocol level; everything listed is a property of an individual relay, and it can be learnt by requesting that relay's information document

source, checked 2026-08-07

Account and access

an account is a key pair rather than a record held by the owner of a platform: «Every account has Nostr keys. Your public key is like your username and can be shared with anyone. Your private key is like your password and must be kept safe. These keys give you ownership of your identity, rather than a company owning it for you»

the quotation is verbatim, the source language is English. Neither registration, nor identity verification, nor approval is required to obtain keys: the key pair is generated on the device. An optional verifiable name of the form name@domain is described in a separate NIP-05

source, checked 2026-08-07

an account has a key pair: the public key works as a username, the private key as a password; the identity belongs to the key rather than to an application, so you can change clients while keeping your profile and followers

There is no registration, no e-mail confirmation and no review of an application

source, checked 2026-07-28

if the private key is lost and there is no backup, access cannot be restored: no «forgot your password» button exists

The project advises not pasting the private key into every application, but using a signing extension or a remote signer

source, checked 2026-07-28

a verifiable name of the form name@domain: the client requests https://domain/.well-known/nostr.json?name=name and compares the public key it receives with the key of the post's author

For a company this is a way to confirm an account through control over a domain rather than by a moderator's decision

source, checked 2026-07-28

What you can publish

the list of NIPs describes, among other things: short notes and threads, long-form material, images and video, live streams and spaces, polls, calendar events, wikis, torrents, lists, bookmarks and quotes

The list of NIPs is not a set of obligations: nothing forces a program to implement any NIP

source, checked 2026-07-28

How the money works here

Who is admitted. payments have no threshold in subscribers, views or number of posts: zaps go directly from person to person over the Lightning network, and the only condition is that the recipient has a wallet with an lnurl address — «Client calculates a recipient's lnurl pay request url from the zap tag on the event being zapped, or by decoding their lud16 field on their profile»

the quotation is verbatim, the source language is English. A threshold of zero: NIP-57 requires no subscriber count, no viewing hours and no account age. The limits on amounts are set by the recipient's wallet through the fields «minSendable» and «maxSendable», not by the network

source, checked 2026-08-07

there is no network commission and no one to take it: money goes past the protocol, through the recipient's wallet, and nostr takes no part in the settlement — NIP-57 describes only two kinds of event, a request record and a receipt record: «9734 is a zap request… 9735 is a zap receipt, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a zap request has been paid»

the quotation is verbatim, the source language is English. A wallet or a node of the Lightning network may take a commission of its own — that is no longer nostr, and its size is not set in NIP-57. The network has no commission, no share and no payout threshold, because there is no intermediary holding the money

source, checked 2026-08-07

payments between people are described in the protocol as «zaps» through the Lightning network: event 9734 is the zap request, event 9735 the receipt from the recipient's wallet confirming the invoice has been paid

There is no platform commission in the scheme: the money goes from wallet to wallet; responsibility for delivery lies with the Lightning network and the wallet provider

source, checked 2026-07-28

the list of NIPs also contains zap goals, badges, Cashu wallets and nutzaps, remote wallet connection and order events between people

Each mechanism is implemented by a client at its own discretion

source, checked 2026-07-28

Pricing

the protocol takes no money, but an individual relay may: NIP-11 provides fields for charges — «Relays that require payments may want to expose their fee schedules»: «fees»: «admission» (a charge for admission), «subscription» (a subscription with a «period» field), «publication» (a charge for publishing, with the kinds of event specified); the list of relay limitations includes the flag «payment_required»

the quotations are verbatim, the source language is English. Each relay sets the figures itself, so the network has no single price of entry. The example given in NIP-11 itself as a sample relay response for nostr.wine: «fees»: «admission»: ({«amount»: 18888000, «unit»: «msats»}) — this is a relay's statement in a sample document, not our calculation and not a promise of a current price

source, checked 2026-08-07

Limits and restrictions

a relay declares its limits in its information document: max_message_length (the size of the incoming JSON), max_content_length (characters in the content field), max_event_tags, max_subscriptions, max_limit; authentication and proof of work may be required

The document NIP-11; the protocol itself has no length or size limits

source, checked 2026-07-28

the relay relay.damus.io on the check date declares a message limit of 1,000,000 bytes, 200 simultaneous subscriptions and a query ceiling of 500 events; the strfry software

The figure belongs to this relay; on another it is different

source, checked 2026-07-28

the relay nos.lol declares a message limit of 131,072 bytes, 20 subscriptions and a query ceiling of 500 events

Measured by requesting the relay's information document

source, checked 2026-07-28

the relay relay.nostr.com declares a message limit of 131,072 bytes, 200 subscriptions and a query ceiling of 500 events; the NIPs claimed are 1, 2, 4, 9, 11, 28, 40, 45, 70, 77

damus.io and nos.lol declare the same set of NIPs

source, checked 2026-07-28

Restrictions

there are no common rules: what to accept and store is decided by the relay's owner; the protocol merely provides for a link to the terms of service in the relay's information

Deletion is described as a «deletion request», and execution is not guaranteed

source, checked 2026-07-28

anti-spam measures: a relay may require proof of work of a given difficulty or authentication; some relays are paid, which, by the project's explanation, reduces spam

Nostr.watch is recommended by the project as a directory of relays, nostrapps.com as a directory of clients

source, checked 2026-07-28

the robots file of nostr.com allows crawling of the site to all agents

Checked separately

source, checked 2026-07-28

Legal

the repository with the list of NIPs is published without a stated licence

The protocol has no legal entity with which a contract could be concluded

source, checked 2026-07-28

API access

the client at nostr.com connects by default to six relays: relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom, relay.snort.social

The list is visible right in the interface

source, checked 2026-07-28

there is no separate «official API»: the protocol itself serves as the interface, and any program can open a websocket to a relay; developer keys and app review do not exist

Support for particular features has to be checked in the relay's information document

source, checked 2026-07-28

Languages

the interface language of the home page: en

The language is taken from the markup attribute, the versions from hreflang

source, checked 2026-07-28

Catalogue section: all similar See also: catalogue index · scheduler comparison · find by situation · platform restrictions