gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] On applications using GNUnet


From: Schanzenbach, Martin
Subject: Re: [GNUnet-developers] On applications using GNUnet
Date: Sun, 4 Aug 2019 19:05:03 +0200

Hi Alessio!


> On 4. Aug 2019, at 16:17, Alessio Vanni <address@hidden> wrote:
> 
> Hello everyone.
> 
> I've been following the project for a while and, besides keeping the
> peer active when possible, I've also tried developing some simple
> clients/services.  In this mail I want to report a couple of things I
> think are a problem and ask some questions to some things I couldn't
> fully grasp by reading the documentation or various papers.
> 
> The first thing is a "user interface" issue: when I develop a client
> following the handbook, if I run it with the '--help' or '--version'
> flags I get messages that do not apply to my program.  The help message
> prints a series of messages related to the GNU project, of which my
> simple program is not part of.  Also, it says that the bug reporting
> address is GNUnet's one instead of my own.  The '--version' flag is
> similar, in which it prints '0.11.6' instead of e.g. '1.0' (the version
> of my program.)

You are right. This is currently hardcoded into the getopt helper.
Might be reasonable to open a bug for this.

> 
> A similar issue is that if I use autoconf I can't include my own
> config.h file, as many entries there are overridden by gnunet_config.h.
> In particular, macros like PACKAGE are defined with the GNUnet's value
> rather than mine.  If I include config.h after gnunet/platform.h, I get
> a number of warnings about redefining already defined values.

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.

> 
> Similarily, I think gettext is broken but I'm not sure about this one.
> 
> Actually, I've hacked GNUnet a bit to fix this issue, by creating a
> GNUNET_APPLICATION parallel to GNUNET_PROGRAM.  I'd like to submit my
> work, but I'm not sure how to do that.  It spans a lot of commits and
> making each of them a patch seems unwieldy.

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.

> 
> Another issue I've met while developing a service is that ARM can't find
> it unless it's installed in the same directory as the default services.
> I'm not sure if there is another way to test services, nor if there is a
> way to let ARM scan other paths.
> 

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?

> A question on CADET: I wrote a silly program that scans each peer
> checking if a specific port is open (it was part of an experiment.)  The
> documentation says that if the port is closed a certain callback is
> called, but when I tried it the function is never called until the
> channel is destroyed by disconnecting from the CADET service.  Actually,
> I log a message when the function is called, but this message is never
> printed until the program exits.  I can't tell if I'm doing something
> wrong because the documentation is either outdated (at least the one in
> the website) or somewhat cryptic.  The question is how to make sure the
> connection with the other peer is established.  Do I have to send a
> message and see what happens?

Maybe the others can comment here.

> 
> Lastly, a question on GNS, which is the part I understood less: let's
> say I'm walking down the street and see a flyier advertising something
> and saying something like "visit us on GNUnet at party.fun".  Let's also
> say I don't have GNUnet installed, so when I get back home I install it
> and try to resolve the "party.fun" address.  What happens then? Do I get
> something or not? If I do, what do I get?  In particular, is "fun"
> unique like with DNS? If not and is resolved, do I get a single result
> or multiple ones?  Sorry for the barrage of questions, but I'm having a
> hard time understanding some of GNS's implications.
> 

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.


BR
Martin

> Thank you in advance.
> 
> A.V.
> 
> P.S.: I'm not subscribed to the list, so please CC me in your replies.
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

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