On 10/20/2012 05:58 PM, Ivan Shmakov wrote: >>>>>> Christian Grothoff <[email protected]> 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.
Not quite. It would be more accurate to say that MESH is build on top of the DHT, and the DHT sits on top of CORE. And yes, as MESH is still under very active development, there is not much documentation on it. Work-in-progress ;-). > 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.) Having many processes allows us to isolate problems and manage concurrency without locking. And actually, the libraries you're talking about typically contain very little of the actual logic, most of it is in the services (the 'daemons' you're talking about). Aside from that, I don't think it should make any difference for a normal user if we have one process or a dozen in terms of making it "simpler". Happy hacking! Christian _______________________________________________ Help-gnunet mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-gnunet
