NIP-35: Torrents
A torrent index, not a file host
NIP-35 is easy to misunderstand if you read the word torrent and think Nostr is suddenly storing media files. It is not. The NIP defines a torrent announcement event. The torrent data still lives in the BitTorrent world. Nostr carries searchable metadata: title, info hash, file list, trackers, categories and external media identifiers.
That makes the standard useful in a very specific way. It gives Nostr clients a shared shape for publishing and discovering torrents while leaving distribution to magnet links, trackers and peers. The relay is an index and conversation layer, not the download network.
This belongs in the Nostr archive because it shows how broad event publishing can become. Nostr can carry social notes, long-form posts, file metadata, marketplace listings and also torrent indexes. The question is not whether every client needs to become a torrent app. The question is whether specialist clients can publish enough structure for search, comments and interoperability.
Kind 2003, info hashes, file tags and outside catalog IDs
A NIP-35 torrent uses kind 2003. The key tag is x, carrying the BitTorrent v1 info hash used in a magnet link. File tags can list paths and byte sizes. Tracker tags can provide tracker URLs. Topic tags such as movie, tv, HD or UHD make ordinary relay search more useful.
The more interesting part is the i tag namespace for outside catalogs. The source names prefixes such as imdb, tmdb, ttvdb, mal, anilist, newznab and tcat. Those tags let a torrent event point at recognized media databases without embedding a private catalog format.
Torrent comments use kind 2004 and follow ordinary reply conventions. That matters because torrent discovery is not only a hash lookup. People want comments, warnings, context and quality signals around a torrent. NIP-35 gives those comments a Nostr-native event kind instead of leaving them inside a single tracker site.
A compact media NIP with a moved-drafts footnote
The visible NIP-35 history begins in April 2024 with Kieran Harkin's torrent work. Later changes adjusted tag keys, made comments explicit and aligned info-hash indexing with file metadata patterns. Vitor Pamplona's May 2024 history is notable because draft behavior moved out toward NIP-37, leaving NIP-35 focused on torrents rather than private draft storage.
The file has stayed relatively compact. That is appropriate. Torrent metadata does not need a giant social model. It needs a stable event kind, a searchable hash, clear file metadata, optional trackers, useful category tags and a comment path.
The important editorial point is that compact does not mean trivial. A torrent event can point at copyrighted, harmful, malicious or misleading content. The standard can define the shape, but clients and communities still decide policy.
dtan, nostrudel and rust-nostr show where support appears
The official NIP names dtan.xyz and nostrudel.ninja as implementations. dtan is the obvious specialist direction: a torrent discovery surface built around this event shape. nostrudel's torrent view shows the other path, where a broader Nostr client experiments with a specialized route.
Rust-nostr documentation exposes a nip35 module with Torrent and TorrentFile structures. That kind of library support matters because it lowers the cost for additional clients to parse kind 2003 events correctly instead of treating them as raw custom data.
A useful client needs to prove three things. First, it can build a magnet link from the hash and metadata. Second, it can search by category and external IDs without inventing a private index. Third, it can show comments and warnings without pretending it has verified the safety or legality of the underlying content.
Searchability brings moderation and safety questions
The main risk is that searchable metadata makes problematic content easier to find. NIP-35 does not and cannot solve copyright, malware, illegal content or deceptive labeling. It gives clients a shape for torrent data. Operators and communities still need policy.
The second risk is false completeness. A magnet-ready event may still have dead trackers, no seeders, inaccurate files or misleading external IDs. Clients need to treat torrent events as claims that can be inspected, commented on and filtered, not as verified download recommendations.
Read NIP-35 in the wild
NIP-35 lets torrent metadata live as signed Nostr events. That can make discovery and commentary around torrents portable while the actual file distribution remains in the torrent network.
The legal and safety boundary is obvious. A signed torrent event does not make the underlying file lawful, safe or available. Clients need to expose hashes, trackers, magnet data and reporting paths clearly.
What changes when you actually use it
For you, NIP-35: Torrents 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 2003, kind 2004, kind 1, draft, file, info/example.txt decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-35: Torrents 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 Tags, Tag prefixes, Torrent Comments, Implementations. Inspect kind 2003, kind 2004, kind 1, draft, file, info/example.txt, movie, HD because these are the pieces most likely to surface as product behavior. Read it beside NIP-10 before treating it as isolated.
NIP-35: Torrents 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-35: Torrents 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-35: Torrents 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-35: Torrents 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-10 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-35: Torrents 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-35: Torrents 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-35: Torrents 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 2003, kind 2004, kind 1, draft, file, info/example.txt. 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: dtan implementation, nostrudel torrent view, rust-nostr NIP-35 module, BitTorrent BEP-0053. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-35 source is the anchor for exact wording, and NIP-35 commit history shows how that wording moved over time. The strongest secondary clues here are dtan implementation, nostrudel torrent view, rust-nostr NIP-35 module. 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-35: Torrents: first the human promise, then kind 2003, kind 2004, kind 1, draft, file, info/example.txt, then the implementation record, then the real-world failure case. That order keeps NIP-35 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 2003,kind 2004,kind 1,draftto render the work without private context?
What to verify before you rely on it
- Find
kind 2003,kind 2004,kind 1,draft,filein the official file and check where the UI exposes the same concept. - Read NIP-10 as context before treating NIP-35 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-35: Torrents in that order: Official NIP-35 source for the current wording; NIP-35 commit history for the change record; dtan implementation, nostrudel torrent view, rust-nostr NIP-35 module 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.
