Re: Gnunet-scheme usage

Maxime Devos <[email protected]> Mon, 24 Jul 2023 22:12:40 +0200
Newsgroups gmane.network.gnunet.general
Message-ID <[email protected]>
(I don't check e-mails often, but they do arrive!)

Op 19-07-2023 om 21:01 schreef MSavoritias:
> 
> Hey,
> 
> I am interesting in using gnunet-scheme to write an application. I am
> looking into writing an xmpp based application in particular. Its still
> in early stages and I am thinking what network to use for it.
> 
> I stumbled upon guile-gnunet and gnunet-scheme. From these two
> gnunet-scheme seems to be the actively developed one.
 >
> What I wanted to ask was:
> 
> 1. Is gnunet-scheme intended to be used to write applications that use
> gnunet, re:claimID, GNS and such? From the docs it seems so but wanted to
> confirm.

Yes.  It also is intended for writing new services (i.e. the equivalent 
of gnunet-service-SOMETHING), though support for that is very manual
(see e.g. the spaghetti that is simulate-dht-service in 
tests/distributed-hash-table.scm).

That could perhaps be something you could work on?

Even if you are only focusing on the application side of things, being 
able to write services (with less spaghetti than simulate-dht-service) 
in Scheme can be very useful for automated testing of the application.

> 2. I guess it is not too far along since there is a lot of todo to be
> done. So I am guessing even if thats the goal not yet?

Yes.
> I am using guix already and I would be interested to contribute to
> gnunet-scheme to push it forward if that is welcomed of course. The xmpp
> app will be written in guile itself. I can help with docs specifically
> since I am going to start to make something out of it. Which from what I
> saw hasnt been done yet.
> And in gnunet itself of course.

Most of the ‘public’ API is documented (though there are a few things 
missing in the manual) -- often, for me the hard part is designing the 
API (*).  As this is roughly the same as writing documentation of the 
API, often I write the documentation before the implementation. 
(Although at times the documentation will turn out to need some changes 
from what I initially had in mind.)

More to the point, most important things are documented, and I actually 
like writing documentation, it's fiddling with the implementation (and 
implementing its dependencies) and tests that comes more difficult.

(Now I read the previous two paragraph again, I notice they contradict 
on what's more difficult -- I don't know how to resolve that.)

To start working with gnunet-scheme and to become familiar with it, I 
would instead propose what I wrote in ‘Writing new (gnu gnunet ... 
struct) modules, converted from C’ (chapter: Manipulation of network 
structures) (**) -- IMO, it's a bit tedious, but at the same time it is 
quite simple, and once you do it you will have a better feel on how the 
service you are porting actually works, which is very useful for doing 
the port.

(Or you could do something else of course, more than one road to Rome etc.)

(*) TBC I plan on eventually changing some parts -- e.g. in retrospect I 
don't think that ‘quajects’ has been useful for (gnu gnunet config db).

(**) I wrote this section while writing this mail, so you might need to 
pull.

Best regards,
Maxime Devos.
OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, 912 B)
-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m
xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2
ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL
CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc
/gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4
LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C
kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK
CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W
ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ
Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0
k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo
AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE
fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA==
=OVqp
-----END PGP PUBLIC KEY BLOCK-----
OpenPGP_signature (application/pgp-signature, 236 B) - not displayed