Oddbean

If you are a nostr user or developer you're probably familiar with nostr identifiers. These identifiers are used to represent public/private keys or event ids. They allow for a human-readable representation of these values that can be used for copy-pasting, sharing, [nostr URIs](https://github.com/nostr-protocol/nips/blob/master/21.md), rendering QR codes or referencing entities in [text content](https://github.com/nostr-protocol/nips/blob/master/27.md). The identifier start with a prefix that indicates the type of the identifier: `npub` for public keys, `nsec` for private keys and `note` for note ids. The prefix is followed by a separator character (`1`) and a payload that is encoded using the [Bech32](https://en.bitcoin.it/wiki/Bech32) encoding scheme. The pubkey `7fa56f5d6962ab1e3cd424e758c3002b8665f7b0d8dcee9fe9e288d7751ac194` is represented as `npub107jk7htfv243u0x5ynn43scq9wrxtaasmrwwa8lfu2ydwag6cx2quqncxg`. ## Context matters There are special variants of the identifiers that include metadata to provide more context. The extra information enhances nostr client UX and interoperability since it allows to more easily find and display these entities. The `nprofile` prefix is used to represent a public key with a set of relays where the user profile can be found. The `nevent` prefix is used to represent an event id (not necesarily a kind 1 note) with an optional set of relays where the event has been seen, the author of the event and an optional kind number. The `naddr` prefix is used to represent an address with kind, author, identifier (`d`) and an optional set of relays where the event has been seen. For those variants the content is a binary-encoded list of [`TLV`](https://en.wikipedia.org/wiki/Type%E2%80%93length%E2%80%93value) fields. Check out [NIP-19](https://github.com/nostr-protocol/nips/blob/master/19.md#shareable-identifiers-with-extra-metadata) for a breakdown of which types are used for each prefix. ### Pubkeys Although there are relays that aggregate profile metadata and relay lists such as [Purple Pages](https://purplepag.es/) and [profiles.nos.social](wss://profiles.nos.social"), a bare `npub` is not enough to find a user's content. The `nprofile` alternative prefix tells clients where they can find the user's profile and posts. Some great options for the relay hints included in an `nprofile` are the relays on the user's [relay list metadata](https://github.com/nostr-protocol/nips/blob/master/65.md) event. ### Events An `nevent` identifier can contain additional metadata about the event such as relay hints, the author of the event and the kind number. The relay hints can be used to find the event on the network and the author can be used to display the author's profile picture and name. Including the kind number in the identifier is useful for clients since they can know if the event is compatible with their rendering logic. A client that only supports kind 1 notes can ignore [kind 9802 highlights](https://github.com/nostr-protocol/nips/blob/master/84.md) or show their `.content` field. A better alternative would be to query the nostr network to find compatbile apps via [NIP-89 Recommended Application Handlers](https://github.com/nostr-protocol/nips/blob/master/89.md) or even embed the apps in the client itself. ### Addresses There are certain types of events that do not have stable identifiers since they can be replaced anytime. A user can publish new versions of long-form articles or their profile. The `naddr` prefix is used to represent these events with an identifier that can be used to find the latest event. The `d` field is used to represent the identifier of the event that the address points to. Similary to `nevent`, the `naddr` prefix can include relay hints to find the event on the network. The author field can be used to display the author's profile picture and name. The kind field can be used to know if the event is compatible with the client's rendering logic. ## tl;dr I encourage developers to use the variants with added context whenever possible. This means that clients will need to keep track of which relays an event has been seen on and which relays a user is posting to and reading from. The trade-off between longer identifiers and better interoperability is worth it if we want to make the nostr network decentralized and resilient. You can use tools such as [nak](https://nak.nostr.com/) to get familiar with the different types of identifiers, add or remove metadata to your identifiers and decode them.