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

[Maxime Devos <maxime.devos@student.kuleuven.be>]

[-- Attachment #1: Type: text/plain, Size: 3024 bytes --]

Hi,

(btw it's Maxim*e*, not Maxim. The ‘e’ isn't pronounced but it's still
written.)

I'll try to address the various issues in separate e-mails.

zimoun schreef op ma 16-11-2020 om 01:35 [+0100
> [snip]
> From my understanding, this is a show stopper.  It has to be solved
first going further, IMHO.  It is not possible to write manually the
URI for all the packages.  And as perhaps you read with the project
’disassemble’, it is not straightforward.

I agree! I see three straightforward answers to this.

a) Fancy

Write a GNUnet service using the DHT to map the hashes used in origin
specifications (*) to URI's for the FS system. To let the local
contribution to the DHT survive peer restarts, maintain a database
(e.g. SQlite) of (Guix hash -> GNUnet hash) (^), that is expanded with
each successful source (or binary) substitution or build.

(Alternatively, as the DHT isn't anonymous,
place hash -> GNUnet hash references into some well-known name space.
Then hash lookup + FS should automatically be anonymous when desired.)

Possible issues: time out behaviour, the DHT is not anonymous.
Annoyance: probably requires extending the build daemon.

Perhaps try regular downloads (e.g. via HTTP/S, ftp, ...) in parallel
with the GNUnet download after a configurable delay?
Perhaps use a well-known GNUnet FS namespace instead of the DHT
for anonymous downloads?

(*) Also usable for package outputs, if the hash of the output is used
and not the hash of the outputs 
(^) In case the database is full, delete some old entries

b) Simple, slow introduction (no additional GNUnet services required)

Extend (origin ...) with an optional gnunet-hash field.
Adjust ‘guix download’, ‘guix refresh’ and ‘guix import’
to emit the gnunet-hash (%) field. Plumb this field to the guix daemon
somehow. Same approach is possible for IPFS.

As packages are updated and new packages are defined, given sufficient
time, there will be more packages with a gnunet-hash field than not.

(%) Computing the gnunet-hash of a directory doesn't require
a full-fledged GNUnet installation. My scheme-gnunet repository
is not very far from the point where it can convert file trees +
libextractor metadata into bytevectors, without depending on C gnunet.

A TODO: different zlib's
would produce different bytevectors --> different GNUnet hash
--> perhaps always use a single version.
A TODO (for nix archives on GNUnet): define
EXTRACTOR_METATYPE_EXECUTABLE (or mimetype: application/x-executable).
Perhaps use mimetype: x-inode/symlink (or something like that) as well?
Repository URL: https://notabug.org/mdevos/scheme-gnunet

c) Not scalable, but may reduce network traffic to ci.guix.gnu.org & co

Like in a) keep a database of known (Guix hash -> GNUnet FS URI).
Perhaps make this available through a web interface or git repository
... wait, this sounds familiar ... this seems to fit well into the
‘disarchive’ project!

Greetings,
Maxime

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 273 bytes --]