What happened to BitTorrent’s Project Maelstrom web browser? | Ctrl blog

Daniel Aleksandersen

Daniel Aleksandersen

2020-09-23

7–10-minute read

Share

In April 2015, BitTorrent Inc. announced the public beta of Project Maelstrom; its new experimental peer-to-peer web browser. The browser reimagined the web using the company’s name sake file-sharing protocol. Websites would be distributed equally by its visitors instead of being hosted by an expensive central web server. The company published a beta and some blog posts, but then never mentioned Project Maelstrom again. What happened to it?

Project Maelstrom was launched four years after Opera had launched Opera Unite (Project Alien). Unite gave everyone their own web server built right into its web browser. It enabled anyone to host a website, share photos, and do all sorts of web things like music streaming directly from their own computer. Unite failed to account for people wanting to shut their computers — now servers — off at the end of the day, however.

BitTorrent’s Project Maelstrom sought to fix this limitation by making everyone who visited a website help contribute to its distribution! As long as someone else was hosting a copy of it, you could shut down your computer for the night without taking your website offline with it.

Maelstrom integrated libtorrent, the “mainline” BitTorrent protocol reference implementation, into the Chromium web browser. Maelstrom itself wasn’t open-source, but its two main components were. It enabled anyone to create a website that could be shared directly between visitors over the BitTorrent peer-to-peer (P2P) protocol instead of being served by a centralized server. The concept radically reduced the complexity and cost of distributing a website. Any old computer could act as a mini-server that would act as a backup/availability guarantee for websites with few visitors hosting it.

Maelstrom was truly distributed with supported both tracked and distributed/trackerless BitTorrent transfers. I’ve previously discussed centralized weak points in decentralized web projects. Its only main weak point being a centralized server required for new clients to bootstrap/join the network. I discuss methods for mitigating that weak point in the linked article.

Normally, when you want to download anything over BitTorrent you need a torrent file. Torrent files are manifest files that describe a set of files for transfer over the BitTorrent protocol. These manifests contain cryptographically secured signatures for every file in the torrent. You can’t modify a file without breaking the signature in the torrent! Clients that download a non-matching file will simply reject it and look on the network for anyone else who might have an untampered copy of the file. So, how can you make updates to your BitTorrent-enabled website?

This is where I’ve run into a little bit of a mystery in the story. I’ve spoken with two dozen people in the distributed-web community that remembers Maelstrom. They all swear they remember that it was using an undisclosed secret and proprietary protocol. Memory can be a funny thing, but what they’re really remembering is that BitTorrent Inc failed to communicate properly about how Maelstrom worked.

I’ve read through every bit of documentation, blog posts, forum posts, and other tidbits of information I can find from the company about Maelstrom. For whatever reason, they seemed to think that “it’s built on BitTorrent!” was all the information anyone would ever need. The extent of available “documentation” was ”a developer tool” (a Python script) for creating torrent snapshots of static websites. The tool did little more than turn a folder of files into a torrent. Any existing BitTorrent-compatible program could be used in its stead. That was probably the point they were trying to make, but it’s not how it has been remembered.

Maelstrom exposes an Application Programming Interface (API) to torrent websites that provides the torrent file’s “current hash” and its “latest hash.” This API is the only indication I’ve found in Maelstrom that it could support dynamically updating torrents. VentureBeat quotes a BitTorrent product manager at the time that confirms this: “[Maelstrom’s] biggest limitation is dynamic content.”

This wasn’t an insurmountable challenge, however. Mutable (changing) torrents had already been specified a few years earlier in BitTorrent Protocol Extension (BEP) 35: Torrent Signing and BEP 39: Updating Torrents Via Feed URL. The first protocol extension specified a way to cryptographically sign a torrent file. The second built on that and specified a method for torrent clients to discover updated versions of the same torrent via a syndication feed (“RSS”). The new torrent had to be signed by the same cryptographic key. This method did require a traditional centralized web server to handle the distribution of the feed, however.

Another protocol extension, BEP 44: Storing arbitrary data in the...