Re: based GNUnet decentralized IP address, Abolish ipv4 and ipv6

[Maxime Devos]

Op 13-12-2023 om 07:07 schreef Christian Grothoff:

Dear aiss,

GNUnet already uses public keys for addressing and routing in the 
CORE/DHT/CADET layers (and above), effectively replacing IP addresses 
that are created in a decentralized way. Only the transport layer which 
adapts the protocol to run over existing Internet connections we have IP 
addresses. However, it is possible to write communicators for the 
transport layer that do not use IP at all, for example by directly using 
Ethernet/WLAN and bypassing TCP/IP entirely.


Happy hacking!


Adding to this: there are also IP addresses in the GNS system. However, 
there is also a ‘VPN record’ which IIUC can be used to communicate via 
CADET (which, IIUC, doesn't have all the right security and anonymity 
properties _yet_, but could have them in the future).


Best regards,
Maxime Devos.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: RFC 9498: The GNU Name System

[Maxime Devos]

Op 21-11-2023 om 08:34 schreef Schanzenbach, Martin:

We are happy to announce that our *The GNU Name System* (GNS)
specification is now published as RFC 9498 [0].



in order to transparently enable this functionality for migration purposes, a 
local GNS-aware SOCKS5 proxy [RFC1928] can be configured to resolve domain names


Are you sure this is transparent?  Consider the case where a website has 
a log-in system, and instead of being based on passwords, it is based on 
TLS client certificates (for example, https://ci.guix.gnu.org/ has such 
a system to decide who is allowed to adjust ‘specifications’ and 
‘restart builds’).


Given that the SOCKS5 proxy is technically a MITM attack, and the client 
certificates instead of only server certificates, I would expect (and 
hope) that the SOCKS5 proxy can't convince the server that it is the client.


It's a somewhat niche use case, so mostly transparent, sure.
But transparent, without qualifiers, I don't think so.

Best regards,
Maxime Devos


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Help needed with compilation

[Maxime Devos]

On 01-09-2022 13:20, Nirvin M wrote:

Hello GNUnet developers,

Not really a GNUnet developer myself, but ...


I would like to contribute to GNUnet with the goal of making the UX 
easy. I'm trying to compile gnunet with the instructions here 



However, `make` command fails with

*make: *** No targets specified and no makefile found.  Stop.*

Can anyone please help with this?

... does "Makefile" exist? If not, you might have forgotten to run 
"./configure --prefix=/usr/local --disable-documentation".


Greetings,
Maxime


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: gnunet-go R5N

[Maxime Devos]

On 18-08-2022 15:10, Bernd Fix wrote:

A new version (v0.1.32) of gnunet-go is availble at 
https://git.gnunet.org/gnunet-go.git that should be ready for 
integration tests. Some major and minor bugs have been fixed that have 
escaped attention before. A lot of code refactoring happened too...


The new README includes a new section on how to run tests yourself; 
you might try that yorself. Any feedback on problems or failures welcome.


Cheers, Bernd.


Looking at the README.md, do I understand correctly that gnunet-go 
listens at the usual /tmp/gnunet-system-runtime/... and that as such 
applications written with the C implementation of the services in mind 
can connect to the Go implementation?  If so, I'd like to eventually 
test gnunet-scheme (a (Guile) Scheme implementation of the client 
libraries, but not the services) against it.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Pushing to the repos

[Maxime Devos]

On 03-08-2022 20:02, Maxime Devos wrote:


On 03-08-2022 19:47, Willow Liquorice wrote:

Hello,

Given that I'm getting repository access soon, I'm getting my changes 
ready to be pushed.


I need to sign my commits, is that with the SSH key pair?


Signing commits is done with GnuPG, telling git.gnunet.org that you 
are allowed to do stuff there is done with SSH; you will need to 
create both and share the public parts -- the public part of the SSH 
key is only needed by those who manage that machine, the public part 
of the GnuPG is required to be public (such that people can verify the 
commits).


I recommend adding

[commit]
    gpgsign = true

to .gitconfig to automatically sign commits.

Is the guide in the developer's manual in line with current practice? 
I've never used a VCS collaboratively before, and I'm a bit worried 
about screwing up my first major contribution.


I do not know if there's a guide there, maybe there is, but I haven't 
looked myself.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Pushing to the repos

[Maxime Devos]

On 03-08-2022 19:47, Willow Liquorice wrote:

Hello,

Given that I'm getting repository access soon, I'm getting my changes 
ready to be pushed.


I need to sign my commits, is that with the SSH key pair?


