Building Torrentium: File Transfer Without a File Server

A file has bytes, a name, and—on most systems—a location. Peer-to-peer software has to make the location optional.

When you upload to a conventional file-sharing service, one company quietly handles every hard step. It stores the bytes, gives them an address, keeps a directory, accepts incoming connections, retries failures, and pays for enough bandwidth to remain available.

Torrentium removes that file server from the data path. The sender and receiver should exchange content through the peer network. That sounds simpler. It actually exposes the jobs the server used to hide.

The application must describe the file without trusting its filename, find a peer that has it, establish a path through NAT and firewalls, move pieces efficiently, and verify that the reconstructed result is correct.

Peer-to-peer architecture does not eliminate coordination. It redistributes coordination across protocols with narrower responsibilities.

Name the Content, Not Its Location

A URL usually says where to ask. A content identifier says what bytes to expect.

Torrentium derives an identifier from the content. If one byte changes, the digest changes. A peer can download from any provider and still perform the same integrity check at the transfer boundary.

This is a strong integrity mechanism, not a claim that the file is safe or that the person who shared its identifier is trustworthy. A hash can show that the received bytes match the expected bytes. It cannot tell you whether those bytes contain malware or whether the human description was honest.

Find Providers Without a Catalogue

Once a client has a content identifier, it still needs a machine that can provide the bytes. A central catalogue would solve that immediately—and recreate the single dependency the project is trying to avoid.

Torrentium uses a Kademlia distributed hash table for provider discovery. A peer announces that it can serve a content identifier. The DHT stores provider information near the corresponding key in its identifier space. A downloader follows progressively closer peers until it finds useful provider records.

The DHT carries small discovery records, not the file. That makes the lookup path light enough to distribute while leaving large transfers to connections built for streaming bytes.

A record is also only a lead. The advertised peer may have disconnected or moved. Discovery needs expiration, multiple candidates, and fallback—not blind confidence in the first result.

Cross the NAT Boundary

Most personal devices do not have a public address waiting for strangers to connect. They sit behind routers that translate internal addresses and discard unsolicited inbound traffic.

Think of an apartment building with one street address. Outgoing mail is easy because the front desk knows which apartment sent it. Unexpected incoming visitors are harder: they need an apartment number, a cooperative desk, or someone inside to arrange the meeting.

libp2p and WebRTC provide the connection machinery around that problem: discover usable addresses, negotiate candidates, attempt hole punching when the network permits it, and use a relay when a direct path cannot be established and relay infrastructure is available.

A relay is a fallback, not a failure of the design. It trades some directness and cost for reachability. Real peer-to-peer software needs that trade-off because two perfectly healthy devices can still be separated by incompatible network policies.

Move Pieces, Not One Fragile Stream

Sending one huge byte stream creates an unpleasant failure mode: if the connection disappears near the end, the application may have little useful state to resume from.

Torrentium splits data into chunks, moves work across available connections, and verifies chunks at transfer boundaries. Parallelism can use capacity that a single path leaves idle. It also creates new responsibilities: backpressure, ordering, retry limits, duplicate chunks, and a clear definition of completion.

SQLite-backed local state gives the client somewhere durable to remember transfers and progress. Resumability is not merely a convenience feature; it is how the application converts peer disappearance from catastrophe into recoverable work.

Let Each Layer Make One Promise

The system becomes easier to reason about when each layer answers a different question:

No layer is asked to prove more than it knows. The DHT does not establish content integrity. The hash does not authenticate a person. WebRTC encryption does not decide who should be authorized to request a file.

“Serverless” Does Not Mean Infrastructure-Free

Torrentium avoids putting one application server in the middle of every transfer. It can still depend on bootstrap peers, DHT participants, address-discovery services, and relays.

The distinction is about control and the data path. A bootstrap peer can introduce a new participant without owning every future lookup. A relay can help two restricted peers communicate without becoming the permanent home of the file. Infrastructure remains, but its roles are distributed and replaceable.

What Building It Changed

The clean architecture diagram is not where most engineering time goes. The hard work lives in the negative space:

• A lookup returns peers, but none is reachable.
• A direct connection fails after most chunks arrive.
• Two retries return the same piece out of order.
• A peer advertises content it no longer has.
• The UI must explain waiting without pretending the network is frozen.

Those are not edge cases in a distributed system. They are the normal operating environment.

Torrentium taught me that decentralization is not the absence of coordination. It is coordination without allowing one machine to know or control everything.