[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] GNS changes
From: |
ng0 |
Subject: |
Re: [GNUnet-developers] GNS changes |
Date: |
Thu, 23 Feb 2017 10:29:28 +0000 |
On 17-02-22 21:39:15, Christian Grothoff wrote:
> 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.)
Does this mean that the previous requirement of a unix group "gnunetdns"
is gone as well?
> 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.
>
>
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers