[Top][All Lists]

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

Re: [GNUnet-developers] On applications using GNUnet

From: Alessio Vanni
Subject: Re: [GNUnet-developers] On applications using GNUnet
Date: Mon, 05 Aug 2019 13:53:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

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 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

> You could get an account and push it as a branch.
> Alternatively, maybe fork 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 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 "" 
> 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.


reply via email to

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