In , 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 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 DHT, was released at the . It could be used to remove the need for BEP 39 and a centralized web server, and store signed information about the updated torrent in the Distributed Hash Table (DHT). DHT is a database maintained autonomously by BitTorrent users all over the world and not a centralized server somewhere. As far as I know, this was never implemented in Maelstrom, but the building blocks were certainly there.
BitTorrent Inc shipped a few test releases of Project Maelstrom between late and early . It then never mentioned it again in public. The project’s website remained on the web until . I’ve reached out to BitTorrent Inc multiple times over the years for comment on what happened to Maelstrom, but I’ve never heard back. So, what happened to it?
In the words of Bram Cohen, the inventor of the BitTorrent protocol and founder of BitTorrent Inc, it was all due to “investor problems.” I’ll not go into details here, but you can read The Inside Story of BitTorrent [Inc]’s Bizarre Collapse in Wired for the full story. Bram Cohen also tells the story using more colorful language in an interview on the Steal This Show podcast (audio via Magnet or YouTube). At about 44 minutes and 20 seconds into the episode. The long and short of it was that new people were put in charge and killed projects like Maelstrom and Bleep (a distributed direct messaging app) in the pursuit of celebrities and “content deals.”
I’ve managed to restore a small piece of file-sharing history: the Maelstrom welcome/onboarding page. This page was Maelstrom users’ first experience with a P2P-powered webpage. The welcome page prominently shows how many devices were actively seeding/sharing the page when you opened it in Maelstrom. (Maelstrom had an undocumented API for accessing peer-counts and details about the torrent.)
BitTorrent attempted to cheat and shipped a copy of this page with every installation. The cheat code was buggy and didn’t work, so people had to download the page files from other BitTorrent users. The welcome page demo was more authentic than intended by its developers.
I’ve kept a torrent client running for over five months, and was able to download 41 % of this six-year-old torrent from about three dozen other users. My torrent client informs me that these peers are still running Project Maelstrom. This is a bit surprising as Maelstrom doesn’t run as a background service nor does it start automatically. People are still using it to this day. IP geolocation suggest these users are primarily located in China.
You can grab a copy of the welcome page and get a piece of BitTorrent history using the links below. The three links at the top require a BitTorrent-compatible client (such as qBitTorrent). The bottommost link only works in the Project Maelstrom browser.
The peer count on the welcome site relies on a Maelstrom-specific API, and will display zero if opened in another web browser. You can still download a copy of Maelstrom via the Internet Archive. Please note that the browser is years out of date and has multiple known security issues. Don’t use it for everyday browsing!
BitTorrent Inc may have abandoned the idea of a distributed web. However, others have since stepped up to the challenge. Beaker Browser is a P2P web browser that picks up where Maelstrom left off. It uses its own Hypercore Protocol which is inspired by BitTorrent, but focuses more on privacy, security, and preserving a persistent history of website changes. You should check it out if you’re interested enough to have read this whole article.