I'm working on something else right now but when it's feature complete I'll port synchrony to Go.
The plan is to give full consideration to potential pitfalls of multiple overlay networks, the contacts list, and of course peer-to-peer streaming hypermedia.
"ENABLE_WEB_APP" is also going to be a configfile option.
Users should also be able to modify a list of domains they won't utilise overlay networks for.
It will also have to perform the necessary alpha transforms on javascripts to prevent them from modifying the proxys' interfaces' objects whilst presenting a public API, so that in-network resources can do friends list operations for things to the tune of "network/nodeid/uid would like to play grand theft space wizards with you".
Addendum: Identity is a first-class concept when it comes to decentralised HTTP/2.
What we're looking at is Users in a shared channel applying functions to a synchronised tree, when it comes to edits. That's exciting to reason about.
Forget replicating frames, p2p live broadcasts and storing references to edits of hyperdocuments in a DHT for just a second though.
When it comes to identity we'll keep it simple and use the SHA1 of an ip, port and public key. This prevents people generating the node ID that corresponds to google.com at will, in principle.
As a user of the software implementing this protocol you can be identified as network_name/node_id/uuid4, where your contacts can alias that address with a username or you can transmit the nickname you want to be seen as alongside an avatar image.
The idea is to then facilitate a server/browser contacts API. You're a peer node. You're willing to transact with other people who're caching hypermedia either indefinitely or for a minute or so for a live broadcast. What needs exporting is the API for contacts list operations (JavaScript class and thoroughly documented stream RPCs) so developers and entrenched entities can implement chat, webrtc teleconferencing etc on top of this simply by introducing the functioning hypermedia into the DHT for retrieval. It shouldn't matter whether the original host serves the resource.
For example G+, Twitter, Facebook and Skype et al. could introduce their own particular index.html and client.js which execute a single-page app for utilising their silo'd contacts data/news feeds etc. Permitting them granular access to your decentralised contacts list.
I'm willing to discuss this via luke.brooks42 [at] gmail.com if anyone would like to support the development of this project.
It decentralises HTTP in-place. No hashes instead of URLs. The thing just treats the hash of a URL as a peer node ID and you ask that node or whoever you find on the way if they've seen anyone reporting that they'll serve data for the URL.
If you're lucky your peers will provide you with an associative array of content hashes referring to nodes who'll serve data corresponding to them and their last-seen times.
I'm working on something else right now but when it's feature complete I'll port synchrony to Go. The plan is to give full consideration to potential pitfalls of multiple overlay networks, the contacts list, and of course peer-to-peer streaming hypermedia.
"ENABLE_WEB_APP" is also going to be a configfile option.
Users should also be able to modify a list of domains they won't utilise overlay networks for.
It will also have to perform the necessary alpha transforms on javascripts to prevent them from modifying the proxys' interfaces' objects whilst presenting a public API, so that in-network resources can do friends list operations for things to the tune of "network/nodeid/uid would like to play grand theft space wizards with you".