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.
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.