Use cases

You may ask: why would someone build these kind of sites rather than normal HTTP sites?

First off, they’re harder to censor. Because your site is not using the DNS system, but rather a distributed system — the DHT — it’s much harder for entities to stop the propagation of messages in this network.

Secondly, they’re cheaper. No need to buy a server on Amazon or a DNS name — because of the P2P nature of it, you can even host it using your home network. The bandwidth load is shared amongst the users. With HTTP servers, on the other hand, you pay for the whole bandwidth yourself.

Thirdly, they’re more resilient against DDoS attacks. Queries are essentially piece-download requests. DDoS attacks would hence require attacking all the peers in the swarm, which is much more costly than attacking a single HTTP server.

This may be an attractive solution for entities such as the Internet Archive or even Wikipedia, where large sets of data need to be shared and accessed all the time.

More “shady” applications such as The Pirate Bay or KickAssTorrents may decide to use such system — to avoid censorship but also to make it cheaper for them to host — with the size of their user-base, it would be virtually free for them to host their site.

Another interesting application would be a search engine, which, rather than crawling HTTP sites, would crawl TorrentNet sites, along with other data found in the DHT.

This may bring opportunities for new kinds of businesses to thrive off this data — similarly to how Google thrived off of HTTP data.

But more importantly, this system puts the power back in our hands. The Web will never be totally free until certain entities are able to shut down DNS names.

Read-only sites

One major drawback of the TorrentNet system described so far is the fact that sites are read-only. Unlike the Web, users can’t modify the state of a site they’re visiting.

ZeroNet seems to have solved this using central authorities that both users and sites trust. In order for users to “change the state” of a site, they need to get approval from such central authorities.

Currently there’s no facility to achieve this in the BitTorrent network and would require a separate network to handle the communication logic.

A simpler solution would be to combine HTTP sites with TorrentNet sites. Writes would go through HTTP servers. For instance, imagine having a Disqus comment section (which works through HTTP), in a TorrentNet site.

Since a TorrentNet site will execute JS code, there’s nothing stopping it from also executing HTTP requests (via fetch() ) and hence have access to all of the currently used HTTP facilities (Google Ads, Disqus comments, etc.).

The important part is that you still control the site public key. If HTTP services become dishonest with the way they handle users’ writes, for instance by censoring certain comments, site owners are still free to change to other HTTP services, or even simply write their own.

Comparisons with Tor

Tor is different from TorrentNet in the sense that its main focus is anonymity.

Although, in Tor, several computers are used to achieve anonymity, it doesn’t really make it a distributed system: if the server hosting the site is shut down, the site will not be accessible anymore.

TorrentNet on the other hand is peer-to-peer, and even if many different servers are shut down, the site can still continue existing, just like several torrents continue existing nowadays after years and years.

It’s important to note that TorrentNet doesn’t give you anonymity — just like downloading regular torrents, anybody in the swarm can see your IP address. Still, there’s nothing stopping you from using Tor along with TorrentNet if you want to hide your IP address.

Comparisons with ZeroNet & IPFS

ZeroNet seems to be similar to TorrentNet. Sites are accessed using public keys and they share similar censorship resistant properties.

One major difference is that TorrentNet uses the sqltorrent technique to drive interactions on the site. This is currently not possible with ZeroNet as the site is downloaded sequentially, and only the data you already downloaded can be queried.

You cannot tell ZeroNet sites “only download data relating this query”. It will download everything and you can only query things offline.

Sqltorrent functionality might be possible to implement in ZeroNet, however, it’s unclear whether sites are structured as torrents — they would need to be split and shared into pieces in order for sqltorrent to work properly.

IPFS

IPFS, being BitTorrent-based, could easily implement the kind of solution sqltorrent provides. However, as to my knowledge, nothing working has emerged so far in the IPFS community to allow for the sort of functionality we described in this article.

It’s also important to note that IPFS is a completely separate network from BitTorrent. TorrentNet on the other hand uses the same DHT network and the same protocols of BitTorrent — hence is interoperable with existing torrent clients.

Pros & cons

Pros

Hosting your site is as simple as seeding a torrent. No need to buy a domain name or a hosting server. You can easily host your torrent site on your home network and let users visiting your site help you with the hosting.

Since you control your address (public key), which is broadcast via the DHT, it’s much harder for governments and institution to block the content you’re sharing.

Via sqltorrent you drive your users experience by letting them only download pieces of the torrent that are relevant to the users’ interaction. Richer interfaces, such as search-engines, are possible using this technique.

TorrentNet uses the famous libtorrent library, and follows BitTorrent standards, hence should play much nicer with other clients.

Cons

Read-only sites for now. ZeroNet seems to have a solution to this problem but I’m not convinced yet.

Your site doesn’t have a pretty name. Sharing your public key can be much harder than sharing a DNS name.

Slow first-time access to sites. Since DHT lookups are required to find the torrent and to find the peers sharing the torrent, first-time loads of sites will be noticeably slower than HTTP sites.

Conclusion

TorrentNet is still under development. Currently I’m thinking whether the system should exist as a background-service daemon, and have the user-interface run on http://localhost:5999 (or some other port).

Another option would be to bundle it with Electron, but this would require users installing “yet another browser” rather than using their default one.

Special thanks to the people in the #bittorrent IRC channel on freenode for the fruitful discussions, and of course to Steven Siloti for creating sqltorrent.