Project Maelstrom: The Internet We Build Next

I know this is an alpha release, but it&#x27;s invitation only with the invitation being &quot;help us shape the future of our network&quot;<p>All of which comes across as being much less open and decentralized than the current web.<p>Even if the technology itself is more distributed than the common standards we&#x27;re all using now, this sounds more like a walled garden than a truly open network.<p>AOL with Tor. Yay.

<i>&quot;Maybe there&#x27;s a way to solve [net neutrality] with technology, he muses&quot;. &quot;Maybe we don&#x27;t need to attack from a policy perspective.&quot;<p>&quot;The internet has handled big problems in the past, and they always do it through innovation, through technology,&quot; Klinker says.</i><p>Amen to that. So, what they&#x27;re basically saying is, <i>seed</i> your webcache. Interesting idea, but what happens with dynamic content?<p>Note: this looks like a way to keep tpb online indepedent of servers or domains

I&#x27;m calling it, this is gonna be huge.

So, BitTorrent&#x27;s vision is that &quot;The Next Internet&quot; (aka the Decentralised Web) will be closed?

Ephemeral P2P site hosting has potential, though I disagree with the route Project Maelstrom is taking. Another approach would be to try an in-browser implementation, using:<p>* WebRTC for the P2P &quot;glue&quot; (i.e. webtorrent[0]&#x2F;instant.io[1])<p>* Google Caja[2] for the sandbox<p>* Custom protocol handlers[3] for URLs&#x2F;URIs<p><pre><code> - &lt;a href=&#x27;eph:&#x2F;&#x2F;[DHT hash]&#x27;&gt; - Handler unavailable? https:&#x2F;&#x2F;eph.io#[DHT hash] </code></pre> You basically just package everything (images, JS, HTML) into a single DHT resource, and share the eph:&#x2F;&#x2F; URI. For long-term hosting, setup a webtorrent-compatible seedbox somewhere in Europe.<p>I&#x27;ve only gotten as far as static P2P site hosting, but if I were to speculate:<p>With a distributed database and a rethink on isomorphic JS, you could build fully-auditable &quot;aether-hosted apps&quot;. Like cloud hosting, but more buzzwordy! It&#x27;ll become even more powerful (but less auditable) if homomorphic encryption ever becomes a thing.<p>For such a DB, perhaps a P2P document store similar to CouchDB&#x2F;PouchDB, with aspects of context-aware networking. The user auth table could include public keys for authorized users, and handle modifications through a signed changelog. You could probably get pretty far through a signature chain (users delegating users), though at some point it&#x27;d be so collision-prone that a superuser would need to regenerate the database and re-sign the contents. I&#x27;m not really a DB guy, though; there are obvious situations where such an approach is unsuitable, plus there might be a simpler DHT-like way to do it.<p>Short URL&#x27;s could be handled using a proof-of-work-based DDNS system (Web Crypto API for PoW, WebRTC for P2P). A more simplistic approach to URI-&gt;URL is simply to convert into human-readable strings[4].<p>---<p>[0]: <a href="https://github.com/feross/webtorrent" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;feross&#x2F;webtorrent</a><p>[1]: <a href="https://github.com/feross/instant.io" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;feross&#x2F;instant.io</a><p>[2]: <a href="https://developers.google.com/caja/" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;caja&#x2F;</a><p>[3]: <a href="https://developer.mozilla.org/en/docs/Web-based_protocol_handlers" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en&#x2F;docs&#x2F;Web-based_protocol_han...</a><p>[4]: <a href="https://neftaly.github.io/radixWord/" rel="nofollow">https:&#x2F;&#x2F;neftaly.github.io&#x2F;radixWord&#x2F;</a>