Christian Grothoff transcribed 13K bytes:
> Hi Olie,
>
> On 6/12/19 9:01 PM, Olie Ayre wrote:
[...]
> > ### 9: What sorts of applications might I write for GNUnet
> > considering what systems already exist?
>
> Whatever you're qualified to do and feel like. It's Free Software ;-).
>
> > If I want to write an application that uses GNUnet to
> > communicate with other users or access things like software
> > repositories for checking for updates and the like, what would
> > be the approach to this?
>
> The GNU Guix folks are interested in this, and did a bit of preliminary
> work on this. But to make this really work nicely, we'll have to finish
> the Transport Next Generation (TNG) work, and fix some fundamental
> design issues in file-sharing (for performance).
I'm no longer (that much/at all) involved, but recent developments drifted towards IPFS
and IPFS having a good feedback in the guix community, at least those who voiced
their opinion publicly about it.
They seem to maintain a protocol independent approach, but I don't
think this is happening anytime soon.
Code exists, and amz3 worked on an update of it this year (gnunet-guile2),
There is a very tiny bulletin board kind of application that rely on the functions used
to implement the cli gnunet-download, gnunet-search and gnunet-publish.
I don't remember correctly why I gave up. I think it is related to the event loop
that I could not make it work the way I wanted using guile-fibers. And I could
not wrap my head around IPC.
and I do have a collection of notes with regards to this (guix in particular).
I have since then moved on to form my own thoughts and ideas about distributed package management.
To me, the architecture for this is not clear at all. Some say that a trusted source
should publish a mapping between GUIX packages and gnunet hash using GNS.
Some (like me) would prefer to have the gnunet hash part of the package definition.
For what it is worth, I looked at IPFS but was not happy either.
I tried to implement some kind of Question-Answer social network on top of
Based on that work, I have written a specification document describing the interface
This is missing large file transfer.
Basically:
get / set procedures are equivalent to gnunet-download and gnunet-publish
without keyword support and it only support files smaller than 1Mb.
bag are wanna-be equivalent to gnunet-search. They allow anyone to publish
the identifier of a file stored using the above procedure called set.
namespace stuff mimic the GNS procedures in gnunet.
Unlike gnunet, this is done without security or anonymity in mind. Also the undocumented
procedure in the specification:
- ref-at
- bag-search-at
- namespace-ref-at
Allow to bypass the default DHT lookup algorithm to fetch the data from a known peer
in a FOAF kind of network. It is meant to be used by the application when the other
procedures fail. Here is an example use in the tests:
Good luck!