[p2p-hackers] I2P triple+file sharing network? (Was Re: [i2p]
simple gnucleus over i2p needed) (fwd from adam@atommic.com)
Eugen Leitl
eugen at leitl.org
Fri Apr 22 08:18:10 UTC 2005
----- Forwarded message from Adam Atlas <adam at atommic.com> -----
From: Adam Atlas <adam at atommic.com>
Date: Thu, 21 Apr 2005 17:19:28 -0400
To: i2p at i2p.net
Subject: I2P triple+file sharing network? (Was Re: [i2p] simple gnucleus over
i2p needed)
X-Mailer: Apple Mail (2.619.2)
I had an idea like this a while ago, but I had a potentially important
thought: If we just port a P2P network onto this anonymizing framework,
it'll seem like we're doing it solely to break the law and evade
punishment. (Depending on the ruling of the current US Supreme Court
case relating to file sharing, MGM v. Grokster, this could actually get
the I2P devs in trouble, or at least whichever ones live in the US.) I
personally am not interested in doing this just to share music -- I
actually support all that "free speech" stuff (as I'm sure most I2P
users do) -- but I won't judge others' motives, either way. However, to
unleash an untraceable, unstoppable file-sharing network would
undeniably make the I2P project look really evil, even though
individual users wouldn't get caught.
Anyway, since an I2P file-sharing network doesn't exist yet, we have
the chance to be truly innovative, instead of just copying existing
things that were innovative a few years ago. I've thought of a way to
make an I2P network much more useful than any existing file-sharing
networks, including several possible uses that *don't* have to do with
warez or illegal MP3s! (We can leave that to Freenet.)
Here's how it works: It's still a distributed searchable data store at
heart. Nodes search other nodes, and then download the files, thus
helping to share them further. The classic file-sharing network. But
the difference is that it's integrated with RDF [1]. *Not* the RDF/XML
serialization [2], mind you -- anonymizing networks are slow enough
*without* huge XML payloads flying around. No, just the triple-oriented
core metadata model. That would allow for smarter searches, maybe based
on RDQL, going far beyond the present style of dumb filename searching
(and even the Filename/Artist/Album music metadata searching available
on some P2P protocols). So what would be the use of this, aside from
finding potentially evil and/or illegal content with greater ease? I'll
tell you. Combined with file-signing (distinct from I2P's built-in
encryption), it would open up a world of decentralized democratic
content-organization capabilities.
As one example, here's how one would build a distributed discussion
forum/BBS platform atop such a network. (For now I won't discuss the
network architecture -- we'll assume that the peers are already
connected to each other, however we decide the best way would.) We
define an RDF predicate -- let's call it
<tag:example.org,2005-04:postedInto> for now -- indicating that the
subject file is a message posted into a discussion board represented by
the object, and <tag:example.org,2005-04:replyTo>, indicating that the
subject file is a message replying to the object message. Now suppose
we're chatting away in #i2p, and a few people decide they want a more
permanent discussion area. So they mint a tag [3] in a namespace
controlled by one of them -- perhaps a Postman I2P email address, or a
well-accepted .i2p domain name, as the authority name -- or maybe just
a uuid URI. A URI representing their discussion board, in any case.
Let's suppose it's <tag:example.i2p,2005:bbs>. They then add that URI
to their forum-browsing programs ("subscribe" to it). Since this P2P
network can also store metadata about abstract non-file resources (as
well as the usual file annotations), the contributors throw some basic
Dublin Core [4] metadata into the mesh -- title, description, stuff
like that. This is stored not centrally anywhere, but is propagated on
a triple-by-triple basis. Once people have added some metadata, anyone
else who subscribes to this forum will receive this info. Behind the
scenes, the forum browser will have retrieved this by making a query to
the network, asking for all triples where the subject is
<tag:example.i2p,2005:bbs>. Once it receives this metadata, it will
begin sharing it also. (What stops people from distributing incorrect
triples? By combining social means with technological means. Clients
might have a capability to "disagree" with a triple, where it stops
sharing it. Further, it reifies [5] the triple, and forms a new triple
saying that the aforementioned statement is inaccurate, and another
saying that its source is untrustworthy. This can eventually result in
a complex web of trust.) Then, introductory metadata aside,
conversation can commence. They post a message by doing so in their
forum client, which may be a local web-based app or a stand-alone
program. (Most likely, it would not connect directly to the network,
but would connect through a daemon which would handle the SAM
connections and provide a public API for client programs. Naturally
there would be a vanilla file-search client, but that would only be the
tip of the iceberg.) When they post a message, that's where the
file-sharing comes in. The program generates a file containing their
message, digitally signed using PGP or some other public-key
cryptography (only so multiple messages can be securely associated with
the same person -- not to identify the sender by a real name, of
course). Then, the most important part, it adds the
<tag:example.org,2005-04:postedInto> metadata key. Other forum clients
can now find this message, without it being stored anywhere, simply by
searching for all ?x such that { ?x
<tag:example.org,2005-04:postedInto> <tag:example.i2p,2005:bbs> }. ?x
should match multiple files -- one for each post in the forum (though
from any number of sources). The client can then download it, however
the download mechanism works (it would be good to include a swarming
mechanism and transport compression from the start, at least for bigish
files). Then, in a manner similar to but not the same as Freenet,
popular things propagate, while unpopular things eventually disappear.
Things (triples AND files) spread when people download and keep them.
That increases their availability. And thanks to the digital
signatures, you know a message is from who it appears, even if you're
downloading it through someone else.
Of course, all that would take place behind the scenes. In the
hypothetical forum client, you'd see a list of forums you subscribe to,
and you could view recent posts in any of them, and post new messages.
I think this demonstrates fairly well what such a simple extension to
the traditional P2P paradigm could bring. Extending it further, we
could have anonymous blogs, websites, etc. *without* a designated file
store, whether central (i.e. HTTP) or distributed (i.e. Freenet or
Stasher). And as I said, there would no doubt also be a plain
file-searching client, perhaps as a module for GiFT or mlnet so we
instantly have a bunch of full-featured clients.
Any comments/criticism, anyone? Better/worse than porting Gnutella,
etc.? Too much effort? Potential problems? 'Tis just a thought. A very
long thought, but just a thought. Whether or not anyone likes the idea,
I'm just hoping it can lead to some insightful discussion and useful
results.
-- Adam Atlas, non-anonymous Semantic Web geek
[1] http://www.w3.org/RDF/
[2] http://www.w3.org/TR/rdf-syntax-grammar/
[3] http://www.taguri.org/
[4] http://dublincore.org/
[5] http://www.w3.org/TR/rdf-schema/#ch_reificationvocab
On 2005-04-15, thus spake closedshop <closedshop at gmx.de>:
>Hi
>we need a simple gnutella client with accepting magnet links workable
>over i2p.
>then all users will come.
>It woudl be best, if this gnucleus dna is installed with i2p installer.
>cause gnutella is most c++ and i2o is java, we need a exe installer,
>which isntalles both on windows.
>See here these simple gnutella clients.,
>the first one is quite easy and has a good design.
>
>http://www.diyp2p.com/
>http://www.slyck.com/forums/viewtopic.php?t=10570
>
>It this is done, we will see all other second generation apps
>chanionging thier sockets for i2p.
>So make an initial phase, please.
>
>thanks
>_______________________________________________
>i2p mailing list
>i2p at i2p.net
>http://i2p.dnsalias.net/mailman/listinfo/i2p
_______________________________________________
i2p mailing list
i2p at i2p.net
http://i2p.dnsalias.net/mailman/listinfo/i2p
----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144 http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
http://moleculardevices.org http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050422/8e2fbeb7/attachment.pgp
More information about the P2p-hackers
mailing list