gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] GNS changes


From: Christian Grothoff
Subject: [GNUnet-developers] GNS changes
Date: Wed, 22 Feb 2017 21:39:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0

This is mostly for Lynx and Martin, but might be of interest to the rest...

I want to briefly explain what I've done with 9bc1c69e2..cd9531932 ...


The above change *removes* support for reverse lookups and shortening
from the GNU Name System. Entirely. Gone from the API....

But *not* gone from what we'd like to have!  Basically, with #4849 I'm
fixing three things:

1) GNS service must run as user 'gnunet', as it needs to access the
'dns' service, which is UID-restricted in the strict security model; at
the same time, GNS service with shortening OR reverse lookup needs to
run as $USER as it needs access to namestore (which is per-user). Eh,
great, how am I supposed to setup my permissions again?  So by NOT
having those two functions in GNS, I fix this BIG problem.  (Note that
moving the 'publish GNS zone to DHT' into 'zonemaster' earlier, I
removed the remaining namestore dependency of GNS.)

2) Shortening was always a UX nightmare, as we ultimately would want the
user to approve the shortening explicitly. By not having GNS do this,
some UX can do it explicitly itself (by putting records into namestore
based on NICKs it encounters), thereby addressing the UX issue.

3) Reverse lookups don't really use the GNS protocol (no DHT!), and you
both have discussed various "better" ways to reverse names.  If an app
needs what GNS did provide, it can just go into NAMESTORE directly and
grab the value there.  And by NOT having the reversal API conflated with
GNS, we _also_ make it easier for both of you to develop fun new name
reversal protocols/subsystems to your heart's content.


Not to mention the GNS logic is complicated enough, no need to bamboozle
GNS code reviewers with shortening and reversal which are really
orthogonal issues to the simple task for forward name resolution. We
don't need to recreate the DNS kitchen-sink.


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]