NIP-B0: Web Bookmarking
Bookmarks are personal infrastructure, not browser debris
People save links for later reading, research, memory, curation and sharing. Most bookmarking systems lock that behavior inside one browser or service. NIP-B0 makes a web bookmark a signed addressable Nostr event.
The event kind is 39701. The d tag is the URL without the scheme, while clients assume https:// or http://. That makes bookmarks queryable by URL and editable over time.
The content can hold a detailed description. Tags can hold title, topics and first-published time. Replies and comments use NIP-22, so discussion can attach to the bookmark without turning the bookmark itself into a normal note.
An addressable URL object with metadata
NIP-B0 does not try to replace all read-it-later features. It standardizes the object that such apps can share. A bookmark can have a title, tags, published time and a body description. The addressable key lets clients update the same bookmark rather than reposting duplicates.
Because the d tag removes the scheme, clients need to handle canonicalization carefully. The same web page can appear with tracking parameters, mobile domains, trailing slashes or different schemes. Good bookmarking clients need to normalize without destroying meaning.
The standard is useful for link collections, public research libraries, personal archives and community-curated lists.
The NIP grew from practical bookmark-app needs
Sebastian Hagens added more requirements for kind 39701 web bookmarks in April 2025 through PR #1849. fiatjaf uppercased B0 and B7 the same day, and AsaiToshiya cleaned up B0 in August 2025.
External mentions point to a small but real ecosystem. Key Pair discussed bookmarking on Nostr and referenced Pinstr and Yumyu. Awesome Nostr lists Community Curated Nostr Stuff around NIP-B0-style link aggregation.
The best reading is that NIP-B0 gives bookmarking apps a shared spine. The interesting product work is search, reading state, tags, export, comments and trust.
A bookmark client needs to care about canonical URLs
A serious client needs to normalize tracking parameters, preserve the user's chosen title, allow private or public curation choices, show comments through NIP-22 and keep the saved URL easy to export.
Tags needs to support discovery without becoming spam bait. Public bookmark feeds are only valuable when they are curated enough to trust.
The most useful interface is not a feed of links. It is a personal or community library where URLs can be found again.
The hard problem is duplicate and low-quality links
A bookmark standard can fill with scraped links, tracking URLs and duplicates if clients do not normalize and curate. Protocol support is only the first layer.
Public bookmarks can also reveal research interests or private plans. Apps must not assume every bookmark belongs in public.
Read NIP-B0 in the wild
NIP-B0 gives web bookmarks a portable shape. A saved link becomes a signed memory object with context instead of a private browser artifact.
The useful bookmark is not only a URL. Title, tags, description, source identity and archive clues decide whether it still makes sense six months later.
What changes when you actually use it
For you, NIP-B0: Web Bookmarks 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 kind 39701, kind 1111, draft, kind:39701, .content, d decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-B0: Web Bookmarks 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 Format, Metadata, Example event, Replies & Comments. Inspect kind 39701, kind 1111, draft, kind:39701, .content, d because these are the pieces most likely to surface as product behavior. Read it beside NIP-22 before treating it as isolated.
NIP-B0: Web Bookmarks 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-B0: Web Bookmarks 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-B0: Web Bookmarks 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-B0: Web Bookmarks 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-22 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-B0: Web Bookmarks 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-B0: Web Bookmarks 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-B0: Web Bookmarks 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 kind 39701, kind 1111, draft, kind:39701, .content, d. 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: PR #1849, Key Pair episode on bookmarking, awesome-nostr, NIP-22 Comments. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-B0 source is the anchor for exact wording, and NIP-B0 commit history shows how that wording moved over time. The strongest secondary clues here are PR #1849, Key Pair episode on bookmarking, awesome-nostr. 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-B0: Web Bookmarks: first the human promise, then kind 39701, kind 1111, draft, kind:39701, .content, d, then the implementation record, then the real-world failure case. That order keeps NIP-B0 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
kind 39701,kind 1111,draft,kind:39701to render the work without private context?
What to verify before you rely on it
- Find
kind 39701,kind 1111,draft,kind:39701,.contentin the official file and check where the UI exposes the same concept. - Read NIP-22 as context before treating NIP-B0 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-B0: Web Bookmarks in that order: Official NIP-B0 source for the current wording; NIP-B0 commit history for the change record; PR #1849, Key Pair episode on bookmarking, awesome-nostr 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.
