How Usenet Serves Files

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