BitTorrent Launches Project Maelstrom, the First Torrent-Based Browser

An anonymous reader writes BitTorrent today announced the first torrent-based browser. Project Maelstorm, as the app is currently called, is being made available as an invite-only alpha to "a small group of testers." Although BitTorrent is in the very early stages of the project (testers are being asked to help assess for usability and reliability), the company strongly believes Maelstrom "is the first step toward a truly distributed web, one that does not rely on centralized servers." This is by no means a new idea from the company: it's the core behind the relatively successful synchronization tool BitTorrent Sync. "Centralized architectures have not scaled well to the volume and size of data moving across the Internet," a BitTorrent spokesperson told VentureBeat. Maybe, but building a file-sharing tool around the idea of decentralization is not the same as building a whole browser.

Comments

Private?

[buchner.johannes]

For normal websites, I can see the benefit of requesting data blocks identified by hashes. But doesn't bittorrent require that all data you download is shared between peers? How can any secure, private connections be handled, like banking or shopping?

Re:Private?

[Anonymous Coward]

I suspect that the torrent aspect would not function for anything using https, session variables, or a few other similar html gimmicks.

As for practicality, the server's connection speed is rarely the bottleneck in web browsing. Something like this would mostly serve as a potential user-defense against accidentally DoSing a popular page (if enough people join the maelstrom).

Re:Private?

[Charliemopps]

For normal websites, I can see the benefit of requesting data blocks identified by hashes. But doesn't bittorrent require that all data you download is shared between peers? How can any secure, private connections be handled, like banking or shopping?

Do you think the hops between you and your bank are private?

I'm not saying that this doesn't present some security concerns, I've no idea how it works. I'm just questioning the premise you seem to have that the connection between you and... anywhere... is in any way private.

Re:Private?

[Anonymous Coward]

Probably using some system comparable to how bitcoin does that. decentralized currencies at least show it is possible to be both decentralized and have secure transactions (as long as you hang onto your private keys, but hey, someone can steal your online banking passwords just as easily).

Re:Private?

[Jane Q. Public]

But doesn't bittorrent require that all data you download is shared between peers?

No.

Most bittorrent clients force you to upload to others as you download. But that isn't a requirement of the protocol, it was a judgment call on the part of the programmers. They felt that if you don't share what you download, then "the community" of sharers will fall apart.

But the BitTorrent protocol has many perfectly legitimate uses today, other than just copyright infringement.

At least some BT clients allow you to control how much (or whether) you upload when you download. Or to share things you didn't download in the first place.

But the short answer is: no. There is no requirement in the BitTorrent protocol that you "share" everything.

Re:Private?

[Bengie]

I wondering how BT will work for CDN style static data.

Re:Private?

[buchner.johannes]

The point was more than any request for data my bittorrent client receives from a peer, I can also request from the network. So nothing is secret.

Re: Private?

[WarJolt]

All distributed systems have similarities, but bit coin doesn't really apply very well to this. The problem with bit coins is that distributed monetary transactions have to be synchronous. The proof of work function(generating hashes) basically creates a giant global virtual clock, such that consensus can be reached. This fixes your double spending problem and also why it takes so long for a transation to go through.

This system wouldn't have to deal with all that nonsense.

Re:Private?

[Anonymous Coward]

Do you think the hops between you and your bank are private?

I think his point is how do you create a secure HTTPS-type channel over a BitTorrent type of network.

Re:Private?

[sexconker]

Your communication with the bank can be secured with public-key cryptography like usual, I would think. People can view the bits you pass back and forth with your bank already- anyone at your ISP and any interconnects between you and the bank. But, in theory, public-key crypto makes those bits meaningless to everyone else.

That's only true once you've established said keys outside of the public channel.
So you have to use something other than this Bittorrent for HTTP bullshit to establish security, then hand the connection off to Bittorrent for HTTP.
The question remains: Fucking why?

Re:Private?

[NotInHere]

I guess very well. In fact, there is a project called peerCDN, which P2P based on WebRTC as a CDN. So Maelstrom can already be achieved by firefox and chrome.

Re:Private?

[MemeRot]

Why? CDN companies like Akamai spend huge amounts on their server networks, and they are already local to you.

Re:Private?

[zidium]

Because they're MUCH cheaper for the end-developer who wishes to use them. Think about it.

Re:Private?

[nmr_andrew]

