What is Nostr? How keys, relays and Tor work

Nostr is an open protocol for exchanging signed messages through independently operated servers called relays. Your public key identifies you, your private key signs messages, and a client app handles reading and writing. Other people's apps retrieve those messages from relays and display them as feeds or conversations.

That separation explains much of Nostr's behavior. Your identity can stay the same when you change apps. A relay can refuse a post without taking your key away. A follower can miss something you published if their app never reaches a server holding it.

Nostr clients, signers and relays

The client is the app you use to read, write, search, and follow people. It decides how to present messages and which features to offer.

The signer holds a private key and authorizes events. It may be part of the client or separate software. NIP-46 describes one way for a client to request signatures from a separate signer without receiving the user's private key.

The relay receives events and returns those matching requests. Operators choose what to accept, how long to retain it, and whether access requires payment or authentication. A Nostr relay is not a Monero node. Our node directory serves wallets connecting to the Monero network, which is a different protocol.

You can use several relays at once. Adding one changes where your app sends or looks for data. It does not create another account.

Public and private keys: npub vs nsec

A Nostr identity uses a public key and a private key. The public key identifies the signer. The private key allows its holder to sign new messages under that identity.

Apps often display the public key as an npub and the private key as an nsec, following NIP-19. These are different encodings for different purposes. Share the public identifier when someone wants to follow you. Keep the private key secret and backed up.

Someone with your private key can publish as you. If you lose every copy, a relay operator cannot reset it like a website password. A separate signer can reduce how many apps receive the key, but its permissions and recovery arrangements still matter.

A name such as monero@monero.love is a domain-based identifier described by NIP-05. It helps a client look up a public key. It is not an email inbox, and it does not replace the key that signs messages.

How posts are signed and published

Imagine writing a short note about a new article. Your client packages it into an event with a timestamp, an event type, tags, content, and the author's public key. Your signer produces a signature, and the app sends the event to selected relays.

The event has an ID derived from its data. Copies of the same signed event keep that ID, allowing clients to recognize duplicates. Recipients can verify its signature. That checks which key signed the message, not whether the writing is truthful.

A relay replies with acceptance or rejection. Acceptance means that relay accepted the event, not that anybody read it. NIP-01 defines the event format and these exchanges.

Public posts remain readable. Signing proves authorship by a key, while encryption serves a different purpose. Do not treat a signature as a way to hide the content.

How relays deliver posts to followers

A reader's app asks relays for events matching filters, such as recent posts from followed public keys. It can keep the request open to receive new matching events. The client then assembles the returned messages into a feed.

There is no automatic network-wide broadcast to every server. If you publish only to a relay your followers never query, they may miss the post. NIP-65 lets users advertise where they publish and where they receive mentions. Clients supporting that discovery can look beyond their initial relay selection.

Reading and writing are separate settings. Reading from a relay does not mean your posts are stored there. Publishing a preferred relay list is also different from merely adding a server locally. Check what your client does with each setting.

Your follow list can itself be published, using NIP-02. A compatible client can retrieve it when you switch apps, provided a reachable relay still has it. Published follow lists are public. Portability depends on available data, so changing apps does not recover missing history.

Is Nostr anonymous? What Tor changes

Nostr does not make public posts anonymous. A public key links the events signed under that identity, and a direct relay connection exposes your IP address to its operator. Tor can hide the source address of that connection. It does not hide your public key or make public notes private.

Monero Love now offers an onion relay endpoint:

ws://5vpajljniv5i762fnx62snwtfm2ru3ycbjlxs35evndkvp6rqprfwnqd.onion

It reaches the same service and database as wss://relay.monero.love. A public event sent through the onion address can be read through the regular address. Using both is not independent storage redundancy.

Our Monero Love Nostr relay setup instructions cover adding both addresses, connection checks and publishing limits.

Use a client with documented onion-relay support and route its relay connections through Tor before adding the address. The ws:// prefix is intentional. Tor provides encryption for onion-service connections, as the Tor Project explains.

You can open the onion information page in Tor Browser. Our guide to using Monero Love over Tor covers the site's onion access. Opening a page does not configure a separate Nostr app. HTTPS web clients may block an insecure WebSocket scheme as mixed content, even when the destination is an onion service. Choose supported client behavior instead of disabling browser protections.

Other connections matter too. A client may contact additional relays, image servers, or link previews. Those requests need their own suitable routing. Using one onion relay does not send every request through Tor. Our identity-linking guide explains how reused details can connect accounts despite changes in network route.

Retention, backups and public-post privacy

Relays have different policies. Monero Love accepts events up to 90 days old and removes older events during hourly cleanup. Its onion and regular addresses share that retention policy, size limits, and per-author limits. Onion connections also share a publishing allowance. Check the current relay policy before relying on it for a particular workload.

Keep important writing and key backups somewhere you control. Several independent relays can improve availability, but none guarantees a reader or permanent storage. Monero transaction privacy does not extend to Nostr notes. Decide what to publish, which identity should sign it, and which operators should receive a copy.