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. _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