Peered file sharing will work fine for the parts that are common to everyone, like background images, javascript libraries, CSS, etc. Actual user specific data and operations, like bank account balances, I can't really picture going through hosts other than the customer and the bank, but that's probably a miniscule fraction of the data transferred.

That sounds sort of like I'd expect something of this sort to work, but there has to be more to it. All of those things mentioned as "common to everyone", with the possibility of some larger JS libraries or Java applets, are already fairly small (or at least can be, anyone using a 4+ MB image for their background should be summarily executed). I'd expect the overhead of noting the request, sending the torrent data, then having the local browser connect to multiple peers would actually INCREASE the total amount of bandwidth consumed.

Now, something like this makes some sense if links to download large images, videos, game updates, or whatnot point to a torrent instead of a large, locally hosted file, but in that case, I don't see how a "torrent-based browser" is any better than a stock browser with a built-in BT client.

Freenet?

[halivar]

There was a project a while back that was called Freenet (I think) that was supposed to be an P2P anonymous internet. Seemed slow as dog crap and more than a little shady. How will this project avoid the same fate?

Re:Freenet?

[bobbied]

I don't know how it will be fast, but to use existing bitTorrent logic, there ARE legal torrents out there and I would assume web content would be similar.

Re:Freenet?

[Anonymous Coward]

Freenet cares about anonymity. Unless this Maelstrom is torrent in name only anonymity won't be a concern. On the bright side that probably allows it have lower latency.

Re:Freenet?

[Finallyjoined!!!]

To paraphrase:

How will I avoid paying for stuff quickly?"

Re:Freenet?

[Jane Q. Public]

Freenet is not "shady". In fact its purpose was the opposite of shady: to enable legitimate internet use without being spied on by others.

There are others, among them OneSwarm, created at the University of Washington.

These projects were intended to promote freedom and privacy. That isn't a "shady" goal. Though people who want to spy on you (like the government) try to pretend that it is.

Re:Freenet?

[PhrostyMcByte]

Freenet had some issues. Most of them won't apply to BitTorrent's offering.

The main one is receiving content was dog slow compared to, say, Tor. This is simply an artifact of how it was routing connections and the distributed storage aspect.

Second, but still contributing to the poor experience is that the app itself had some architectural flaws that made it and your PC run dog slow -- the choice was either use hundreds of threads or let the operations stall.

The third, more of a security/philosophical flaw, is that the base protocol was not documented in any significant fashion. To review the protocol's security, you'd need to have an expert understanding of Java and a large part of the codebase. So it never really had many eyes on it looking for flaws.

I haven't used Freenet in around 5 years, so this may have improved. It was pretty clear why it never caught on at the time.

Re:Freenet?

[phorm]

I don't think that the GP was indicating the *project* was shady, but more likely many of the visible uses.
Like many things, freedom affords benefits to both paragons and scoundrels, but the latter may often be more high-profile or visible.

Re:Freenet?

[Jane Q. Public]

I don't think that the GP was indicating the *project* was shady, but more likely many of the visible uses.

I don't think that argument holds water. Is cash "shady" because it can be used for illegal purposes?

Re:Freenet?

[phorm]

No, because the majority of people visibly using cash are still doing so for legitimate/legal purposes.

Interesting if done right

[amaurea]

One of the reasons why the world-wide web is buried in a sea of advertising is that the costs associated with hosting a web-site increase as the site becomes more popular. So you might be ruined by your site becoming too popular. Advertising fixes that problem by giving income proportional to the popularity. But it comes with the undesirable side-effect of the ads themselves.

A peer-to-peer alternative to HTTP is a very different way of solving the same problem. If people who visit a page help upload it to other visitors, then the available resources will scale with the number of visitors without the server's bandwidth needing to increase. Bittorrent does this very successfully for large files and demonstrates that this mechanism can work. But bittorrent's latency is too high to serve as a replacement for HTTP. If this new protocol fixes that, and manages to get supported in many browsers, then things could get interesting. If they are to have any hope in the protocol gaining acceptance, it mustn't only be low latency, it should also be open and well-documented. So let's hope they don't pull another "Bittorrent Sync" here, and keep the protocol closed.

Re:Interesting if done right

[Bengie]

Parallelizing requests could help hide latency. Small requests would hurt, unless you could make many at the same time and or batch them up. If you're working with relatively static data, you could optimize the data such that many small pieces could be placed together in a single block. The same way file systems like to batch together small files to reduce the overhead of minimum block sizes.

Re:Interesting if done right

[davidwr]

