[p2p-hackers] Tighter HTTP and P2P integration??

[coderman]

On 2/14/06, Charles Iliya Krempeaux <supercanadian at gmail.com> wrote:
> ...
> One thing that's been on my mind for a while is making "tighter
> integration" between HTTP and P2P technologies.
> ...
> A "P2P conditional get" (sent by the client) would tell the server NOT
> to send the requested document if there is an alternative way of
> getting the document via a P2P technology supported by the client.
> ...
> Also, are there already any proposals or specs along these lines?

another route to http / p2p integration is through the file system
with each peer running a local web server instance for UI on top of a
shared fs tree / archive.  [decentralized and/or distributed file
systems are another topic, so i'll assume the presence of a robust
shared file system view among peers in this explanation]

our context is a bit different, as this mainly applies to private
group networks with known client configurations (everyone running off
a live CD / hdd install of the same shared OS)

the desired handlers for various MIME types / filters / views can be
accomplished per user with custom browser configurations and plugins.

for interactive / collaborative / real time functions the private
group network endpoints can be used to host services.  consider:

a pre-distributed archive / fs tree associated with the group:

.../mygroup/public/music/
                          video/
                          docs/

all peers can reference these resources via local methods like
file:///... or aliases in a drupal instance on localhost -
http://127.0.0.1/video/favorites.  aliases/vhosts for 127.0.0.1
(localhost, home, mygroup, etc) can also be used to provide distinct
shared group apps/instances with distinct document roots as desired. 
(again, simply apache and drupal with a common httpd.conf bound to
127.0.0.1:80 using vservers  for names in /etc/hosts)

services and other resources are bound to peer identities and IPv6,
for example a private IPv6 network using
feed:7ba3:c779:e5f5:cc1a:8bc7:5fe1:ed08 where feed: is the common
subnet and the remaining identifier space is based off a hash of
public node identity.

feed:7ba3:c779:e5f5:cc1a:8bc7:5fe1:ed08 can then be aliased like
127.0.0.1 and will remain valid as long as communication (direct or
via proxy) with that peer can be accomplished.

using private networks also means that UDP|TCP/IPv4/v6 aware
applications can be hosted on these endpoints and used as private p2p
group services.

so while this approach requires a heavy endpoint (custom live CD / hdd
OS linux image with group key material and base|cached fs distributed
securely out of band) the benefits from a security|privacy and
flexibility viewpoint are significant.  this moves a lot of the
complexity out of application space (where it usually resides for p2p)
and into the networking / file system layers, where it is more
appropriate and can be handled much more robustly.  (think access
restrictions, network and distributed filesystems, netfilter hooks,
security modules / caps, etc rather than trying to reproduce a subset
of this poorly in user space applications)

this is one of the many reasons i am so fond of the tun/tap based
networking software (openvpn, openssh 4.3), IPsec, and virtual
machines (Xen, VMware player, etc).