CraysDTAN
DTAN is a NIP-35 torrent index on Nostr: a web client and server stack for publishing torrent metadata, browsing categories and constructing magnet links without storing torrent files on Nostr.
The directory is not the archive
DTAN is one of those Nostr apps that looks small until you ask the right question. At first glance it is a torrent directory: browse categories, search, open a detail page, copy a magnet link. That sounds almost too familiar. The interesting part is where the directory lives. A normal torrent index is a website with a database behind it. If the site disappears, the map disappears with it. DTAN asks a different question: what if the map is made of signed Nostr events that other relays and clients can carry?
That does not make DTAN magic. It does not seed files for you. It does not turn legal risk into mist. It does not make every torrent healthy. What it does is narrower and better defined: it indexes torrent metadata. A DTAN entry can contain a title, a description, file names and sizes, tracker URLs, category tags and external database references. From that, the app can construct a magnet link. The data that says "this torrent exists" can move through Nostr; the actual content moves through BitTorrent.
This distinction matters because it keeps the product honest. Nostr is not being used as a file dump. It is being used as a public, signed, relay-distributed catalog layer. If you are trying to understand what Nostr can do beyond social notes, DTAN is a useful specimen. It shows the protocol as a shared index for things that live elsewhere.
The public trail points to dtan.xyz for the running client and to the v0l/dtan repository for the code. The project name is spelled out in the README as Distributed Torrent Archive on Nostr. As of this review on June 6, 2026, the GitHub repository is public, owned by v0l, describes itself as a torrent index on Nostr, uses TypeScript as its primary language, links back to dtan.xyz, and carries the topics Nostr, torrent and censorship-resistance.
What DTAN actually publishes
The center of DTAN is NIP-35. The spec defines torrent events as kind 2003. That event is not a torrent file. It is enough metadata to search, display and build a magnet link. The crucial tag is x, the BitTorrent info hash used in magnet:?xt=urn:btih:.... Other tags can describe files, trackers, categories and external IDs.
Read that slowly and DTAN becomes much easier to judge. The event can say: here is the title, here is the info hash, here are the files, here are optional trackers, here is a category such as video/movie/4k, and here are IDs that point to IMDb, TMDB, TVDB, MyAnimeList, AniList or Newznab. That is why DTAN pages can feel closer to a library card than to a raw swarm. The card can be indexed, searched and discussed even though the files themselves are not present on the Nostr network.
The DTAN client implements this model directly. Its NostrTorrent model reads tags from an event, tracks the info hash, file list, trackers, labels and proof-of-work value, and builds a magnet link. If an event has no trackers, the client can fall back to a small built-in tracker list. It also maps several external ID types into normal web links, so an event can connect a torrent entry to a movie, anime or catalog record without turning that outside database into DTAN's source of truth.
The official NIP also defines torrent comments. DTAN's detail screen leans into that social layer: it can show the publisher profile, the file tree, related torrents, comments, zaps when a Lightning address is available, and an option to copy the raw JSON event. That last button is not glamorous, but it is very Nostr. It says: the object is not hidden inside a private database. It is an event you can inspect.
The client: search, import, sign
The web client is built like a modern Nostr app, not like an old torrent forum with a protocol sticker glued on top. The public package file shows a TypeScript, React and Vite stack, run with Bun scripts, React Router, Tailwind, and Snort's Nostr system libraries. It uses @snort/system, @snort/system-react and @snort/worker-relay, plus hashing, markdown and QR code packages. There is also a deployment script for Cloudflare Pages via Wrangler, though the live project you see is the DTAN site itself.
The route map is simple in the good way: home, profile, new torrent, torrent detail, search, categories, relays and login. The home page browses the top categories. The search page asks Nostr relays for kind 2003 events, can apply search text, category tags and label filters, and includes a relay for search alongside the user's configured relays. The default relay list in the code includes wss://nos.lol/, wss://relay.damus.io/, wss://relay.primal.net/, wss://relay.snort.social/ and wss://relay.dtan.xyz.
The most revealing screen is the new-torrent flow. DTAN can import a .torrent file in the browser, bdecode it, compute the SHA-1 info hash from the torrent's info section, pull out the file list, title, comment and trackers, then let the publisher choose categories and external labels. If the file list is enormous, the client truncates it rather than making a giant event unreadable. When you publish, DTAN creates a NIP-35 event, signs it with your Nostr identity, broadcasts it, and routes you to the new torrent event page.
The login code is also worth noticing. DTAN supports NIP-07 browser signing, NIP-46 remote signing and direct nsec/private-key login. From a user-safety point of view, that list should make you pause. NIP-07 or NIP-46 is the cleaner path for most people because the site does not need your raw secret key. Direct nsec login may be convenient, but convenience is not the same as good key custody. If you use DTAN seriously, use a signer setup you understand.
DTAN also has a Web of Trust flavor through the Snort system setup: it initializes a Nostr system, can build a follow graph, and sets the WoT root to the logged-in public key. That is an important clue about the intended experience. A decentralized directory still needs ways to sort trust, spam and relevance. Without that, a public index becomes noise very quickly.
The server: relay, replica, DHT
There is a second half to DTAN, and it is the half that makes the project more than a web UI. DTAN Server is a Rust project described as a DTAN server and P2P relay. Its README calls it a self-replicating torrent index built on Nostr. The server acts as a Nostr relay for torrent metadata and as a DHT node for peer discovery. In plain terms: it can store and serve the index while also participating in the BitTorrent discovery layer.
The Umbrel App Store listing makes the same point from a self-hosting angle. It lists DTAN Server as a Nostr-based torrent distribution network, version v0.2.0, developed by v0l and submitted by Kieran. Umbrel describes it as a specialized Nostr relay for NIP-35 torrents that combines relay behavior with DHT-based peer discovery and ships with a DTAN web UI for managing torrents and monitoring the relay.
The Rust code is compact and specific. Its package file uses Rust edition 2024 and depends on v0l's nostr-sdk fork, nostr-lmdb, nostr-relay-builder, Tokio, Hyper, Clap, Serde, SHA-1, Mainline DHT and port mapping tools. The main server accepts torrent events, torrent comments, metadata and relay lists, and also follows comments and zap receipts tagged back to torrent events. It can store events in LMDB, connect to bootstrap relays, sync historical events, subscribe for live ones, notify its local relay, and run an HTTP/WebSocket server.
There is a small but important write policy in the server. It can reject event kinds outside the torrent-related set, and it can optionally enforce one torrent event per info hash. That is not a total moderation system, but it shows the project thinking about a directory problem that every index eventually hits: duplicates. A torrent index is not only about finding more. It is also about preventing the map from becoming unusable.
The sample config tells you how it expects to live in the world. It stores data locally, listens on port 8000 by default, can serve the DTAN web build, and bootstraps from relays such as Damus, nos.lol, nostr.band and Snort. It can use DHT peer discovery unless disabled. You can run it from Cargo, from Docker, or as an Umbrel app. That makes DTAN an app for readers, but also a small infrastructure piece for people who want to help replicate the index.
Why this is uncomfortable and useful
DTAN sits in an uncomfortable zone, which is exactly why it is worth writing about carefully. Torrents are not illegal by nature. They are a distribution method. They can move Linux ISOs, public-domain archives, open datasets, game patches, independent media and plenty of things that should not be distributed. A torrent index can point toward lawful material or unlawful material. The protocol does not know the difference. People, relays and law do.
So the adult reading of DTAN is not "cool, censorship resistance." The adult reading is: DTAN separates index, identity, storage, discovery and transfer. The index is Nostr. The publisher is a public key. The content transfer is BitTorrent. The relay may accept or reject events. The DHT may help find peers. Trackers may be present or absent. Seeders may exist or not. The legal responsibility does not disappear just because the catalog entry is an event.
That separation is useful even if you never touch a questionable torrent. It gives builders a pattern. Nostr can be a coordination layer for external resources: signed records, comments, zaps, profiles, relay replication and cross-client visibility. The files, payments, playback, storage or delivery can happen somewhere else. DTAN happens to apply that pattern to torrents, but the lesson is larger than torrents.
It also shows why Nostr apps should not all be judged by the same yardstick. A microblog client lives or dies by conversation flow. A signer lives or dies by permission clarity. A marketplace lives or dies by trust and settlement. DTAN lives or dies by metadata quality, relay availability, duplicate handling, search, signer safety and whether another NIP-35 client can understand the events it creates. noStrudel is listed by the NIP as another implementation, which matters because one-app standards are mostly wishes. A second reader is the beginning of a real surface.
What to check before you trust it
If you open DTAN, do not start by asking whether it feels "decentralized." Start with the object. Pick one entry and inspect what is actually there: title, info hash, files, trackers, category tags, external labels, publisher profile and raw event JSON. Then ask whether the magnet link can be built from the event alone. That is the interoperability test.
Next, check relay behavior. Which relays are you reading from? Are you relying on DTAN's relay, your own relay list, a public search relay or a server you run? If one relay drops an event, can another still return it? If you operate DTAN Server, do you understand what you are storing, what you are broadcasting and what policy you want around duplicates or abusive entries?
Then check signer behavior. Publishing an index entry is public. Your pubkey is attached. If you import a torrent and publish it, you are not merely browsing a website; you are signing a Nostr event that can be replicated. Use NIP-07 or NIP-46 when possible. Avoid handing a raw nsec to a web app unless you have made a deliberate, informed decision and the key is disposable enough for that risk.
Finally, check the legal and human side. DTAN is an index, not permission. A magnet link is not a license. A category label is not a safety guarantee. Relays can moderate. Operators can refuse content. Users can publish bad data. The right way to admire DTAN is not to pretend those issues vanish. It is to see how cleanly the project exposes the boundary: here is a signed catalog entry, here is the network that carries it, here is the outside system that moves the bytes, and here is the responsibility that stays with the people using it.
That makes DTAN a sharp little app. It is not broad, warm or beginner-friendly in the way Damus or Primal can be. It is a tool for people who want to see Nostr doing index work in public. If you are mapping the ecosystem, DTAN belongs on the shelf because it stretches the imagination without hiding the machinery.
Sources worth opening
This article keeps claims close to the public project trail. Start with the spec, then open the client and server code so you can see exactly where Nostr stops and BitTorrent begins.
- DTAN live app
- v0l/dtan GitHub repository
- DTAN README
- NIP-35: Torrents
- DTAN torrent event model
- DTAN publishing flow
- DTAN signer/login code
- DTAN package and frontend stack
- DTAN Server repository
- DTAN Server README
- DTAN Server Rust relay logic
- DTAN Server Cargo dependencies
- DTAN Server on Umbrel App Store
- DTAN on NostrApps
- noStrudel torrent view
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
- NIP-07 browser signer capability
- NIP-10 text note threading
- NIP-11 relay information document
- NIP-19 bech32 encoded entities
- NIP-44 versioned encryption
- NIP-46 remote signing
- NIP-51 lists and mute lists