Signing commits is done with GnuPG, telling git.gnunet.org that you are 
allowed to do stuff there is done with SSH; you will need to create both 
and share the public parts -- the public part of the SSH key is only 
needed by those who manage that machine, the public part of the GnuPG is 
required to be public (such that people can verify the commits).


I recommend adding

[commit]
    gpgsign = true

to .gitconfig to automatically sign commits.

Is the guide in the developer's manual in line with current practice? 
I've never used a VCS collaboratively before, and I'm a bit worried 
about screwing up my first major contribution.


The main benefit of VCS like Git is that if you somehow screw up, you 
can often recover easily. Even if somehow you delete all contents of the 
git repo at git.gnunet.org, other people have their own local copy that 
can be pushed on git.gnunet.org to undo the breakage.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: New SSH key

[Maxime Devos]

On 26-07-2022 23:40, Christian Grothoff wrote:
Done. In general, please send these types of requests directly to me 
or Martin, no need to bother the list.


-Christian 

Thanks, and noted, I've pushed some new commits now.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

New SSH key

[Maxime Devos]

Hi,

I'll be using a new SSH key: 'ssh-ed25519 
C3NzaC1lZDI1NTE5IPJa2FK5j9V6zkxVcvyvBQnt8dbXIXEABwO3rQZIhQ08'; 
the list of SSH keys for gnunet-scheme.git needs to be updated.


Also, there is no description on https://git.gnunet.org, for 
gnunet-scheme maybe:


GNUnet client implementation in (Guile) Scheme

Greetings,
Maxime



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Packaging problems

[Maxime Devos]

