[p2p-research] Data Roads: P2P network physical topology.

[Michel Bauwens]

Hi Jared,

if at some point you want to publish your project on our p2p foundation
blog, but in not too technical fashion, please don't hesitate,

Michel

On Wed, Aug 25, 2010 at 1:31 AM, Jared Hardy <jaredhardy at dataroads.org>wrote:

> Thank you all for looking at DataRoads.Org. Please understand that
> this project is in the early outreach phase, and the blog contents are
> addressed at a widely mixed audience of mostly lay computer users. A
> lot of my friends are from my video game and artistic circles, and
> they understand very little about network hardware. I imply many of
> the technical underpinnings while only explaining them by way of
> analogy -- Data Roads itself is one such analogy. I think it might
> catch on because USA culture is so car-centric.
>
> It's nice to talk to more diverse hackers here -- I need to get back
> in the habit of using my GPG keys. :)
>
> On Tue, Aug 24, 2010 at 8:34 AM, jaromil <jaromil at dyne.org> wrote:
> > congratulations for DataRoads, looks like an interesting illustration
> > and hopefully it will achieve what we all dream of, also with projects
> > like Netsukuku.
>
> I have studied similar projects to Netsukuku here, and I've been in
> contact with the CUWiN project leader Sascha Meinrath.
>    I try to avoid talking about wireless when talking about Data
> Roads, because I believe it can operate in a link-layer agnostic way.
> Many of the concepts actually started out as wired networks, but can
> easily be expanded to fixed wireless meshes. Part of the reason for
> geoposition numbering in DataRoads is to provide a means of easily
> "stitching" separate meshes when they eventually converge
> topographically. I want to provide a large and consistent number space
> that can be routed throughout the whole world without prior
> coordination. Geolocation routing also avoids a lot of the edge-case
> loop issues of more traditional routing systems. It makes packet route
> navigation a lot more like video game AI navigation.
>
> > i've taken the initiative to forward this to our hackers network at
> > dyne.org for comments, which i'll gladly forward to you. even after a
> > quick look I'm undoubtely interested in its forthcomings: the approach
> > to geoposition looks like a good idea, although some privacy concerns
> > would arise, as they do already with efforts like IPv6.
>
> As you note those privacy concerns already exist, even with IPv4
> geolocation systems. Data Roads organization will petition ICANN for a
> 64-bit or larger IPv6 subnet space for its geoposition numbering
> system, to maintain compatibility with (but not dependency on) the
> legacy ICANN-dependent networks. I hope to alleviate privacy concerns
> with a series of security and anonymity oriented protocols, utilizing
> "Web of Trust" (WoT) metrics to determine first-tier protection
> exchanges, similar to FreeNet. Each router node should have a unique
> private/public key pair that it uses for all communications.
>
> One idea is what I call "matryoshka doll packets" -- a series of
> encrypted packets nested inside each other, with only one "destination
> header" shown at any phase of transfer. Each "destination node"
> decrypts one inner packer further, and then forwards it on to the
> newly revealed header's destination. No "destination" should be able
> to detect the true final destination, nor the true sender, because it
> has no knowledge of how deeply the "matryoshka doll packet" is nested
> at any phase. If a return address is required, that would be hidden
> inside the final inner encrypted packet.
>
> Another idea is "registered recipient lists" -- multiple WoT peers are
> asked to receive response packets from a foreign service on a node's
> behalf. The foreign service should have no clue which "recipient" the
> real request is originating from, if any. A per-session key can be
> created separately from any one node identity, so the entire session
> can be encrypted without revealing the true destination. Each
> "registered recipient" peer node only gets a small piece of the
> request/response puzzle, to prevent them from spying or intervening on
> the transfer in whole.
>
> Many more protections can be built into the DataRoads:IPv4/6 gateway
> specifications, similar to ToR and I2P. A lot of the protections
> involve WoT-enabled black/white-list distribution, and game theory
> agents to automate conflict resolutions. I've been reading the works
> of Dr. Elinor Ostrom (Nobel Prize in Economics, 2009) for a lot of the
> relevant game tactics.
>
>    Thank you,
>    Jared Hardy
>



-- 
P2P Foundation: http://p2pfoundation.net  - http://blog.p2pfoundation.net

Connect: http://p2pfoundation.ning.com; Discuss:
http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org

Updates: http://del.icio.us/mbauwens; http://friendfeed.com/mbauwens;
http://twitter.com/mbauwens; http://www.facebook.com/mbauwens

Think tank: http://www.asianforesightinstitute.org/index.php/eng/The-AFI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20100825/1df2c0b4/attachment.html>