Re: [GNUnet-developers] On applications using GNUnet

[Alessio Vanni]

Hi Martin,

> Are you building your app in a separate source tree (gnunet-ext) or inside 
> gnunet?
> If it is the latter, then this is the expected behaviour.
> If it is the former, then this might also be an issue that could be addressed
> in gnunet-ext => bugreport.

At first I used gnunet-ext, but then I started writing everything from
scratch, from configure.ac to the client/service's source code.  It
actually ended up being very similar to gnunet-ext, but it was a nice
learning experience (the differences were mostly in the directory tree
structure and "meta" files like Makefile.am.)

> You could get an account and push it as a branch.
> Alternatively, maybe fork https://gitlab.com/gnunet/gnunet and push your 
> changes
> in your gitlab account. Eventually we/you can merge it. But at least we can 
> all look at
> it first then ;)
>
> This is a great example for how our onboarding and collaboration is, well,
> at this time not-existant. At least not in the way git{hub,lab} allows you
> to contribute.

The plan was to submit it for review and change anything if needed.
I'll try submitting a pull request on Gitlab in a few minutes.  I
haven't had the chance to use Gitlab for this kind of thing yet, so I
need to understand how it works first.  I'll also try to include a
summary of the work done.

> Yes, your service must be installed under $GNUNET_PREFIX/gnunet/libexec in 
> order for
> ARM to find it. If your service is a GNUnet service, it is reasonable to
> enforce/expect this also for 3rd party services. Does this limit you in
> any way?

On Gentoo (which I use as my main Linux distribution) until some months
ago, /lib and /usr/lib were symlinks to /lib64 and /usr/lib64.
Nowadays, instead, those became real directories containing 32bit
libraries (e.g. since I occasionally have to use wine, I have some files
there.)  Because of this change, I can't install my GNUnet service in
/usr/lib anymore but have to explicitly use /usr/lib64.  If I hardcode
it, however, it is not guaranteed that I can always safely install in
/usr/lib64 on every other distribution: it is always possible for a
distribution to do the opposite, i.e. change /usr/lib to /usr/lib32 and
/usr/lib64 to /usr/lib, for example.  There aren't any that do this as
far as I know, but it can be done.  It wouldn't really be an issue if I
always pass the '--with-gnunet' argument to configure, but I also expect
configure to automagically find the GNUnet installation, especially if
it's in a "standard" place (maybe thanks to a package manager) without
having to explicitly pass it as an argument.  I can't think of an easy
way to do it within configure.ac and, as far as I could see, it seems
GNUnet doesn't explictly export GNUNET_PREFIX (as a variable or even
something else.)

> Basically GNS is a "petname" system. Which means that you decide on
> your names in your local root zone (e.g. TLDs). Similar to how you choose
> names for your contacts in your phone.
> In your example, you would most likely find a QR code on that flyer which you 
> tell you
> a public key.
> I guess the most practical way would be to take a photo of the flyer first.
> At home, you would scan the QR code using your PC and retrieve the public key.
> You can store this public key under any TLD you wish, could
> be "fun" or "flyer" or anything really. There are no global names in GNS as
> there is no global registry such as ICANN (or a consensus like in 
> blockchains).
> (The gnunet-qr tool is there to help with this import)
> When you have imported that key, you can resolve the website as "party.fun" 
> OR "party.flyer" etc.
>
> Now, GNS actually does feature globally unique naming as well but only if you
> use public key hashes as the TLD.
> For example, if the QR code on the flyer encodes a public key "P", then the 
> name
> party.<hash(P)> is a valid name and globally resolvable for anybody.
> Unfortunately, it is hard to remember that for humans so only really 
> feasible/useful for
> applications that require unique names.

I see.  I'll explore gnunet-qr then, and maybe come back if there are
still some obscure parts.

> BR
> Martin

Thank you.

A.V.