NIP-51: Lists
The social graph is more than follows
NIP-02 gave Nostr a basic follow list. Real use quickly outgrew that. People need mute lists, bookmarks, pinned notes, blocked relays, search relays, communities, public chats, profile badges, favorite relays, blocked words, curation sets, app sets, picture sets and follow packs. If each client stores those choices privately, the user loses them when they switch apps.
NIP-51 turns those choices into portable Nostr events. A list can contain public items in tags and private items encrypted into the content field. That split is essential. Some lists are meant to be public, such as a curated app set or a displayed badge list. Others are deeply personal, such as mutes, blocked relays or private bookmarks.
This is one of the NIPs that makes Nostr feel less like one feed and more like a user-owned workspace. The user brings their shelves with them.
Standard lists, sets and the public/private boundary
NIP-51 defines two broad families. Standard lists are normal replaceable events where a user has one list per kind: mute list kind 10000, pinned notes 10001, read/write relays 10002, bookmarks 10003, communities 10004, public chats 10005, blocked relays 10006, search relays 10007, profile badges 10008 and more.
Sets use addressable events and can have many named instances. A user can publish many bookmark sets, curation sets, app curation sets, interest sets, emoji sets, release artifact sets, relay sets, picture sets or follow packs. The d tag names the specific set.
The current file uses NIP-44 for private list items. Older NIP-04 encrypted content is deprecated, but clients may detect it for backward compatibility. That history matters because lists are long-lived user state. Clients need to migrate carefully rather than throwing away old data.
A NIP that keeps absorbing real client behavior
NIP-51 has one of the busier histories because list-shaped behavior keeps appearing in real products. The file picked up interests, bookmark sets, kind mute sets, file metadata sets, video lists, favorite relays, follow packs, app curation sets, picture sets and Blossom server lists as the ecosystem discovered more portable preferences.
The 2025 NIP-44 migration is an important milestone. Private items moved away from NIP-04 toward the newer encryption format. The 2026 additions around NIP-F4 podcasts and Blossom server lists show that NIP-51 is still being used as the general place for user-owned collections.
That makes the standard powerful and messy. It is not one feature. It is a vocabulary for lists, and it will keep growing when a client behavior proves useful enough to leave the app database.
Good list support is careful sync, not just rendering tags
A client implementing NIP-51 needs to preserve order, append new items to the end, keep public and private entries distinct and avoid leaking private lists through previews, analytics or search. The muted-word list has a different privacy meaning than a public curation set, even though both are lists.
The standard intersects with NIP-65 relay lists, NIP-58 profile badges, NIP-72 communities, NIP-89 app handlers and several media standards. That means list support often becomes the glue between product areas. A client that ignores NIP-51 may still display notes, but it will feel amnesiac.
The test is simple: create a mute, save a bookmark, publish a curation set, accept a badge, move to another client and see whether the choices arrive intact without exposing what needs to stay private.
Lists can leak the user's inner map
Lists reveal taste, fear, relationships and intent. A public bookmark set may be fine. A public mute list can expose enemies. A public blocked-relay list can reveal threat models. Clients need defaults that respect those differences.
There is also interoperability risk. Because NIP-51 covers many list types, partial support can be confusing. A client needs to show when it ignores an unknown list kind instead of quietly deleting or overwriting it.
Read NIP-51 in the wild
NIP-51 is the list standard. It gives mute lists, bookmark lists, relay lists, interests and other collections a portable event shape.
Lists are where personal preference becomes infrastructure. A mute list can protect your feed; a public curation list can guide others; a private list can leak habits. Treat list visibility as part of the feature.
What changes when you actually use it
For you, NIP-51: Lists is felt inside the room: who can read, who can reply, what remains visible and what the interface makes private by implication. Messaging standards are risky because familiar chat design can smuggle in promises the protocol never made. Read NIP-44, NIP-04, NIP-02, NIP-65, NIP-72 as the surrounding map before trusting the room label.
What changes for builders and operators
For builders, NIP-51: Lists is expectation control. Test the same conversation across relays, devices and clients. Make audience, persistence, encryption and moderation visible. A chat-shaped interface can feel private even when the event is public, and that mismatch is a product bug.
What the official file makes concrete
The official file is organized around Types of lists, Standard lists, Sets, Deprecated standard lists, Examples, A mute list with some public items and some encrypted items, A curation set of articles and notes about yaks, A release artifact set of an Example App. Inspect kind 1, kind 30023, kind 34550, kind 40, kind 30009, kind 8, kind 30008, kind 30002 because these are the pieces most likely to surface as product behavior. Read it beside NIP-44, NIP-04, NIP-02, NIP-65, NIP-72, NIP-28 before treating it as isolated.
NIP-51: Lists needs honest audience language. Public, private, group, encrypted, temporary and moderated are different promises.
Where it breaks
The failure mode in NIP-51: Lists is false intimacy. The room feels like a messenger, but storage, audience, reply context or metadata tell a more public story. This is where copywriting, UI labels and protocol behavior need to match exactly.
Where this appears outside the markdown
In the ecosystem, NIP-51: Lists touches the most emotionally familiar interface: a conversation. That makes it easy for products to borrow the comfort of chat, groups or DMs while the actual protocol object has different privacy and delivery properties. The page has to slow that moment down before the interface creates a false expectation.
The nearby-standard trap
The nearby-standard trap in NIP-51: Lists is using one room word for several protocols. Chat, public chat, private DM, group, forum thread, comment and encrypted envelope are different. Read NIP-44, NIP-04, NIP-02, NIP-65, NIP-72 and keep the interface honest about which promise is actually present.
Language that keeps the feature honest
Good product copy for NIP-51: Lists names the room. It says public, encrypted, relay-scoped, group-controlled, archived, temporary or moderation-aware when those things are true. It avoids borrowing private-message comfort for data that travels more openly.
What this page does not promise
NIP-51: Lists does not turn every conversation into a private room. A chat-like screen can hide public relays, visible metadata, partial delivery, missing devices or moderation rules that only live on one server. The safe reading is concrete: who can read, where does the event live, what does encryption cover, and what happens when one client leaves?
Read it as a field test
Start NIP-51: Lists with the audience. A message-like interface earns trust only when public, private, encrypted, group-scoped and relay-scoped behavior are not blurred. Read NIP-44, NIP-04, NIP-02, NIP-65, NIP-72 before drawing product conclusions, because most messaging mistakes come from using the wrong room model for the event in front of you.
Where the standard earns trust
The source links give you places to test the interpretation in public: NIP-02 Follow List, NIP-44 Encryption, NIP-58 Badges, NIP-65 Relay List Metadata. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-51 source is the anchor for exact wording, and NIP-51 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-02 Follow List, NIP-44 Encryption, NIP-58 Badges. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-51: Lists: first the human promise, then kind 1, kind 30023, kind 34550, kind 40, kind 30009, kind 8, then the implementation record, then the real-world failure case. That order keeps NIP-51 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who can read the event, and does the screen say that before you type?
- What metadata remains visible even when content is encrypted or wrapped?
- Can another client recover the thread, room or message history without pretending delivery is guaranteed?
What to verify before you rely on it
- Find
kind 1,kind 30023,kind 34550,kind 40,kind 30009in the official file and check where the UI exposes the same concept. - Read NIP-44, NIP-04, NIP-02, NIP-65, NIP-72 as context before treating NIP-51 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-51: Lists in that order: Official NIP-51 source for the current wording; NIP-51 commit history for the change record; NIP-02 Follow List, NIP-44 Encryption, NIP-58 Badges for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
