< the skull

HOW USENET SERVES FILES
=======================
2026-06-14

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.

Then, as usually happens on the internet, someone looked at that system and
thought: “What if I put files in here?”

And that is exactly what happened.

Usenet 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.

It sounds like a hack, and it is. But it is a very clever hack.

The file is not uploaded as one piece
-------------------------------------

When 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.*`.

A single file can become hundreds or thousands of separate messages.

The simplified flow looks like this:

  original file
  → split into parts
  → encoded into a message-friendly format
  → posted as multiple NNTP articles
  → stored by Usenet servers
  → downloaded by a client
  → decoded
  → reassembled
  → final file

So 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.

That distinction matters.

yEnc: the boring but essential magic
------------------------------------

In the early days, encodings like `uuencode` were common. Later, `yEnc` became
the de facto standard for binaries on Usenet.

The 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.

So 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.

The regular user does not need to see this process. The download client handles
it automatically.

The `alt.binaries.*` groups
---------------------------

The file-sharing side of Usenet became strongly associated with the
`alt.binaries.*` hierarchy.

Examples include:

  alt.binaries.movies
  alt.binaries.multimedia
  alt.binaries.sounds
  alt.binaries.pictures
  alt.binaries.ebooks
  alt.binaries.software

The name gives away the purpose: these groups are meant for binary content, not
just text conversations.

Technically, 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.

Because text is cheap. Binary data is not.

Keeping text discussions for years is relatively easy. Keeping large files for
years requires a lot of disk, bandwidth, and administrative discipline.

Why so many RAR files?
----------------------

Anyone who has dealt with Usenet binaries has probably seen sets like this:

  file.part001.rar
  file.part002.rar
  file.part003.rar
  file.part004.rar
  ...

That 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.

So the original content is often compressed and split into multiple RAR volumes
before being encoded and posted as articles.

In the end, you have layers on top of layers:

  original file
  → RAR volumes
  → smaller pieces
  → yEnc articles
  → NNTP messages

It may look excessive, but it solves real problems.

PAR2: insurance against missing pieces
--------------------------------------

Usenet 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.

That is where PAR2 files come in.

`.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.

A set may look like this:

  file.part001.rar
  file.part002.rar
  file.part003.rar
  file.part004.rar
  file.vol000+01.par2
  file.vol001+02.par2
  file.vol003+04.par2

If 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.

Still, 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.

NZB: the treasure map
---------------------

Now comes a central piece: the NZB file.

Imagine a file split into 3,000 NNTP articles. How would a user find all those
articles manually? They would not. It would be impossible.

The `.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.

The client reads the NZB and thinks:

“Alright, I need to fetch these 3,000 articles from the NNTP server.”

Then 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.

In short:

  NZB = map of the articles
  NNTP = protocol used to fetch the articles
  Usenet server = where the articles are stored
  client = software that downloads, repairs, and rebuilds everything

The NZB does not contain the file itself. It contains the instructions for
finding the file’s pieces inside Usenet.

It 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.

Does the server know what it is delivering?
-------------------------------------------

Most of the time, the server does not need to understand the final file. It only
stores articles.

An NNTP client asks for something like:

  ARTICLE <some-message-id>

The 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.

That separation is the whole trick.

The intelligence is mostly on the client and indexer side, not in each
individual server.

The role of commercial providers
--------------------------------

Today, 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.

The key word here is retention.

Retention 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.

When 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.

That 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.

Usenet is not torrenting
------------------------

People often compare Usenet with BitTorrent, but the logic is very different.

With BitTorrent, users download pieces from each other. A file exists as long as
there are seeders. You participate in a peer-to-peer swarm.

With 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.

Put simply:

  BitTorrent:
  - users share with each other
  - depends on seeders
  - decentralization lives in the peer swarm
  - you usually upload while downloading
  
  Usenet:
  - you download from NNTP servers
  - depends on provider retention
  - decentralization comes from the old server federation model
  - you do not need to upload to other users

Usenet 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.

Can you run a server like that?
-------------------------------

Technically, yes.

Practically, that is a different conversation.

Running 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.

Running a public or federated binary server is much heavier. You need to deal
with:

  huge storage requirements
  heavy bandwidth
  short or expensive retention
  spam
  abuse
  problematic content
  legal notices
  authentication
  peering
  queues
  constant monitoring

If you accept groups like `alt.binaries.*`, data growth can become brutal. This
is not something you throw onto a cheap VPS and forget about.

If the goal is to learn, the smart path is to create a small private binary
group, for example:

  local.binaries.test

Then 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.

The short version
-----------------

Usenet serves files without really being made to serve files.

It 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.

The complete process looks like this:

  original file
  → compression/splitting into RAR volumes
  → yEnc encoding
  → posting as NNTP articles
  → storage on Usenet servers
  → NZB indexing
  → client download
  → PAR2 repair
  → final file reconstruction

It 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.


< the skull