pukkamustard schreef op wo 02-02-2022 om 09:56 [+0000]: > Maxime Devos writes: > > > [[PGP Signed Part:Undecided]] > > pukkamustard schreef op di 25-01-2022 om 19:21 [+0000]: > > > I will be looking into the HTTP fallback and also using BitTorrent and GNUNet > > > as transports. > > > > I have been writing a (Guile) Scheme port of GNUnet's client libraries > > (https://git.gnunet.org/gnunet-scheme.git/). Currently only NSE is > > supported, but I'm working on DHT. DHT search/put already works to a > > degree (see examples/web.scm), but there are plenty of sharp edges > > (see TODOs about disconnecting, reconnecting and stopping fibers, > > and see guix.scm for Guile bugs that are patched out and extra guile- > > fibers features). > > Very interesting! I have been following your work on that a bit. > > From what I understand gnunet-scheme interacts with the GNUNet services > and sends messages to the various GNUNet services. Is that correct? Yes, it works like the C GNUnet client libraries, except it's in Guile Scheme and a few different design decisions were made, e.g. w.r.t. concurrency. > Have you considered implementing the GNUNet protocols themeselves in > Guile? I.e. instead of connecting with the GNUNet services and sending > messages, implement R5N completely in Guile. I didn't, at least not _yet_. As-is, things are already complicated enough and the client code seems a lot simpler than the service code. Though perhaps in the future ... E.g., for testing the DHT service, the test code effectively creates a tiny, limited, in-memory DHT service (not communicating to any peers) that's buggy in some respects (not yet committed, but will be in tests/distributed-hash-table.scm). > IMHO this would be very nice as one could use GNUNet protocols completely > in Guile and not rely on the GNUNet C code. While it's not a priority, I'm not opposed to someday implementing the services in Guile and testing whether they can communicate with C peers. However, keep in mind that GNUnet is supposed to be able to eventually replace the TCP/IP stack, and running the DHT, NSE, NAT, FS, CADET, TRANSPORT ... services in every web browser, in every mail client, in all "guix substitute" and "guix perform-download" processes, etc. is rather wasteful (memory-wise and CPU-wise), so I'd prefer this not to be the _default_ option. (I'm not sure if you were referring to that.) Greetings, Maxme.