NIP-73: External Content IDs
The outside world already has identifiers
Nostr does not need to invent identifiers for books, films, papers, podcasts, web pages, places or blockchain transactions. Those worlds already have ISBNs, ISANs, DOIs, podcast GUIDs, URLs, geohashes, ISO country codes and transaction IDs.
NIP-73 gives clients a shared way to attach those identifiers to Nostr events. That lets people query every review, comment, highlight, bookmark, note or article tied to the same outside object.
The standard is small but very useful for media, commerce, comments, books, podcasts, maps and research.
i tags identify the object, k tags identify the namespace
The i tag carries the actual external identifier. The k tag carries the identifier kind. For a web page, i is the normalized URL and k is web. For a book, i is isbn: plus the ISBN without hyphens and k is isbn.
The supported table covers web, books, geohashes, ISO 3166 countries and subdivisions, movies, papers, hashtags, podcast feeds, podcast episodes, podcast publishers, blockchain transactions and blockchain addresses.
NIP-22 comments use these values for scoped external comments. That makes NIP-73 part of the comment and media layer, not only a metadata appendix.
Oscar Merry opened the door, then the identifier list widened
Oscar Merry drafted external content IDs in April 2024 and added several expansions across 2024, including podcast publisher GUIDs and broader identifier examples. Xavier Damman added blockchain transactions and addresses in April 2025. Alex Gleason added ISO 3166 countries in January 2026.
The history shows NIP-73 doing what a registry-like NIP needs to do: start with obvious identifiers and add namespaces when real use cases appear.
The page needs to resist treating the list as complete forever. The model is extensible because the outside world has many identifier systems.
Normalization is the hard boring part
A client implementing NIP-73 must normalize identifiers exactly: URL fragments removed where required, ISBN hyphens stripped, geohashes lowercase, ISO codes uppercase and DOIs lowercase. Sloppy normalization splits one object into many query islands.
The product payoff is strong. A book client can show every Nostr note about an ISBN. A podcast client can collect comments around an episode GUID. A web-comment client can attach Nostr discussion to a page without asking the page owner for an API.
A good UI needs to show both the readable object and the raw identifier so users can understand what is being grouped.
Bad IDs create false neighborhoods
If a client normalizes URLs or ISBNs badly, unrelated objects can merge or one object can split into many threads. That damages search and comments.
External IDs also import outside-world authority. An ISBN or DOI is useful, but clients need to not imply that every event tagged with it is verified by the publisher.
Read NIP-73 in the wild
NIP-73 gives external content IDs a portable form. It lets Nostr conversations cluster around books, podcasts, videos, web pages, Git commits and other objects that did not originate on Nostr.
The hard problem is canonical identity. Two links may point to the same thing, and one link may change. Good clients normalize carefully and show the original reference.
What changes when you actually use it
For you, NIP-73: External Content IDs is felt when a post becomes a durable object: article, file, image, video, audio, bookmark, wiki entry or source reference. The question is whether the work still makes sense after one app, host or relay disappears. The concrete pieces draft, <id, without hyphens>, <id, without version part>, <id, lowercase>, <guid>, <chainId> decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-73: External Content IDs is context preservation. Store enough title, tag, author, hash, URL, media, preview and reference material that another interface can rebuild the object. If your feature depends on a private database to make sense, the NIP is not doing the portability work yet.
What the official file makes concrete
The official file is organized around Supported IDs, Examples, Webpages, Geohashes:, Countries:, Books:, Podcasts:, Movies:. Inspect draft, <id, without hyphens>, <id, without version part>, <id, lowercase>, <guid>, <chainId>, <txid, hex, lowercase>, ["i", "podcast:guid:c90e609a-df1e-596a-bd5e-57bcc8aad6cc"] because these are the pieces most likely to surface as product behavior.
NIP-73: External Content IDs protects context. Titles, media, hashes, source links, timestamps and references decide whether work survives beyond one app.
Where it breaks
The failure mode in NIP-73: External Content IDs is link rot with a nice interface. Media disappears, metadata lies, source URLs change, hashes are missing or an article loses its addressable identity. The page needs to make durability part of the feature, not an afterthought.
Where this appears outside the markdown
In the ecosystem, NIP-73: External Content IDs is part of the creator and archive layer. It decides whether writing, media, files, bookmarks, wiki material or source references remain understandable after the first app disappears. That is why media standards need to talk about storage, provenance and recovery, not only presentation.
The nearby-standard trap
The nearby-standard trap in NIP-73: External Content IDs is flattening every creative object into a note with a link. Articles, videos, files, torrents, highlights, images, wiki entries and bookmarks carry different metadata and storage pressure. Read NIP-01 and the adjacent source links so the product does not throw away the part that made the object portable.
Language that keeps the feature honest
Good product copy for NIP-73: External Content IDs names the object and the storage. It says article, file, image, video, bookmark, wiki page, torrent, highlight or podcast episode, then tells you where the signed metadata ends and where external hosting begins.
What this page does not promise
NIP-73: External Content IDs does not guarantee that published work survives forever. It can carry richer metadata, hashes, references or addressability, but files still need hosts, relays still need retention, and clients still need to render the object faithfully. Treat the NIP as the signed map of the work, then check where the actual bytes, previews and source links live.
Read it as a field test
Start NIP-73: External Content IDs with the object you want to keep: article, file, media, bookmark, repository, torrent, wiki entry or podcast episode. Then trace which parts are signed, which parts are hosted, and which parts another client can reconstruct from draft, <id, without hyphens>, <id, without version part>, <id, lowercase>, <guid>, <chainId>. That is the difference between portable publishing and a pretty link preview.
Where the standard earns trust
The source links give you places to test the interpretation in public: NIP-22 Comments, Podcast GUID namespace, DOI Foundation, ISAN. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-73 source is the anchor for exact wording, and NIP-73 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-22 Comments, Podcast GUID namespace, DOI Foundation. 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-73: External Content IDs: first the human promise, then draft, <id, without hyphens>, <id, without version part>, <id, lowercase>, <guid>, <chainId>, then the implementation record, then the real-world failure case. That order keeps NIP-73 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Where do the signed metadata and the actual media or file bytes part ways?
- Can the object still be identified by hash, address, title, author and source if the first URL breaks?
- Does a second client know enough from
draft,<id, without hyphens>,<id, without version part>,<id, lowercase>to render the work without private context?
What to verify before you rely on it
- Find
draft,<id, without hyphens>,<id, without version part>,<id, lowercase>,<guid>in 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-73 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-73: External Content IDs in that order: Official NIP-73 source for the current wording; NIP-73 commit history for the change record; NIP-22 Comments, Podcast GUID namespace, DOI Foundation 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.