Martin Schanzenbach schreef op ma 06-06-2022 om 16:52 [+]:
> > As Maxime says, GNUnet takes a long time to compile (when it
> actually
> > does - I'm having problems with that right now), and presumably
> quite
> > a 
> > while to test too. The obvious way to reduce those times is to
> simply
> > *reduce the amount of code being compiled and tested*. Breaking up
> > the 
> > big repo would achieve that quite nicely.
> 
> It really does not (on modern hardware).
> See:
> https://copr.fedorainfracloud.org/coprs/schanzen/gnunet/build/4501586/
> 
> It takes around 7mins to install & compile from scratch (this
> includes
> installing all dependencies!).
> 
> IMO right now "make check" is kind of annoying because it takes too
> long and fails because of bad test design. It needs some love.
> Maybe a high-level, quick "make check" and an optional "make check-
> thorough" idk.

FWIW, I included "make check" time in compilation time (from Guix'
perspective, running tests is just yet another compilation).  And the
computer I use for compilation isn't exactly modern -- according to the
timestamp on /etc/host.conf, it's ~16 years old ... wait no, cannot be
right ...  I'm not sure about the exact year, but at least ~5 years I'd
say?  And that's the current computer (*) which has an SSD, whereas the
computer(^) I used back then for GNUnet was older and had an old
spinning disk.  I guess that isn't representative.

(*) currently held together by duck tape, missing a few screws, keys,
part of the frame and has a crack in the screen -- I cannot recommend
Lenovo Yoga computers.

(^) screen is broken unless a sea star is inserted between the keyboard
and the screen in the right place at the right depth and angle.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Packaging problems

[Maxime Devos]

Willow Liquorice schreef op do 02-06-2022 om 14:44 [+0100]:
> While I was working on the documentation, I decided to put a Repology 
> badge at the top level of the install page, and then I saw the extent of 
> GNUnet's packaging woes. There are more distros with severely outdated 
> versions than ones that are up to date, even the rolling release ones 
> that have comparatively lax stability requirements.
> 
> What's the deal with that? This sort of thing only hurts the project.
> 
> Best wishes,
>   Willow
> 

In case of Guix:

  * lots of failing tests (has been fixed recently, current version
should now be up to date)

  * takes long to compile (not unique to gnunet), which makes testing
changes to the packaging of gnunet require much more time.

Greetings,
Maxime


signature.asc
Description: This is a digitally signed message part

Re: GNUnet Name System not working (as expected)

[Maxime Devos]

Tanguy LE CARROUR schreef op ma 11-04-2022 om 09:13 [+0200]:
> Correct (again)! I activated UPNP on my box and the error disappeared.
> But, I cannot do the same on my other computer because I have no control
> over the "box" and cannot forward ports!
> 
> Does this mean that I cannot use GNUnet on this computer?!

IIRC there is also a TCP transport that can function without port
forwarding (at least, if a sufficient amount of peers have the TCP
transport with a public port).

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Building gnunet and gnunet-gtk from git on GUIX

[Maxime Devos]

Marcin Skrzypek schreef op zo 03-04-2022 om 17:25 [+]:
> 
> (define-public gnunet-git
>   (package
>    (name "gnunet")
>    (version "0.16.3")
>    (source (local-file "/home/gnunet" #:recursive? #t))
>    (build-system gnu-build-system)
>    (inputs
>     `(("bluez" ,bluez)

FWIW, this can probably be simplified to

  (define-public gnunet-git
(package
  (inherit (@ (gnu packages gnunet) gnunet))
  (version "0.16.3")
  (source (local-file "/home/gnunet" #:recursive? #t))
  (arguments [...])))

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Building gnunet and gnunet-gtk from git on GUIX

[Maxime Devos]

Marcin Skrzypek schreef op zo 03-04-2022 om 17:25 [+]:
> To install GNUnet from git on GUIX I use modified (removed check
> phase) package definition as tests fail:

Which tests are failing?  Maybe the bug can be fixed.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Building gnunet and gnunet-gtk from git on Guix

[Maxime Devos]

Marcin Skrzypek schreef op zo 03-04-2022 om 17:25 [+]:
>         ;;"--with-gnunet=/gnu/store/7hbk1a4f59zzp9rfav8xmxcfczb995s1-
> gnunet-0.16.3/" 
> ;;"--with-gnunet=/gnu/store/7hbk1a4f59zzp9rfav8xmxcfczb995s1-gnunet-
> 0.16.3/include"

If I'm not mistaken, due to reasons, you need the ungrafted file name
here, not the grafted file name probably returned by "guix build
gnunet(-git)".  Maybe try:

 (arguments
   (list #:configure-flags
 #~(list "--with-[...]"
 (string-append "--with-gnunet="
#$(this-package-input "gnunet")))
 #:tests? #false))

(untested)

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Building gnunet and gnunet-gtk from git on GUIX

[Maxime Devos]

Marcin Skrzypek schreef op zo 03-04-2022 om 17:25 [+]:
> To install GNUnet from git on GUIX I use modified (removed check
> phase) package definition as tests fail:

This does not answer your question, but it's named Guix, not GUIX.  The
reddit's name is a lie.  Also, the standard way of disabling tests is
adding #:tests? #false to the package definition.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Attacking the documentation monster

[Maxime Devos]

William Liquorice schreef op di 01-03-2022 om 19:51 [+]:
> Hello,
> 
> A year or two ago, I tried to wrap my head around GNUnet so that I could 
> try to make parallel implementations of small bits in Rust, but found 
> its documentation to be utterly impenetrable. Not even from a technical 
> standpoint, the massive reference manual / "handbook" is quite 
> overwhelming and more akin to the Lord of the Rings.
> [...]

While it's not explicitly mentioned, going by the subject line, it
seems you are interested in improving the documentation?

If so, perhaps you might be interested in the documentation for the
‘gnunet-scheme’ WIP port (*)
(https://git.gnunet.org/gnunet-scheme.git/tree/doc) I've been writing,
though be aware that the API is somewhat different from the C API.  To
read it, clone the git repo and point TeXmacs at 'doc/scheme-
gnunet.tm'.  Or I can send you a PDF.

This documentation is structured differently from the C documentation,
maybe you'll find it clearer.

Greetings,
Maxime.

(*) Client libraries only, no services (yet?)!


signature.asc
Description: This is a digitally signed message part

Re: LSD0001 review

[Maxime Devos]

Schanzenbach, Martin schreef op do 10-02-2022 om 22:34 [+]:
> While I understand the problem GNS defines strings to be UTF-8
> (notwithstanding punycode exceptions).
> You can't have UTF-8 strings with a zero terminator without having it
> mean exactly that: A string termination.
> 
> Yes, you can say "but what if it is not a UTF-8 string", but that is
> not really the problem of the GNS spec.
> It normatively defines it as such and the implementation must comply
> (with UTF-8).
> See also https://en.wikipedia.org/wiki/Null-terminated_string section
> in "Character encoding".

I thought that UTF-8 supports encoding \0 characters.
For example Guile silently encodes \0 and decodes it again:

$ ((@ (rnrs bytevectors) utf8->string) ((@ (rnrs bytevectors) string->utf8) 
"foo\x00bar"))
> "foo\x00bar"

and Guile claims it is UTF-8:

 Return a newly allocated bytevector that contains the UTF-8, [...]
 or UTF-32 [...] encoding of STR.  For UTF-16 [...].

I guess I'll have to submit documentation patches to Guile and perhaps
even the RnRS.

Greetings,
Maxime.



signature.asc
Description: This is a digitally signed message part

Re: LSD0001 review

[Maxime Devos]

Schanzenbach, Martin schreef op do 10-02-2022 om 22:28 [+]:
> What I mean is that you would not look at a nick like that and think
> "I am going to add this to my zone".
> The use of a NICK is not defined in a normative way.
> There is no action associated with it that is qualified with a MUST or SHOULD.
> So users may consider the NICK record to when adding new PKEY delegations.
> They may choose not to. [...]

I thought that there was a special zone, the ‘pin zone’, that is
_automatically_ populated based on NICK records.  

Anyway, I don't see problems here anymore.
Thanks for the explanation.

Greetings,
Maxime


signature.asc
Description: This is a digitally signed message part

Re: LSD0001 review

[Maxime Devos]

Schanzenbach, Martin schreef op ma 07-02-2022 om 19:02 [+]:
> > > LEGACY HOSTNAME
> > >     A UTF-8 string (which is not 0-terminated) representing the
> > > legacy hostname.
> > 
> > What happens if it contaings \0, or ends with two dots, does that
> mean
> > the LEHO record is invalid and must be rejected?  If it is in
> punycode,
> > why say ‘A UTF-8 string’ instead of ’an ASCII string’?
> 
> It is not in punycode. It is just a UTF-8 string.
> Why is it not 0-terminated? TBH I am not sure, probably to save a
> byte :)

Some context on this question about nul characters.

Consider a C application that is asked to contact http://i.hate.c,
a website about the use of "\0" in C software.  i.hate.c has a LEHO
record with value "foo\0bar.com" (and some VPN or  record).

Perhaps the HTTP spec disallows \0 in the "Host" header,
and the C application hence gives some kind of error message
about not being able to contact i.hate.c.  No problem in this case.

Perhaps the C applications assumes that GNS will only return ‘proper’
hostnames, add a \0 to the end of the record, and
use strlen("foo\0bar.com") (= 3) to determine how large a buffer needs
to be calculated, and copy "foo\0bar.com" (the whole thing of size 12
(including terminating\0)) into the buffer that's only of size 3,
resulting in a buffer overflow.

(Variants of) the second scenario seems plausible to me.

As such, I would recommend forbidding \0 bytes in GNS,
or mentioning problems involving \0 in a section ‘Security
considerations’.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: LSD0001 review

[Maxime Devos]

Schanzenbach, Martin schreef op ma 07-02-2022 om 19:02 [+]:
> > > NICKNAME
> > > 
> > >    A UTF-8 string (which is not 0-terminated) representing the
> > > preferred label of the zone. This string MUST NOT include a "."
> > > character.
> > 
> > Can I have a nickname "SOME-ZTLD"
> 
> Yes.
> 
> > , "@"
> 
> Ah good catch. Yes. But nobody will accept it.
> [...]
> > , "foobar"
> Yes.
> [...]
> > or "" (zero-length string)?.
> 
> Yes
> 
> You can do whatever you like with your string.
> You cannot expect it to be used :)

You say that nobody will accept the "@".
Possibly you also mean that "foobar" won't be accepted
(because many C assume the nul character is only for termination).

However, I don't see anything in the spec telling people not to accept
this @ and .  Does this ‘don't accept this’ need to be
included in the spec somewhere?

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: LSD0001 review

[Maxime Devos]

Schanzenbach, Martin schreef op ma 07-02-2022 om 19:02 [+]:
> > > LEGACY HOSTNAME
> > >     A UTF-8 string (which is not 0-terminated) representing the
> > > legacy hostname.
> > 
> > What happens if it contaings \0, or ends with two dots, does that
> mean
> > the LEHO record is invalid and must be rejected?  If it is in
> punycode,
> > why say ‘A UTF-8 string’ instead of ’an ASCII string’?
> 
> It is not in punycode. It is just a UTF-8 string.
> Why is it not 0-terminated? TBH I am not sure, probably to save a
> byte :)

A follow-up question: LEGACY HOSTNAME can be an UTF-8 string, not in
punycode.  But can it be in punycode, even though that is not
necessary?  Should punycode be forbidden here, in favour of UTF-8?

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Using some GPL comments in GFDL documentation

[Maxime Devos]

Christian Grothoff schreef op ma 07-02-2022 om 13:59 [+0100]:
> Yes, that's fine. -Christian

Done, in commit 1f6ddc48151d5ad47389eb38b901f190c97c4f10.




signature.asc
Description: This is a digitally signed message part

LSD0001 review

[Maxime Devos]

Hi,

> Name
> A name in GNS is a domain name as defined in [RFC8499] as an
> ordered list of labels. The labels in a name are separated using the
> character "." (dot). Names, like labels, are encoded in UTF-8.

Does that mean, no punycode, unlike DNS?  Does GNUnet's GNS<->DNS code
handle punycode conversion?

> GNS TLDs are typically part of the configuration of the local
> resolver (see Section 7.1), and may thus not be globally unique

This reads to me as ’it is forbidden for them to be unique’,
whereas I assume it was meant ‘and thus are not necessarily
globally unique’ -- if I name a TLD, say, maximed-943438-foobar, then
it's probably globally unique.

It's clear from context though, and this sentence can be read
in the latter way as well.

>  In order to further increase tolerance for failures in character
>  recognition, the letter "U" MUST be decoded to the same Base32 value
>  as the letter "V".

Does this mean that, if I point a browser at a zTLD with a 'U',
then the browser should change it to a 'V' (if the browser has GNS
integration)?  How does this interact with the domain name in TLS and
HTTP?  If the server expects a certain (subdomain of a) zTLD, does it
need to recognise equivalent encodings?

Likewise for 1IiLl, Aa, Bb, ...

> TIMESTAMP
> denotes the absolute 64-bit date when the revocation was
>  computed. In microseconds since midnight (0 hour), January 1, 1970
> in network byte order

Do leap seconds count? What timezone is this?

> DNS NAME
>The name to continue with in DNS. The value is UTF-8 encoded and >
0-terminated.
> DNS SERVER NAME
>The DNS server to use. May be an IPv4 address in dotted-decimal
> form or an IPv6 address in colon-hexadecimal form or a DNS name.

How is using a DNS name for the DNS server supposed to work, how are
we supposed to resolve the name of the DNS server without a pre-
existing DNS server?  This seems rather cyclic.

Perhaps the ‘standard’ DNS root servers need to be contacted
(indirectly, via the ISP's DNS servers)?

If the peer doesn't have DNS set up, or it does have DNS set up
by redirecting it to GNS, what is supposed to happen?

Can I use localhost or loopback as IP address?
If I can use localhost or loopback here, how is that interpreted?
The peer that initiated the GNS query?  The peer that contacts the DHT
system?  The peer that created the GNS record?

> It
> may also be a relative GNS name ending with a "+" as the rightmost
> label. The implementation MUST check the string syntactically for an
> IP address in the respective notation before checking for a relative
> GNS name. If all three checks fail, the name MUST be treated as a DNS
> name. The value is UTF-8 encoded and 0-terminated.
>
>  NOTE: If an application uses DNS names obtained from GNS2DNS records
in a DNS request they must first be converted to a punycode
representation [RFC5890].

I'm not sure what this note means exactly.  Does this mean that DNS
NAME and DNS SERVER NAME must be in punycode?  Or do they not need
to be in punycode, instead the name in the record should be converted
into punycode before contacting the DNS server?

Are IPv6 addresses with surrounding [] or without?

> LEGACY HOSTNAME
> A UTF-8 string (which is not 0-terminated) representing the
>  legacy hostname.

What happens if it contaings \0, or ends with two dots, does that mean
the LEHO record is invalid and must be rejected?  If it is in punycode,
why say ‘A UTF-8 string’ instead of ’an ASCII string’?

> NICKNAME
>
>A UTF-8 string (which is not 0-terminated) representing the
> preferred label of the zone. This string MUST NOT include a "."
> character.

Can I have a nickname "SOME-ZTLD", "@", "foobar", "foo;bar",
"foo@bar", "@", "an UTF-8 string not in canonical form",
"special PURPOSE
> A 32-bit signature purpose flag. For a RRBLOCK the value of this
> field MUST be 15. The value is encoded in network byte order. The
> value of this field corresponds to an entry in the GANA "GNUnet
> Signature Purpose" registry.

What should happen if unrecognised flags are encountered?

>  7.3.3. BOX
> 
> When a BOX record is received, a GNS resolver must unbox it if the
> name to be resolved continues with "_SERVICE._PROTO". Otherwise, the
> BOX record is to be left untouched. This way, TLSA (and SRV) records
> do not require a separate network request, and TLSA records become
> inseparable from the corresponding address records.

What happens if try to run a web server at
"http://_SERVICE._PROTO.domain.tld" (assuming there's a  record
or something there) and the user points the browser
at "http://_SERVICE._PROTO.domain.tld;? Success, failure?

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

LSD0004 call for reviews

[Maxime Devos]

> Block Storage
> The Block Storage component is used to persist and manage data by
> nodes. It includes logic for quotas, caching stragegies and data
> validation.

stagegies -> strategies

> Responsible Peer:
> The peer N that is responsible for a specific resource K, as
> defined by the SelectClosestNode(K, N) algorithm (see Section 7.

missing closing parenthesis

>  In order to achieve O(log n) routing performance

> 0: Demultiplex-Everywhere
indicates that each node along the way should process the request.

What's the advantage of not doing this by default?  And what is
Demultiplex-Everywhere useful for?

> 3-15: Reserved
> For future use.

What should a peer do when it encounters one of these?
Set it to zero? Ignore the unknown flags? Drop the message?
Disconnect from the peer that sent it?

> EXPIRATION
> denotes the absolute 64-bit expiration date of the content. The
> value specified is microseconds since midnight (0 hour), January 1,
> 1970, but must be a multiple of one million (so that it can be
> represented in seconds in a HELLO URL). Stored in network byte order.

What should a peer do when the expiration isn't a multiple of one
million?  Round it, drop it?  What's the problem with not exactly
being representable in a HELLO URL when it's not exactly a multiple
of one million, wouldn't an approximation do?

> ADDRESSES
> A sequence of exactly URL_CTR 0-terminated URIs in UTF-8 encoding
> representing addresses of this peer. Each URI must begin with a non-
> empty URI schema terminated by "://" and followed by some non-empty
> Underlay-specific address encoding.

If I have two addresses FOO and BAR, do they need to be encoded as
FOO<0 byte>BAR or FOO<0 byte>BAR<0 byte>?  What should the peer do
if it encounters superfluous 0 bytes: FOO<0 byte><0 byte>?  Is a
sequence of zero URLs acceptable?  If a sequence of zero URLs is
acceptable, does it need to be encoded as <0 byte> or ?

What should happen if the field is bogus?  Why zero-encoding and not
length-prefixed?  Length-prefixed is IMHO easier to parse, with less
chance of going out-of-bounds.

> PATH_LEN
>is a 16-bit number indicating the length of the PUT path recorded
>in PUTPATH. As PUTPATH is optional, this value may be zero. In
>network byte order.

Is this optional even when Record-Route is specified?  Is this 'length'
the number of path elements, or the byte size of all the path elements?

> HOPCOUNT
> is a 16-bit number indicating how many hops this message has
> traversed to far. In network byte order.

Wouldn't PATH_LEN = HOPCOUNT when Record-Route is requested?  What's
the difference?

> EXPIRATION
> denotes the absolute 64-bit expiration date of the content. In  
>  microseconds since midnight (0 hour), January 1, 1970 in network
> byte order.

Do leap seconds count? How about time zones?

> REPL_LVL
> is a 16-bit number indicating the desired replication level of
>  the data. In network byte order.

What about its bounds?  The GNUnet DHT service imposes some bounds,
e.g. it requires it to be >0 and <=10 IIRC.


> BLOCK
> the variable-length block payload. The contents are determined by
>  the BTYPE field.

How do I know the length of this payload? 

>  The EXPIRATION field is evaluated. If the message is expired, it
>  MUST be discarded.

How can I know if a message is expired, when clocks aren't perfect?
Will an approximation be sufficient?

> If the local node is the closest node (cf. IsClosestNode(N, Key)) or
> the DemultiplexEverywhere options flag ist set, the message MUST be
> stored locally in the block storage.

ist set --> is set

> The implementation MAY forward to fewer or no peers in order to
> handle resource constraints such as bandwidth

So if REPL_LEVEL is 65535, the peer doesn't actually have to forward it
to thousands of peers?  Peers are responsible for stopping
amplification attacks?

Also, wouldn't the number of peers grow exponentially as the message
passes through the network?  The first peers passes it to k other
peers, each peer passes it to another k peers ..., then at step n, 
∑(i=1..n)k^i = ϴ(k^n) have been contacted (assuming no duplicate
peers).

> XQUERYthe variable-length extended query. Optional.

How do I now if this is present?  Is it absent whenever XQ_SIZE=0?

> RESULT_BF
> the variable-length result bloomfilter

How do I know its length?

> OPTIONS
> is a 16-bit options field (see below).

What if there are unrecognised options?

> MTYPE
>is the 16-bit message type. This type can be one of the DHT
>  message types but for put messages it must be set to the value 148
> in network byte order.

Does that mean that no DHT message type has the value 148?

>  9.1. Block Processing 

What about an OK_UNKNOWN result, if it is unknown whether the response
matches the key?  For example, for Guix, we could use the DHT to map
store item names /gnu/store/-foo-1.0 to corresponding GNUnet FS
URIs.  Assuming reproducibility, there's 

Using some GPL comments in GFDL documentation

[Maxime Devos]

Hi,

Some documentation I've been writing for Scheme-GNUnet (GNUnet-
Scheme?) (GFDL1.3+, no invariant sections) is based on comments in
src/include/gnunet_mq_lib.h, but that C header is GPL3+ licensed.  Do I
have permission to use it in the GFDL1.3+ documentation (see
attachement)?

More specifically, I've adapted the comments on
GNUNET_MQ_PriorityPreferences, see attachement.

Greetings,
Maxime.


service-communication.pdf
Description: Adobe PDF document


signature.asc
Description: This is a digitally signed message part

Re: Using GNUnet API for distributed database in an app

[Maxime Devos]

Prayank via Mailinglist for GNUnet developers schreef op wo 15-12-2021
om 06:35 [+0100]:
> Is this the only documentation for APIs https://rest.gnunet.org/ ? Or
> there are any other examples, tutorials etc.? Is there any project
> which uses GNUnet API to achieve something similar? Any other
> suggestions?

GNUnet has a reference manual, a C tutorial and doxygen documentation
at , each documenting GNUnet's APIs in their
own way (though only the C API and REST API; the Scheme, Java, Nim and
Python bindings are elsewhere, and they support less than the C API).

E.g., here's some documentation on the GET operation of the DHT:



I thought GNUNET_DHT_get_start was documented but I cannot find it
anymore ...

Greetings,
Maxime.

Re: Pre-announcement of partial Scheme port of client libraries

[Maxime Devos]

Hi,

Christian Grothoff schreef op wo 15-09-2021 om 16:12 [+0200]:
> Yes, that would be desirable (also for your contributions), as that
> could allow GNUnet e.V. to re-license/dual-license if ever required.
> Note that the process is very simple (one signature), can be done under
> a pseudonym (if you contribute under a pseudonym), and you also get to
> keep the copyright! See https://gnunet.org/en/copyright.html for details.

I printed it and signed it.  Now, where do I sent it?
I would presume the physical copy needs to be sent to

  GNUnet e.V.
  Fakultät für Informatik -- I8
  Technische Universität München
  Boltzmannstraße 3
  85748 Garching
  GERMANY

but were can I send the digital scan?

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Pre-announcement of partial Scheme port of client libraries

[Maxime Devos]

Schanzenbach, Martin schreef op wo 15-09-2021 om 14:26 [+]:
> We should think about how to handle the confusion with the other repos.
> I am not familiar with gnunet-guile(2), but from what you are writing it
> appears as if we may want to consider deprecating and archiving those repos.
> Maybe it makes sense to rename gnunet-guile2 to gnunet-bindings-guile and
> calling yours gnunet-guile or something like that.

Scheme-GNUnet (to be renamed gnunet-guile?) doesn't have enough functionality
yet to deprecate gnunet-guile, as it only supports NSE at the moment.  
Otherwise,
this seems reasonable to me.

Greetings,
Maxime


signature.asc
Description: This is a digitally signed message part

Re: Pre-announcement of partial Scheme port of client libraries

[Maxime Devos]

Christian Grothoff schreef op wo 15-09-2021 om 16:12 [+0200]:
> On 9/15/21 12:57 PM, Maxime Devos wrote:
> > Hi,
> > 
> > I've been porting parts of the client libraries of GNUnet to Guile (*) and
> > changing a few things.  It now has sufficient functionality for a v0.1
> > POC release (**), but I have a few questions to ask before I announce it.
> 
> Nice.
> 
> > (*) See ‘4. Relation to gnunet-guile’ for differences with
> > <https://git.gnunet.org/gnunet-guile2.git/> and
> > <https://git.savannah.gnu.org/cgit/guix/gnunet.git/>;;.
> > (**) It can talk with the NSE service.
> > 
> > 1. Name
> > 
> >I've been calling the port ‘Scheme-GNUnet’.  Would this be acceptable,
> >or do I have to remove GNUnet from the name?
> 
> See https://git.gnunet.org/: usually we'd call it gnunet-scheme. At
> least that'd be consistent with the cocoa, go, nim, java and python
> bindings / integrations...

Right.  I think I'll rename it to gnunet-scheme or gnunet-guile.  The latter
might cause confusion with <https://git.gnunet.org/gnunet-guile2.git> though
...

> > 2. Infrastructure
> > 
> >As it is library for interacting with GNUnet services, I thought
> >the pre-existing gnunet-developers@gnu.org, help-gnu...@gnu.org and
> >info-gnu...@gnu.org mailing lists might be appropriate.  Can I direct
> >people help-gnunet@ for help about Scheme-GNUnet and gnunet-developers@
> >for sending patches for Scheme-GNUnet?  And can I send release 
> > announcements
> >at info-gnunet@?
> 
> Yes, alas I might need to manually approve info-gnunet@ (ditto for
> messages from non-subscribers), so they might arrive with some delay.

Messages to info-gnunet@ will be relatively infrequent, so that shouldn't
be a problem.

> > 3. Copyright assignment
> > 
> >I noticed most source code of GNUnet, with some exceptions, only lists
> >‘GNUnet e.V.’ under the copyright notices.  Would it be possible for
> >contributors to Scheme-GNUnet to (if they want to) assign the copyright
> >to GNUnet e.V.?  And would this be desirable?
> 
> Yes, that would be desirable (also for your contributions), as that
> could allow GNUnet e.V. to re-license/dual-license if ever required.
> Note that the process is very simple (one signature), can be done under
> a pseudonym (if you contribute under a pseudonym), and you also get to
> keep the copyright! See https://gnunet.org/en/copyright.html for details.

I don't have access to a printer at the moment, so this will have to wait
a little.

> As a rule of thumb, if you want write-access to git.gnunet.org, you must
> sign the copyright agreement (technically what we do is not an
> _assignment_ but _sharing_ of the copyright).

FWIW, the title of ‘copyright.pdf’ is ‘Copyright Assignment Agreement for
Contributors to GNUnet’.

> > 4. Relation to gnunet-guile (not a question).
> > 
> > Some may be wondering why I didn't use the
> > <https://git.savannah.gnu.org/cgit/guix/gnunet.git/> or
> > <https://git.gnunet.org/gnunet-guile2.git> Guile bindings instead of writing
> > my own <https://notabug.org/maximed/scheme-gnunet>;;.  The answer is that:
> > 
> >(1) I didn't write Guile->C bindings, I ported parts of GNUnet from C to
> >Guile
> >(2) A few parts of the Guile bindings are reused in the Guile port
> >(3) there were some crashes with the Guile bindings (things like
> >NULL-pointer exceptions)
> >(4) I couldn't figure out the issue
> >(5) I would like to use GNUnet from within guile-fibers, but didn't 
> > succeed
> >in letting the C event loop cooperate with guile-fibers' scheduling
> >(6) I find Scheme easier to hack on than C.
> 
> I think that's a fine (and maybe generally preferable) approach rather
> than doing bindings. I'd just not do the crypto itself directly in
> Guile, that's likely neither performant nor safe.

Bindings for crypto libraries already exist and appear to work well
and easy to use.  E.g. guile-gcrypt has been succesfully used in Guix
and nettle's C API seems trivial to wrap.  The pure crypto (I'm including
hashing here) will be done by a wrapped C library.

>  The real question is,
> does your work render the bindings obsolete?

At the moment, not yet, because it doesn't support GNS, DHT, FS ...
But eventually, I think it will.

> > For the interested, I have included a copy of the manual.
> 
> Very nice ;-).
> 
> Happy hacking!

Greeting,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: [bug#44199] [PATCH 0/1] An origin method for GNUnet FS URI's

[Maxime Devos]

[CC'd to Timothy Sample because of discussion of defining a new format
for disarchive, and to gnunet-developers because of obvious reasons]

A small status update!

zimoun schreef op di 27-10-2020 om 14:39 [+0100]:
> [...]
> 
> The story about archives as tarball is a bit more complicated.  The
> main
> issue –as I understand it– can be summarized as: Guix knows the URL,
> the
> integrity checksum and only at package time the content of the
> tarball.
> Later in time, it is difficult to lookup because of this very
> address;
> and some are around: nar, swh-id, ipfs, gnunet, etc.
> 
> Bridges to reassemble the content are currently discussed, e.g.,
> 
>
>
> 
> Well, today the fallback of tarball archive to SWH is not reliable.
> 
> 
> What is your question? ;-)

I looked a bit into the GNUnet FS code and disarchive discussions. The
part about tarballs seemed particularily relevant, as well as some
older discussion on preserving the executable bit when using IPFS.

Some issues with using GNUnet's directory format in GNUnet for Guix
substitutes to address:

* directory entries are not placed in any particular order.
  Solution: sort by file-name

* there is no executable bit.
  Solution: define a new metadata property (*).
  This should only take a small patch to libextractor.

  (*) Not sure about the correct terminology

* GNUnet sometimes inlines small files in directories,
  but strictly speaking when to do so is left up to the implementation.
  Solution: pick a fixed reference implementation.

* By default, when publishing, gnunet-publish uses libextractor
  to figure out some meta-data (e.g. title, mime-type, album name),
  which may return different meta-data depending on the implementation.

  Solution: disable the use of libextractor, at least when GNUnet is
  used by Guix.

I'm currently porting the directory creation code of GNUnet to Scheme
(but not any other GNUnet code), to be used by Guix (for publishing
substitutes) and disarchive (for reconstructing GNUnet directories).

After addressing these issues, I believe I will end up with a fairly
well-defined archive format.




signature.asc
Description: This is a digitally signed message part