NIP-02: Follow List
A social graph that can leave the client
NIP-02 is one of the reasons Nostr feels different from a normal social platform. A following list is not a private table in one company's database. It is a signed event, kind 3, published by the user and readable by any client that understands the convention.
That sounds obvious until you compare it with the platform model. On a centralized network, the follow graph is a product asset. On Nostr, the follow graph can become user-held state. A client can disappear and the user can still recover who they followed, assuming the event remains available on relays.
The NIP is deliberately modest. It does not define a full social graph engine. It defines a replaceable event whose tags list followed pubkeys, optionally with relay hints and petnames. The value is not sophistication; it is portability.
Kind 3, p tags and the shape of follows
A NIP-02 follow list is a kind 3 event. Its tags array contains one p tag per followed or known profile. The second element is the followed user's public key. The third can hold a relay URL where that user's events may be found. The fourth can hold a local petname.
The content field is not used. The meaning lives in the tags. Because kind 3 is replaceable under NIP-01's kind-range rules, a new follow list replaces the older one for the same pubkey. That is useful, but it also creates a clear implementation obligation: clients need to publish the whole current list, not just the new follow, when updating the state.
The relay hint is historically important. Early Nostr had a hard discovery problem: knowing a pubkey did not always tell a client where to find that person's events. NIP-02 lets users publish some relay context beside the social graph. Later standards, especially NIP-65, gave relay discovery more specialized structure, but NIP-02 still carries the older social-graph pattern.
From contact list to follow list
The visible file history starts with the May 2022 migration of NIPs from the main Nostr repository. In November 2022, it was marked among NIPs that had settled enough to be finalized. In December 2023, Alex Gleason changed the name from Contact List to Follow List, a small wording change that reflects how users and clients actually talk about the feature.
That rename matters because NIP-02 sits at the border between protocol language and product language. A contact list sounds like an address book. A follow list sounds like social software. The NIP can support both ideas, but in most clients the user's mental model is simple: these are the people I follow.
The history also shows why lists became a larger subject later. NIP-51 generalizes list behavior for many objects, while NIP-02 remains the specific, familiar kind 3 follow graph. The older standard survived because the follow graph is too central to fold into a generic list without losing clarity.
Where follow lists become product behavior
Clients use NIP-02 for account recovery, follow import/export, suggestions, profile context and relay hints. The simplest use is backup: publish your follow list once, then another client can fetch your latest kind 3 event and reconstruct the follow set.
The more interesting use is social context. A client can show who someone follows, build recommendations, infer network neighborhoods and use petnames to make unfamiliar pubkeys more readable. That can be useful, but it also makes NIP-02 one of the early places where Nostr's public-by-default model becomes visible. A follow list says something about a user.
Implementation needs care around replacement. If a client appends a new follow locally but publishes only that new tag, it can accidentally wipe the list elsewhere. If clients reorder or mutate tags without intention, they can destroy chronological cues. The spec asks clients to append new follows to the end so the list can preserve some time ordering.
The social graph is portable, but not private
The obvious weakness is privacy. A public follow list is a public social graph. For many users that is acceptable; for others it can reveal politics, communities, contacts or operational habits. NIP-02 predates more nuanced list privacy patterns, so people must not mistake portability for confidentiality.
There is also a product tension. Follow lists are simple enough for every client to support, but the interpretation is not universal. Does following mean friendship, reading preference, trust, contact backup or a public signal? The standard stores the list; the client gives it social meaning.
Read NIP-02 in the wild
NIP-02 is the public follow graph. It is easy to describe as a contact list, but that phrase hides the point: your social graph can move because it is a signed event, not a table inside one company. A client can rebuild the people you follow from your key instead of asking a platform to export your account.
The tradeoff is privacy. A public follow list can reveal communities, politics, work relationships and habits. Treat portability and confidentiality as separate decisions: NIP-02 helps you leave an app, but it does not make your relationships invisible.
What changes when you actually use it
For you, NIP-02: Follow List is felt when identity stops being a username and becomes authority. A client, signer, name, proof or auth event may look like account plumbing, but it decides who can publish, approve, connect, recover or be recognized. Read NIP-01 and the adjacent source links beside it so you can tell the difference between a convenient identity surface and the key material that actually controls the account.
What changes for builders and operators
For builders, NIP-02: Follow List means making authority visible before action. A signer prompt, name proof, delegation, encrypted key, external identity or HTTP auth event needs plain language around scope, expiry, destination and recovery. If a person has to guess what they are authorizing, the protocol has already lost the trust battle.
What the official file makes concrete
The official file is organized around Uses, Follow list backup, Profile discovery and context augmentation, Relay sharing, Petname scheme. Inspect p, ["p", <32-bytes hex key>, <main relay URL>, <petname>], .content because these are the pieces most likely to surface as product behavior.
NIP-02: Follow List is an authority path, not decoration. A name, key, signer, delegation or auth event decides who can act as you.
Where it breaks
The failure mode in NIP-02: Follow List is authority drift. A name resolves to an old key, a signer approves too broadly, an auth event gets replayed, a delegation lasts too long or a private key backup gives false comfort. The product has to keep control boundaries visible after onboarding, not only during setup.
Where this appears outside the markdown
In the ecosystem, NIP-02: Follow List usually appears at the doorway: account setup, profile recognition, signer approval, cross-platform proof, remote signing, HTTP auth or recovery. That doorway needs unusually clear language because identity mistakes are sticky. Once a key, signer or proof is trusted in the wrong place, every later feature inherits the confusion.
The nearby-standard trap
The nearby-standard trap in NIP-02: Follow List is confusing recognition with control. A name, signer, URI, encrypted key, delegation or auth signature may all sit near identity, but they answer different questions. Read NIP-01 and the adjacent source links and ask one thing each time: who can act, who can verify, and what can be revoked?
Language that keeps the feature honest
Good product copy for NIP-02: Follow List names the authority. It says whether you are sharing a public key, approving a signature, trusting a domain, exporting an encrypted secret, delegating power or authenticating to a service. Small labels matter because identity mistakes do not feel small after they happen.
What this page does not promise
NIP-02: Follow List does not make identity effortless or risk-free. It can help keys, names, signers, delegation or authentication become portable, but it cannot decide who you trust, how you back up secrets or whether a domain, app or signer deserves authority. Read NIP-01 and the adjacent source links as a control map before handing any interface the power to sign, verify or speak for you.
Read it as a field test
Start NIP-02: Follow List with the moment of authority: signing, naming, delegation, authentication, encryption or recovery. Then ask which key or service can act. The source terms p, ["p", <32-bytes hex key>, <main relay URL>, <petname>], .content are useful because they turn vague identity language into concrete control points. Without that, a friendly login screen can hide the most important security decision.
Where the standard earns trust
The source links give you places to test the interpretation in public: nostr-tools issue #322, NIP-51 Lists, Nostr.co.uk NIP-02 explainer. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-02 source is the anchor for exact wording, and NIP-02 commit history shows how that wording moved over time. The strongest secondary clues here are nostr-tools issue #322, NIP-51 Lists, Nostr.co.uk NIP-02 explainer. 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-02: Follow List: first the human promise, then p, ["p", <32-bytes hex key>, <main relay URL>, <petname>], .content, then the implementation record, then the real-world failure case. That order keeps NIP-02 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who gains authority when this NIP is used: your key, a signer, a domain, a delegated key, a wallet or a web service?
- Can you revoke, rotate, back up or inspect that authority before something goes wrong?
- Does the interface separate public recognition from private signing power in language you can act on?
What to verify before you rely on it
- Find
p,["p", <32-bytes hex key>, <main relay URL>, <petname>],.contentin the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-02 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-02: Follow List in that order: Official NIP-02 source for the current wording; NIP-02 commit history for the change record; nostr-tools issue #322, NIP-51 Lists, Nostr.co.uk NIP-02 explainer 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.
