someone on Nostr: Open weights that depend on a single host are not really open With BitTorrent, ...

Open weights that depend on a single host are not really open

With BitTorrent, bandwidth pooling happens by design. Every downloader is a potential uploader, so popularity grows capacity instead of straining it. A viral 70B release that 5000 people want simultaneously will melt a single HTTP origin; on a swarm, those 5000 peers are the swarm.

The genuine weakness of torrent distribution is seeder attrition — old swarms die. This project handles it on two fronts. First, webseeds: every .torrent has HTTP webseed URLs embedded, so a BEP-19-aware client (Transmission is the reference) can fetch the full payload over HTTP, piece-verified against the torrent's hashes, even with zero peers. For HuggingFace-mirrored models the webseeds point at huggingface.co/<org>/<repo>/resolve/, which means every webseed download is a continuous cryptographic audit of HF's served bytes against the curator's snapshot — if HF silently swaps a shard or a CDN edge caches a truncated file, the piece hash fails. The signed `hf_match` tag asserts whether the torrent is a byte-exact mirror of the HF repo, and the webseed mechanism lets anyone independently verify that without trusting HF, the curator, or the relay.

Second, on-protocol demand signaling. Users signal dead swarms with a proof-of-work-backed Nostr event (kind 30103). The PoW makes spam expensive, so the signal stays meaningful. Curators watching the relay can see which models people actually want and re-seed them — turning "nobody knows this is unreachable" into "twelve people asked this week."

What Nostr adds on top

BitTorrent gives you transport, not discovery. Historically, torrent catalogs lived on websites — seizurable, suable, corruptible. This project uses Nostr as the catalog. Listings (kind 30099) are signed events carrying the .torrent URL, metadata, and source reference, propagating across nine relays run by different operators. If one disappears, the other eight still serve every listing. If an operator dislikes a model, they can delist it on their relay — but not on anyone else's. Censorship becomes a local opt-out, not a global deletion.

Catalog and transport are decoupled: the Nostr event tells you a torrent exists and where the .torrent is; the .torrent tells your client how to join the swarm; the swarm moves the bytes. No single component can be shut down — you'd need to shut down every relay, every .torrent host, and every seeder simultaneously.

Failproof distribution, by construction

- Discovery is redundant across nine independently-operated Nostr relays. Listings are signed by the whitelisted curator npub and verified client-side, so a malicious relay cannot forge or alter one.

- The .torrent file is a small, cacheable blob hostable anywhere. The client checks its info-hash against the signed Nostr event before passing it to the BT client, so a compromised host cannot swap in a tampered torrent.

- The weights live on the swarm. One laptop on a residential connection in the right timezone is enough to keep a 13B model alive for the next person who needs it.

An open, forkable catalog

The listings are not the private property of this HTML page. Every kind 30099 event lives on the Nostr network, signed and queryable by anyone. A developer who wants a different UI, disagrees with the curator's taste, or needs listings filtered for a specific use case can ship their own client — web page, CLI, desktop app — and pull the exact same signed events over the exact same relays, no permission or API key required. The catalog is a public, append-only, cryptographically-signed event stream. Clients are views onto that stream, not privileged gatekeepers. Anyone can fork this HTML, modify it, and publish the result; the network effect accrues to the protocol, not to any single client.

Standalone and self-upgrading

The HTML client requires no website, backend, or build step. Saved to disk, opened from file://, mirrored on any static host — it behaves identically, because all work happens client-side. There is no deploy to take down, no domain to seize, no server bill to default on. Distribution of the client is itself peer-to-peer.

The client is upgradable by its maintainer, but the upgrade path is tamper-evident. The running HTML listens to Nostr for kind 30100 events signed by the curator npub. When an event announces a higher version, the client fetches the candidate HTML from the Blossom URLs in the event, computes its SHA-256, and compares against the signed sha256 tag. Only if the hash matches — proving the bytes the maintainer signed are the bytes the host served — does it surface the new version as a verified update, offered as a local blob URL. A compromised host cannot push malicious HTML: the signed hash authorizes the bytes, not the host's say-so. Upgrades are opt-in and reversible — the user retains the version they are running until they choose otherwise. Combined with forkability, the maintainer's authority is strictly over what gets offered as an upgrade, not over what users must run.