[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnunet] email-like service atop of GNUnet?
From: |
Ivan Shmakov |
Subject: |
Re: [Help-gnunet] email-like service atop of GNUnet? |
Date: |
Sat, 20 Oct 2012 22:58:42 +0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) |
>>>>> Christian Grothoff <address@hidden> writes:
>>>>> On 10/20/2012 05:14 PM, Ivan Shmakov wrote:
[…]
>> That being said, I don't quite understand how do I search the data
>> stored under namespaces as currently implemented? I've tried to
>> publish some data with a command like:
>> $ gnunet-publish -P 〈pseudonym〉 -t 〈name〉 …
> Use
> gnunet-search gnunet://fs/sks/PHASH/<name>
ACK, thanks! (Is it documented anywhere, BTW?)
Do I understand it correctly that there's no way to list all (or
some) the names under a specific namespace?
> where PHASH is the hash of the public key of your pseudonym
> (gnunet-rsa can be used to display it).
Well, $ gnunet-pseudonym -o did it for me.
[…]
>>> The SecuShare people are working on that; GNUnet's mesh routing
>>> infrastructure will be the basis for that, so I'd say message
>>> exchange between users is work-in-progress ;-).
>> Indeed, I feel their goals worth pursuing (and their ideas align
>> with my own), but I'm somewhat in doubt as to to what extent they're
>> going to re-use the existing GNUnet code base?
> I believe they are firmly committed to building it on top of the MESH
> API (GNUnet's multicast infrastructure).
Unfortunately, I don't seem to understand the details of
interaction between the subsystems comprising GNUnet.
As per [1], my understanding is that the underlying P2P protocol
is provided by libgnunetcore. The routing (that allows for the
“distant” peers to be connected) is then the responsibility of
MESH. Which, in turn, is used to implement DHT and the
filesharing facility, though I fail to understand their relation
to one another. And, as it seems, the only definitive source on
their operation is, well, the source.
One valid point from SecuShare, though, is that we may (in
certain situations) benefit from a “simpler” infrastructure.
Which makes me wonder, what is the purpose of the multitude of
daemons GNUnet currently relies upon? And what would be the
implications of having an occasionally-run, and perhaps
one-binary, GNUnet filesharing application? (AIUI, such an
application is possible, given that the most part of GNUnet is
implemented within a set of libraries.)
TIA.
[1] https://gnunet.org/node/37
[…]
--
FSF associate member #7257