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, rendering QR codes or referencing entities in text content.
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 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 fields. Check out NIP-19 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 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 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 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 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 to get familiar with the different types of identifiers, add or remove metadata to your identifiers and decode them.