-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How do you imagine the web of the future?
[pre-draft, after a first small review circle we should make the development of the draft as viral as possible] The Web could embrace distributed web-content, applications and services. Today resourceful client hardware, sophisticated browsers and a complex client-side JavaScript language has already become reality. Global IPv6 endpoint-to-endpoint connectivity adds new opportunities to fully distributed P2P networks. (and that's also already reality, even if for the meantime just due to Microsoft shipping built-in IPv6 transition method Teredo since Windows 7) Many services already do load-balancing on many layers (web-caching, database-clusters, distributed storage), but that "cloud" obviously runs on centrally managed infrastructure, which is expensive to run. Modifying the current server-centric web architecture into a hybrid distributed architecture would allow existing services to scale better by making use of resources on clients. This could lead to a gradual adoption of peer-to-peer methods (as already seen in proprietary environments such as Adobe Flash) once support on the client-side exists/matures. This is an invitation to help linking those topics with more related projects, existing RFCs (there is a lot!) or papers on these topics. I guess it makes most sense to discuss and develop even the specs (!) on gitorious. How would you feel comfortable to participate? This needs a lot of glue! I envision an architecture that extends the current W3C web by a number of additions: - -1. (a more distributed) Networking infrastructure, multi-homing in ARPA, local mesh (arig), global overlay-networks like DN42, VPNs and TOR * transparent to client applications due to trivial routing for IPv6 multi-homed nodes as there are now address-space collisions 0. distributed DNS (many are breaking their heads on it) DNSSec provides the base for it, however, probably there will remain many implementations, ranging from hierachical/centralized to fully distributed, depending on the clients connectivity and system properties. * implemented as a device-type specific (permanent-infrastructure,stationary,mobile) daemon on each network node, therefore also transparent to the client. 1. (more) DHT e.g. using an existing implementation like libbitdht BitTorrent DHT is already widely adopted, namespaces can easily be added. I can imagine a use like NoSQL, given there is a JavaScript API provided by the browser... The DHT service could be extended with operations needed to run a distributed PKI, see section 4. 2. Distributed storage and streaming (to be implemented in VLC, hopefully Mozilla foundation will realize the need...) retrievel e.g. http://torrentstream.info there are proposals to add libtorrent streaming to VLC why not to Firefox? (or use Vuze or miro as your browser ;) or not even torrent but GnuNET? imagine URLs like magnet:?xt=urn:sha1:34a6fe12ac58d090610ad9b78feb3f75049fb3db:/file.html magnet:?xt=urn:sha1:34a6fe12ac58d090610ad9b78feb3f75049fb3db:/stream.ogm maybe HTML5 <a>,<style>,<img>,<video>,<audio>,... tags could have extra CSS/DOM attributes for retention time and other p2p client settings... or append it to the url like in SIP such as magnet:?xt=urn:sha1:34a6fe12ac58d090610ad9b78feb3f75049fb3db:/news0.html;r=1d DNS can carry such things as magnet-urls TXT records, seed-nodes could also be refered to by SRV records in DNS. site-certificates or even IPSec keys could also be stored in DNS.... publishing by creating torrents could also be integrated into the browser, e.g. for photo or other media uploads 3. WebSockets<->TOR(onion) local service on each client :) or anonymous other overlay networks like I2P and again GnuNET. Can any of them do "real" multicasting? can easily be used in JavaScript by creating a WebSocket connection to localhost:[tor-websocket-port] 4. a distributed PKI a distributed keyring and key/certificate management system imagine a mapping of social-networking like operations (->LinkedIn) to operations on PGP-like cryptographic certificates. Client side must support key generation, foreign public key signing, signed-public key certificate publishing in the DHT (+extensions, see below), public-key+purpose signing request. certificate signature revocation can be achieved by generating the revoker and refering to it's hash, but not yet publishing it on the DHT). this includes adding a crypto-namespace to the DHT which restricts operations on key-value-pairs according to rules provided by the cryptographic interpretation and evaluation of the current value(=certificate) of the key(=hash) (instead of keyservers), plus local support for both, per-user/per-app/per-namespace/... locally generated software keys or hardware tokens (PKCS#12). Singular permissions can then be reference by the hash of the corresponding signed certificate. A simple login with only a username and a password could be provided by storing a private-key plus certificate in an password-encrypted wrapper in the DHT. On the GUI-level, this could look like an roster. This includes using the PKI to include certificates for infrastructure services like DNSSec, IPSec, 802.11i or authsae or to-be-invented-olsr-real-security (which could be just IPSec-AH, however, only once the PKI is already populated...) A good example of existing building-blocks can be found in rapidshare https://rapidshare.com/ or key-management-guys like seahorse and of course just plainly GnuPG and all related tools. 5. real-time communication (implemented at least in Firefox and Chrome) WebRTC for direct Audio/Video communication (I wonder how we will fit established VoIP servers like freeswitch, camilo, asterisk, ... into that story...) 6. feeds/blogs/logs could then be implemented in client-side script-language by using DHT and PKI features 7. distributed search and crawling e.g. http://yacy.net/en/index.html (implemented in Java) maybe someone wants to write something like this in node/js? 8. distributed processing and building for software distribution and continuous integration during development, bigger data-processing tasks, ... e.g. using http://www.buildbot.net/ 9. distributed collaborative development and revisioning of course using http://git-scm.com/ 10. multi-cast broadcasting well, one day, it will probably make sense to use real multicast for real-time content instead of (caching) torrent-like method (as via zattoo.com)... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRHXV5AAoJECBgbL4bcbCQ3CAH/R+IuRVk0YkNBNXI60NLOrz5 UlgJXtD9TO4njHue71TOiIhfM9bul9F06t3SfWmHPu4YQ9Wdo6gvWGpThRjhlM+n d1U1Gr2yUKZTcg9xDi1b00KS+2VkAs9r1Krbkm8TREWhL+Q/yid2qSMJ1PG7gPqt 4mQGCcjoUKslzmDhYWOgE2h1Y+NCCBgem2ptOWLwM1CpVwCcgReeYoNjpMSmOzk2 sci2skcZrzR3cFJMd/XaU1lKBUDhUNBOfMtMEZ/wNIYlJ5UJV1f3HmIRc8/95/IV j0/xohg+YpUsHvlExUFfG0yU1eo0jfeyomequm3HaSkRiUI1Q0eoO76Bb9SSFAs= =XcCE -----END PGP SIGNATURE----- _______________________________________________ arig-discuss mailing list arig-discuss@lists.subsignal.org https://lists.subsignal.org/mailman/listinfo/arig-discuss
