Project Maelstrom: The Internet We Build Next
blog.bittorrent.com
blog.bittorrent.com
All of which comes across as being much less open and decentralized than the current web.
Even if the technology itself is more distributed than the common standards we're all using now, this sounds more like a walled garden than a truly open network.
AOL with Tor. Yay.
> AOL with Tor. Yay.
I checked but I could not find any mention of Tor; could you explain why you threw that into the mix?"The internet has handled big problems in the past, and they always do it through innovation, through technology," Klinker says.
Amen to that. So, what they're basically saying is, seed your webcache. Interesting idea, but what happens with dynamic content?
Note: this looks like a way to keep tpb online indepedent of servers or domains
Nearly all open-source software projects either the source or at least a specification/standard for the upcoming software very early.
OSS doesn't begin with closed alphas of closed software and a content-free press release.
* WebRTC for the P2P "glue" (i.e. webtorrent[0]/instant.io[1])
* Google Caja[2] for the sandbox
* Custom protocol handlers[3] for URLs/URIs
- <a href='eph://[DHT hash]'>
- Handler unavailable? https://eph.io#[DHT hash]
You basically just package everything (images, JS, HTML) into a single DHT resource, and share the eph:// URI. For long-term hosting, setup a webtorrent-compatible seedbox somewhere in Europe.I've only gotten as far as static P2P site hosting, but if I were to speculate:
With a distributed database and a rethink on isomorphic JS, you could build fully-auditable "aether-hosted apps". Like cloud hosting, but more buzzwordy! It'll become even more powerful (but less auditable) if homomorphic encryption ever becomes a thing.
For such a DB, perhaps a P2P document store similar to CouchDB/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'd be so collision-prone that a superuser would need to regenerate the database and re-sign the contents. I'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.
Short URL'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->URL is simply to convert into human-readable strings[4].
---
[0]: https://github.com/feross/webtorrent
[1]: https://github.com/feross/instant.io
[2]: https://developers.google.com/caja/
[3]: https://developer.mozilla.org/en/docs/Web-based_protocol_han...