Hi, I think I "fixed" the proxy. It is not pretty but works for me now.
> On 5. Mar 2018, at 18:42, Christian Grothoff <[email protected]> wrote: > > On 03/05/2018 05:14 PM, Schanzenbach, Martin wrote: >> Hi, >> >> I need two clarifications as this change basically broke everything ;) > > "everything"!? :-( > >> 1. API: >> The GNS_lookup API call takes a zone to look up in. Previously tools looked >> up the "gns-master" for a sane default value. >> This is no longer needed I guess?? >> If yes, we should remove it. > > It is needed, because the API allows a _personalized_ lookup. > When I have a multi-user system, the gnunet-service-gns runs as > "gnunet", while the client runs as some other user. The idea is that > this other user may have the .TLD=PKEY configuration file options or the > identities, which determine the zone. So the client should first > determine the zone based on the TLD (and determine whether GNS should be > used in the first place), and then trigger the lookup for what remains > of the name. > > That said, I do intend to add a convenience API where libgnunetgns > determines the zone based on the TLD. > >> 2. Proxy: >> The proxy still uses gns-master for lookups. Now the question is if the >> application calling lookup should handle the TLD or of the resolver takes >> case of that automagically. From your change in the CLI tool I assume the >> former? > > I've not yet finished (or started) work on the proxy. I guess I should > finish the convenience API first, as that will be helpful for the proxy > as well. > > Happy hacking! > > Christian > - Martin GPG: 3D11063C10F98D14BD24D1470B0998EF86F59B6A
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