Advertising fixes that problem by giving income proportional to the popularity. But it comes with the undesirable side-effect of the ads themselves.

Thereby lowering popularity - a classic example of a negative feedback loop keeping your server farm from crashing under load.

Re:Interesting if done right

[DigitAl56K]

One of the reasons why the world-wide web is buried in a sea of advertising is that the costs associated with hosting a web-site increase as the site becomes more popular.

Costs per visitor are usually extremely small.

The main reason the www has so much advertising is that almost nobody wants to pay for content, yet content is not free to produce, and even if you come up with a schema for which some people will pay, your competitors will steal all your volume by offering something closer to free (or supported by advertising), and volume is essential for almost all internet-based businesses.

None of this will change because of the distribution method. Content is still not free to produce.

Re:Interesting if done right

[xonen]

As you say, the costs per visitor are extremely low. That's also why i, personally, wouldn't mind to pay a few cents to have access. However, such is not possible. Either one pays reasonable high fees, up to multiple dollars per month, either it's free and filled with ads. There is no such choice as donating 1 cent.

So, what is lacking is a proper micropayment system that works, in an unobtrusive way. That's something that a *random big player in the market* has to solve. 20 years of consumer internet. The word micropayment is about just as old. And it still does not exist.

Re:Interesting if done right

[kaiser423]

I'm a bigger fan of HTTPS everywhere over this. As far as I can tell, this would break a lot of that....But it still could be a boon for imgur, and other picture/video hosting sites. Makes sense, but I think that the trend towards encrypting everything clash with this idea pretty well.

Re:Interesting if done right

[amaurea]

Not all websites are for profit. In fact, the majority probably isn't. This approach would only be a moderate help for for-profit websites, but it would help for popular noncommercial websites like wikipedia, discussion forums, open source software pages, etc. It could also be used to make a noncommercial youtube alternative. Just because something takes an effort to produce doesn't mean that somebody is looking to get paid for it. Some people are just looking for an audience, or others to collaborate with, or are just trying to make the world a better place.

Just a few stories back here on Slashdot we heard examples of people who had their webpages grow so popular that they were forced to put ads on them, even though they didn't wish to. That's the sort of case that would benefit the most from a distributed system.

Re:Interesting if done right

[Bengie]

They don't entirely clash. HTTPS makes it so both a passive and active viewer cannot see what you're requesting. In theory, something like P2P could still make it so a active viewer could not see what you're downloading, but an active participant could. As long as the protocol had a way to quickly black-ball participants who falsely claimed to have data, then anyone who wanted to watch would also have to help.

Re:Akami is dead

[omtinez]

Wanting to "break the internet" seems to be a hot trend these days.

No centralized servers?

[bananaquackmoo]

Of course it relies on centralized servers. Websites have to come from somewhere. Data has to be load-balanced. You don't download and upload a website with a database and hardware.

Re:No centralized servers?

[codebonobo]

There are many examples of decentralized sites: openbazaar, twister, bitmarkets, ect ... all which require no centralized servers and are created with DHT and the blockchain protocol.

Interesting as an alternative for CDNs

[Anonymous Coward]

Obviously this works only for static resources. I can see this work as an alternative for CDN's, and as such it's really interesting. Cache invalidation is annoying. Distributed cache invalidation is a headache in a whole different ballpark

Netflix et al

[davidwr]

Netflix could too, if they can get authorization to actually use the system (insert MPAA members howling about their IP being on a P2P network

I can see the MPAA accepting "partial" distribution (say, 75% or maybe even 90% or 99%+ of the bits) over hard-to-track torrent-like protocols as long as enough of the bits are distributed "directly" to ensure that those having only the "partial" distribution either get a useless (e.g. encrypted or compressed-with-key-bits-missing) bits or they get bits that result in such an unpleasant viewing experience (drop-outs/noise, segments that have key plot elements removed, or missing audio) that it won't be an economic threat.

Heck, if the recording-industry was smart, they would set up their own "stripped-to-the-point-of-useless" torrent-like system then invite customers to buy/rent unique-per-customer versions of the missing data. Of course there would have to be some incentive/compensation for your average viewer for them to allow others to "upload" from their computer, such as "fan bucks" usable at the movie's official web site online store or some such.

From a marketing perspective, it would also be smart for the recording industry to use existing BitTorrent-type networks to seed sample TV episodes (complete with ads of course, sigh).

The code is the documentation

[davidwr]

The third, more of a security/philosophical flaw, is that the base protocol was not documented in any significant fashion. To review the protocol's security, you'd need to have an expert understanding of Java and a large part of the codebase. So it never really had many eyes on it looking for flaws.

I know what you are trying to say - that the protocol was not documented in any significant fashion in a popular human language, but I must point out that computer code, to the extent that it is non-ambiguous,* is "documentation in a significant fashion" of the protocol's implementation. Unless there is other documentation to that contradicts it (such as a human-language protocol spec) it is also the de facto documentation for the protocol.

Now all we need is a few million people who can understand Java as well as most people understand their native human language.

*Some computer languages have ambiguities/undefined-behavior in their spec (these are frequently unintentional oversights). Some computer languages have popular implementations that "go against the spec," introducing de facto ambiguities where the original specification had none.

Re:Akami is dead

[davidwr]

Tor isn't anonymous anymore, and just using it probably puts you on a watch list somewhere. Insert tinfoil hat joke below.

I'm not laughing, and I doubt you are either. Sigh.

On a slightly different topic:
Tor increases anonymity by making it much harder for someone to track you down. In practical terms, if neither you nor anyone using your ISP are currently being monitored, you don't use it to visit sites that are being actively monitored by an adversary (including any site that shares an ISP with such a site), and you use it only sparingly (maybe a few MB today e.g. to visit a blocked-from-your-country news or web-mail site, then none at all for a few weeks, changing IP addresses and devices in the meantime) it is much more likely than not that your actual traffic will not be de-anonymized. But there is still a good chance that you could be. Of course, if you live in certain non-free countries, ALL TOR and similar traffic probably triggers alarms at your country's or ISP's border-routers and even of the police can't decode WHAT you are viewing, they can probably throw you in the gulag just for daring to use TOR. In countries that pretend to be free, you won't be arrested but as the parent-posting AC said, you might be put on a watch-list so the NEXT time you use TOR you can be traced much easier. So be sure that your second trip through TOR you pretend to be a good citizen and only visit www.ILoveMyGloriousLeader.[yourcountrycode] and that you post all kinds of kinds words to the public blog.

Imagining torrented streaming

[davidwr]

(except that I can't imagine now 'bit-torrent streaming' would work.)

Imagine a video broken into small chunks of 1-2 seconds. Imagine a torrent-ified web browser that used the torrent protocol to verify that all chunks were available for download from somewhere then proceeded to download the first few seconds of the video ("buffering") and while doing so figure out how big of an initial buffer it needed (latency, sigh), then after filling the initial buffer displayed them in order, downloading subsequent chunks while the first chunks were displaying.

Oh, that large and ever-changing latency? That's not your imagination, that's real.

Re: Imagining torrented streaming

[Anonymous Coward]

Surprised tot see no mention of YouTube's 'network-assisted' option in the flash for video's. That's p2p streams right there for you, and it works.

Re:Imagining torrented streaming

[Bengie]

Optimally, there would be a notion of a few buffers. P2P works best when chunks are randomly uploaded as not to cause a bias to what data is available. Probably a primary buffer that fills and requests data sequentially, then a much larger secondary buffer that is ahead of the primary one's timeline, where it grabs random blocks.

I wonder how much data storage would be required for a base optimal viewing experience and what kind of eviction algorithm.

There are two primary types of data for web viewing. Latency sensitive small requests, like HTML/CSS/JS; And initial latency or burst sensitive, but overall low sensitivity to bandwidth and latency requirement bulk transfers like large images and video streaming.

Re:Imagining torrented streaming

[Bengie]

This shouldn't be used to replace normal web browsing, but to help augment it. The web server can always been around to seed the data.

Re:Right

[diamondmagic]

You just need to track down a peer who's a member of the network, and you need to be able to get packets to them. Any peer will do; doesn't matter who or how much you trust them.

How is any part of that 'centralized'?

The very worst that can happen is you never get to download your file, or your payment never makes it to the vendor, if you have a bottleneck through your ISP, and your ISP decides to cut your service... but that's not a fault of the protocol, that's a fault of physics. If you have any connection at all to the network, Bitcoin and Bittorrent will work.

Multiple "central" servers

[davidwr]

And yet somehow, there is always a key - some centralized process somewhere that is the Achilles' heel.

And this is why there are hundreds of root DNS servers with over a dozen "names" (list).

TOR has (or had) "directory servers." Although it was discarded as not being practical, TOR or its predecessors considered using fully-distributed directory information (see 2004 documentation). TOR now has the option of using bridge-nodes. The addresses of these nodes are typically distributed "out of band" (e.g. by email or personal contact) on a need-to-use basis.

In short, "centralized servers" are not a bad thing as long as there are enough of them without any significant risk of common failure (short of a catastrophic event that would take down the whole Internet or for that matter the whole planet).

Re:Right

[Dunbal]

There's always a choke point. With Bitcoin - how do you buy them for US dollars? How do you sell them? Go after the "exchanges". With distributed networks I can sniff them and see who's on - and if I have enough resources (like say the NSA) I can figure out which packets are going where. If I know an origin (you, my suspect) and a destination (what I think you're accessing), I can make the same link. Why? Because you can make it.

Asteroids

[ChunderDownunder]

I remember Maelstrom.

It put Andrew Welch on the map as a game developer, 22 years ago.

dynamic sites ?

[Tom]

How does it handle dynamic sites? If the answer is "not at all" as with previous projects of this kind, it's dead on arrival.

Most of the web is dynamic today, and almost all of the interesting sites are. How many of us would be reading /. if it didn't have comments and moderation?

Re:dynamic sites ?

[ThePhilips]

Most of the web might be dynamic.

But most of the interesting content is quite static, changing relatively slowly. Consider Wikipedia or YouTube. Wikipedia updates relatively slowly. YouTube only adds new videos (and after Google's touches the comments and the recommendations are pretty useless anyway).

Search and the comments might need to stay dynamic - and centralized - but hosting costs would drop significantly if the bulk data transfers would be handled by the P2P network.

Subsistence, Gift, Exchange, Planned & More

[Paul Fernhout]

On alternatives to profit-making websites emphasizing other types of transactions than exchange, see my comment: "1. Outdoor Holiday Lights 2. ??? 3. Profit!" http://slashdot.org/comments.p...

As I mention there, I've been working on-and-off towards software for supporting a social semantic desktop. Many other have of course (like with NEPOMUK), I'm just one more. The Maelstrom sounds like it may be heading in that direction too.

I have some later stuff I have not released yet, but it is pretty similar to this:
"A step towards a social semantic desktop in JavaScript using a NodeJS or PHP backend "
https://github.com/pdfernhout/...

A key idea there is to write applications that spread their content state across a set of files, where you change the content state by adding a new file rather than changing an existing file.

So, for a simple example, imagine you have a document you can find by some UUID. When you make a new version of it, you write out a new file that references the same UUID but has a later timestamp. When you want to display the content, you search through all the versions of the document you have and display the one with the latest timestamp. Every actual file can be referenced by its SHA256 hash value and its length

Now, things can rapidly get more complex that that like by having hyperdocuments where only part of the document is in each file and so on. That requires a somewhat a different style of writing applications than is typical today.

In that version, you can have log files you add to, which can be generated by the system as it accepts new files and sees if they have special indexing tags. You can also have git-like variables that represent a pointer to a specific file and which can only be changed if you present the current version of the variable.

That older version is a bit more complicated than the one I'm working on, which has been progressing mostly by subtraction. :-) In the new version (not yet on GitHub, but I plan to put it there at some point), I got rid of the logs and variables, and replaced them with memory indexes of all content which is always a JSON document. Standard indexing of the files is simple and mainly just enough to find related ones which you can process or index further locally. Indexing in the server is based mainly on files having an optional ID (representing a document potentially with versions under the same ID) and having optional tags (to provide context about hyperdocuments), as well as having a SHA256 and length for direct retrieval. You can also query a server for files that match those IDs. Eventually, I see those queries as being like "magnet URIs".
http://en.wikipedia.org/wiki/M...

I've been writing a Single Page Application in JavaScript that uses that new backend to support "Participative Narrative Inquiry" (implementing ideas outlined in my wife's book "Working with Stories");

I think there is a great potential for such tools for community dialog and community planning and community design. I have a video related to that on the front page of site that is currently running the Pointrel20130202 software:
http://twirlip.com/

Of course *many* people have been working towards a social semantic desktop (like NEPOMUK). And there are many document-oriented databases (CouchDB, MongoDB, etc.) and a variety of other databases of different sorts. These are just my own experiments and I don't know if they will succeed in being generally useful. I remain hopeful that someone will develop a general purpose system for this and it will be useful for communications, planning, and design. Maybe Maelstrom (or Maelstrom plus some new apps written in the way described above) will be it.

The Theodore Sturgeon short sci-fi story, "The Skills of Xanadu" is