What is Nostr?
A practical first model: your key is the identity, events are the signed record, relays carry the record, and clients turn it into an experience you can actually use.
Start with the simplest useful picture. Nostr is not one app, one company database or one feed. It is a way to sign social data with your own key, publish it to relays, and let different clients read it back in different shapes.
The account moves first
On a normal social network, the account lives inside the platform. The company owns the database, controls the API, defines the ranking rules and can decide which client is allowed to exist. You can export some data, maybe, but the account itself is still a tenant.
Nostr flips that first piece. Your public key is the stable identity. Your private key signs actions as that identity. A client can disappear, a relay can reject a post, a feed can feel wrong, and the identity can still continue somewhere else. That is the first idea to keep in your pocket.
- Public key. The identifier other people can follow, search, verify and display.
- Private key. The signing authority. Treat it like a root credential, not like a casual password.
- Signature. The proof that an event really came from the key that claims to have sent it.
Four pieces, not one platform
The daily Nostr system is made of four moving pieces: keys, events, relays and clients. Keys identify and sign. Events carry the actual content or state change. Relays receive, store and return events. Clients create the visible product: timeline, long-form editor, marketplace, wallet flow, dashboard or venue interface.
That separation is why Nostr can feel strange at first. You are used to an app being the account, the server, the feed, the moderation system and the business model at once. Here those jobs can be split. That is powerful, but it also means you need better words for what is happening.
- Keys. Who is acting.
- Events. What was signed.
- Relays. Where it is published, stored, filtered or refused.
- Clients. How you see, create and navigate it.
Events are the basic object
NIP-01 is the base layer: an event has an id, a public key, a timestamp, a kind, tags, content and a signature. A short note, a profile update, a follow list, a zap receipt, a badge award or a relay list can all be represented as different event types.
This is why Nostr is broader than microblogging. A timeline is only one possible client view over signed events. The same pattern can support long-form writing, search, file metadata, wallet permission messages, badges, lists, communities, marketplaces and local venue context.
Relays are not social accounts
A relay is not where your identity lives. It is more like infrastructure with opinions. It can accept, store, return, rate-limit, reject, require payment, require authentication or moderate. A client asks relays for events by sending filters, and relays answer with matching events.
Because relays do not automatically synchronize with every other relay, availability is a design question. If you publish only to one fragile relay, the post can be hard to find later. If you publish everywhere without strategy, you create noise and overhead. Good clients and good relay lists matter.
Why it is not a blockchain
Nostr does not put every social action into blocks, and it does not require a native token. Events are signed and distributed through relays. Bitcoin and Lightning enter the picture when money is useful: zaps, wallet connections, paid access, rewards or settlement.
That distinction matters. The social layer stays lightweight. Payments can be attached where they make sense. You do not need consensus for every note, but you do need good key handling, relay choice, client UX and spam resistance.
Where we use the idea
For us, Nostr is useful because we need one identity layer that can touch profiles, creator pages, fan demand, content access, status, venues, awards, payments and future governance. A closed Crays-only login would be easier to build, but too small for the mission.
The honest product job is to hide the machinery without hiding the ownership. You should not need to memorize every NIP to use Crays, but the system underneath should still respect portable identity, signed actions and user control.
The first test before trusting any feature
When a Nostr product sounds exciting, ask four questions: what is signed, where is it stored, which client shows it, and what still works if one service disappears. That test cuts through most protocol fog.
If the answer is clear, you are looking at a real Nostr-shaped feature. If the answer is vague, you may still be looking at a normal platform feature with Nostr words painted on the outside.
- Signed. Which key authorized the action?
- Stored. Which relay, file server or service keeps the data available?
- Rendered. Which clients know how to show it?
- Portable. What survives if the first app is gone?
The client-relay conversation
Under the friendly app surface, Nostr is a small conversation between clients and relays. A client can send an EVENT message when you publish. It can send a REQ message with filters when it wants posts, profiles, follows, replies or other event kinds. Relays answer with matching EVENT messages, an EOSE marker when stored results are done, and OK or CLOSED messages when they accept, reject or end a subscription.
That message flow matters because it explains why two clients can feel different while reading the same network. One client may query more relays, use better filters, understand more event kinds, cache more aggressively or show clearer errors. The protocol gives the common language; the client still decides how fluent the experience feels.
- EVENT. A signed event sent to or returned by a relay.
- REQ. A subscription request with filters such as authors, ids, kinds, tags, since, until and limit.
- EOSE. End of stored events, meaning the relay has finished the historical part of a query.
- OK. The relay's publish response, including whether an event was accepted.
Addresses you will actually meet
NIP-19 is one of the most useful beginner standards because it gives human-facing prefixes to different data. npub is a public key. nsec is a private key. note points to an event id. nevent can carry an event plus relay hints. naddr points to addressable events such as long-form articles or replaceable records.
Those prefixes are not decorative. They help products make dangerous and safe values visually distinct. A good interface should make it almost impossible to confuse a public identifier with a signing secret.
NIPs are optional building blocks
A NIP is a Nostr Implementation Possibility, not a promise that every app supports the feature. NIP-01 is foundational. NIP-05, NIP-07, NIP-19, NIP-23, NIP-47, NIP-57, NIP-65 and NIP-94 are practical pieces you will meet often. Others are narrow, experimental or only useful inside certain products.
That is why we avoid explaining Nostr as one finished product. The network is a standards shelf plus real clients, relays and services that implement different pieces at different quality levels.
Media and money sit next to the core
The core protocol signs and moves events. Larger media and payments sit next to that core. NIP-94 describes file metadata. NIP-96 described HTTP file storage but is now marked unrecommended in favor of Blossom. Blossom uses sha256-addressed blobs, HTTP servers and Nostr-based authorization. NIP-57 describes zaps, and NIP-47 describes wallet connection.
That gives you a more honest picture: Nostr can carry social identity, references and payment signals, but real products still need storage, wallets, limits, moderation and clear user prompts.
Source trail for the first model
If you want to verify the model yourself, read the sources in this order. Start with NIP-01 for the event and relay message format. Then read NIP-19 for visible identifiers, NIP-05 for names, NIP-07 for browser signing and NIP-65 for relay lists. Use Nostr.how and the Developer Guide when the raw standards feel too terse.