{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigwu3qnk7ktc5lrzdtt7ycq6afh6gfanmcvng67xhyl3qtxqq5mwm",
    "uri": "at://did:plc:iw5jw32bqqdf4bkbhotvf23m/app.bsky.feed.post/3mobw24obwph2"
  },
  "description": "There is something fascinating about Usenet: it was not created as a file download system. Its original purpose was much simpler and, in a way, more elegant. It was made to distribute messages. Text. Discussions. Forums before modern forums. People posted to groups, servers exchanged articles, and NNTP clients downloaded messages and replies.\n\n\nThen, as usually happens on the internet, someone looked at that system and thought: “What if I put files in here?”\n\n\nAnd that is exactly what happened.\n",
  "path": "/how-usenet-serves-files/",
  "publishedAt": "2026-06-14T23:23:40.000Z",
  "site": "https://pablomurad.com",
  "textContent": "There is something fascinating about Usenet: it was not created as a file download system. Its original purpose was much simpler and, in a way, more elegant. It was made to distribute messages. Text. Discussions. Forums before modern forums. People posted to groups, servers exchanged articles, and NNTP clients downloaded messages and replies.\n\nThen, as usually happens on the internet, someone looked at that system and thought: “What if I put files in here?”\n\nAnd that is exactly what happened.\n\nUsenet does not serve files the way HTTP, FTP, or BitTorrent do. It was not designed to say: “Here is `video.mkv`, download it.” What Usenet does is store and distribute articles. So the solution was to turn files into articles.\n\nIt sounds like a hack, and it is. But it is a very clever hack.\n\n## The file is not uploaded as one piece\n\nWhen someone posts a large file to Usenet, the file is not uploaded as a single block. That would be impractical. Instead, the file is split into many smaller pieces. Each piece is encoded into a format that can travel inside an NNTP message, and those messages are posted to specific newsgroups, usually under `alt.binaries.*`.\n\nA single file can become hundreds or thousands of separate messages.\n\nThe simplified flow looks like this:\n\n\n    original file\n    → split into parts\n    → encoded into a message-friendly format\n    → posted as multiple NNTP articles\n    → stored by Usenet servers\n    → downloaded by a client\n    → decoded\n    → reassembled\n    → final file\n\n\nSo the Usenet server is not “serving a file” in the traditional sense. It is serving articles. The client understands that those articles, together, form a file.\n\nThat distinction matters.\n\n## yEnc: the boring but essential magic\n\nIn the early days, encodings like `uuencode` were common. Later, `yEnc` became the de facto standard for binaries on Usenet.\n\nThe role of yEnc is to take binary data and encode it in a way that works inside Usenet messages. It is more efficient than older methods because it wastes less space. When you are dealing with millions of messages and very large files, that difference matters.\n\nSo when a file is posted, it is broken into chunks, and each chunk is encoded with yEnc. Each chunk becomes an NNTP article whose body may look like nonsense if you view it raw. But to a Usenet client, it is a perfectly valid piece of a larger file.\n\nThe regular user does not need to see this process. The download client handles it automatically.\n\n## The `alt.binaries.*` groups\n\nThe file-sharing side of Usenet became strongly associated with the `alt.binaries.*` hierarchy.\n\nExamples include:\n\n\n    alt.binaries.movies\n    alt.binaries.multimedia\n    alt.binaries.sounds\n    alt.binaries.pictures\n    alt.binaries.ebooks\n    alt.binaries.software\n\n\nThe name gives away the purpose: these groups are meant for binary content, not just text conversations.\n\nTechnically, a binary file could be posted to other groups too, if the server allows it. But in practice, binaries concentrated in these hierarchies. That also helped servers decide what to accept, what to reject, and how long to keep each kind of content.\n\nBecause text is cheap. Binary data is not.\n\nKeeping text discussions for years is relatively easy. Keeping large files for years requires a lot of disk, bandwidth, and administrative discipline.\n\n## Why so many RAR files?\n\nAnyone who has dealt with Usenet binaries has probably seen sets like this:\n\n\n    file.part001.rar\n    file.part002.rar\n    file.part003.rar\n    file.part004.rar\n    ...\n\n\nThat is not random. RAR became common because it helps split large files into smaller volumes. If something fails, you do not necessarily need to download everything again. These volumes also fit nicely into the Usenet workflow, where everything is already being broken into many smaller parts.\n\nSo the original content is often compressed and split into multiple RAR volumes before being encoded and posted as articles.\n\nIn the end, you have layers on top of layers:\n\n\n    original file\n    → RAR volumes\n    → smaller pieces\n    → yEnc articles\n    → NNTP messages\n\n\nIt may look excessive, but it solves real problems.\n\n## PAR2: insurance against missing pieces\n\nUsenet does not guarantee that every article will arrive intact on every server. One server may miss a part. Another may expire older articles. Another may have corruption. Another may not carry a certain group at all.\n\nThat is where PAR2 files come in.\n\n`.par2` files are recovery files. They use parity data to rebuild missing or damaged parts. In simple terms, they are mathematical backup material for repairing a download.\n\nA set may look like this:\n\n\n    file.part001.rar\n    file.part002.rar\n    file.part003.rar\n    file.part004.rar\n    file.vol000+01.par2\n    file.vol001+02.par2\n    file.vol003+04.par2\n\n\nIf one or two pieces are missing, the client can use the PAR2 files to repair the set. Of course, there is a limit. If too much is missing, there is no magic fix.\n\nStill, this repair layer is one of the reasons Usenet worked so well for large files. Without PAR2, downloading large binary posts would be much more frustrating.\n\n## NZB: the treasure map\n\nNow comes a central piece: the NZB file.\n\nImagine a file split into 3,000 NNTP articles. How would a user find all those articles manually? They would not. It would be impossible.\n\nThe `.nzb` file solves this. It is basically an index, or a manifest. It lists the `Message-ID`s of the articles needed to reconstruct a given file.\n\nThe client reads the NZB and thinks:\n\n“Alright, I need to fetch these 3,000 articles from the NNTP server.”\n\nThen it connects to the server and starts requesting article after article. Once it has the pieces, it joins them, decodes them, repairs them if needed, and gives the user the final file.\n\nIn short:\n\n\n    NZB = map of the articles\n    NNTP = protocol used to fetch the articles\n    Usenet server = where the articles are stored\n    client = software that downloads, repairs, and rebuilds everything\n\n\nThe NZB does not contain the file itself. It contains the instructions for finding the file’s pieces inside Usenet.\n\nIt is similar to the difference between a `.torrent` file and the actual torrent data. The `.torrent` is not the movie, book, or program. It only tells the client where and how to find the pieces. NZB plays a similar role, but inside the Usenet ecosystem.\n\n## Does the server know what it is delivering?\n\nMost of the time, the server does not need to understand the final file. It only stores articles.\n\nAn NNTP client asks for something like:\n\n\n    ARTICLE <some-message-id>\n\n\nThe server responds with the corresponding article. The body of that article contains an encoded chunk, usually in yEnc. To the server, it is just a message. To the client, it is part of a larger file.\n\nThat separation is the whole trick.\n\nThe intelligence is mostly on the client and indexer side, not in each individual server.\n\n## The role of commercial providers\n\nToday, when people talk about downloading from Usenet, they are usually talking about commercial providers. These providers sell access to servers with high retention, high speed, multiple connections, and SSL/TLS.\n\nThe key word here is retention.\n\nRetention means how long the provider keeps articles available. For text groups, keeping years and years of material is relatively cheap. For binary groups, keeping years of content requires massive infrastructure.\n\nWhen a provider says it offers thousands of days of binary retention, it is saying that it keeps old binary articles for many years. That is expensive, because the amount of data in binary groups is enormous.\n\nThat is why modern binary Usenet is not exactly a garage hobby. A text-only server can run on a small VPS. A serious binary server requires huge storage, heavy bandwidth, and a very clear abuse policy.\n\n## Usenet is not torrenting\n\nPeople often compare Usenet with BitTorrent, but the logic is very different.\n\nWith BitTorrent, users download pieces from each other. A file exists as long as there are seeders. You participate in a peer-to-peer swarm.\n\nWith Usenet, you download from a server. You do not need to upload pieces to other users. Availability depends on the retention of the server or provider, not on seeders.\n\nPut simply:\n\n\n    BitTorrent:\n    - users share with each other\n    - depends on seeders\n    - decentralization lives in the peer swarm\n    - you usually upload while downloading\n\n    Usenet:\n    - you download from NNTP servers\n    - depends on provider retention\n    - decentralization comes from the old server federation model\n    - you do not need to upload to other users\n\n\nUsenet ends up feeling more like downloading from a premium server, even though underneath it all there is this older structure of articles, groups, propagation, and retention.\n\n## Can you run a server like that?\n\nTechnically, yes.\n\nPractically, that is a different conversation.\n\nRunning a text-only NNTP server is completely realistic. You install something like INN, create a few groups, control access, configure TLS, and use it with an NNTP reader. For learning, small communities, or internal projects, it is a great experiment.\n\nRunning a public or federated binary server is much heavier. You need to deal with:\n\n\n    huge storage requirements\n    heavy bandwidth\n    short or expensive retention\n    spam\n    abuse\n    problematic content\n    legal notices\n    authentication\n    peering\n    queues\n    constant monitoring\n\n\nIf you accept groups like `alt.binaries.*`, data growth can become brutal. This is not something you throw onto a cheap VPS and forget about.\n\nIf the goal is to learn, the smart path is to create a small private binary group, for example:\n\n\n    local.binaries.test\n\n\nThen you can post small files, see how yEnc works, generate NZBs, download with a client, and understand the whole flow without drowning in terabytes of data and legal headaches.\n\n## The short version\n\nUsenet serves files without really being made to serve files.\n\nIt stores articles. People learned to break files into pieces, encode those pieces, post them as NNTP messages, and reconstruct the file on the other side.\n\nThe complete process looks like this:\n\n\n    original file\n    → compression/splitting into RAR volumes\n    → yEnc encoding\n    → posting as NNTP articles\n    → storage on Usenet servers\n    → NZB indexing\n    → client download\n    → PAR2 repair\n    → final file reconstruction\n\n\nIt is old, strange, and a little underground, but it is also incredibly clever. The modern web tries to hide complexity behind polished buttons. Usenet does not. Usenet shows the gears. And maybe that is exactly what makes it so interesting.",
  "title": "How Usenet Serves Files",
  "updatedAt": "2026-06-14T23:23:41.177Z"
}