From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: gnunet-guile reboot & guix Date: Sat, 13 Jan 2018 11:14:53 +0000 Message-ID: <20180113111453.huczs6g7k4yrulmy@abyayala> References: <20180113004949.svmgkjbgrhydn3jg@abyayala> <415a3580fb65ec46e76fc97674767bfd@hypermove.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6651431606021761902==" Return-path: In-Reply-To: <415a3580fb65ec46e76fc97674767bfd@hypermove.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gnunet-developers-bounces+gnu-gnunet-developers=m.gmane.org@gnu.org Sender: "GNUnet-developers" To: Amirouche Boubekki Cc: Guix Devel , Gnunet Developers List-Id: guix-devel.gnu.org --===============6651431606021761902== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3didxgaeqo6zcfqc" Content-Disposition: inline --3didxgaeqo6zcfqc Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Amirouche Boubekki transcribed 6.3K bytes: > On 2018-01-13 01:49, ng0 wrote: > > Amirouche Boubekki transcribed 1.5K bytes: > > > H=C3=A9llo all, > > >=20 > > > I restarted from scratch the gnunet-guile bindings. It was made > > > much easier thanks to the work of ng0 on gnunet documentation and > > > guile-bytestructures to handle C structs and unions. >=20 > ... >=20 > > > I think I need to know what's the plan/design for gnunet/guix > > > integration to continue. > >=20 > > If you want a (relative) unprocessed summary of its history, it's > > collected in here > > (org-mode recommended): > > https://gnunet.org/git/infotropique-artwork.git/tree/doc/guix-past-note= s.txt >=20 > Here is an extract relevant to the current discussion: >=20 > * Design of guix/gnunet integration >=20 > > > So I can see two milestones now, as we discussed before: >=20 > > > 1. Create a variant of =E2=80=98guix publish=E2=80=99 that publishes = over GNUnet=E2=80=99s > > > file sharing (FS) service, using the neat bindings that you wrote. >=20 > > > For that you can literally copy guix/scripts/publish.scm as a > > > starting point, and simply remove the HTTP-related code (which is a > > > small fraction.) The rest will be mostly identical: narinfo > > > meta-data generation, signing. I guess it will be easy to test it > > > using gnunet-search and similar tools. >=20 > > > As a 2nd step, we=E2=80=99ll see how we can refactor things to allow = code > > > sharing between the existing =E2=80=98guix publish=E2=80=99 and its G= NUnet variant. >=20 > > > 2. Create a variant of =E2=80=98guix substitute=E2=80=99 for searches= through GNUnet. > > > Again, a large part of the code is about narinfo and signature > > > checking, and it can be reused. >=20 > > > I=E2=80=99m not completely clear on how search for substitutes will w= ork, > > > though. Currently, when the user wants to build /gnu/store/xyz, =E2= =80=98guix > > > substitute=E2=80=99 simply fetches http://hydra.gnu.org/xyz.narinfo. = How will > > > that work with GNUnet? Are we going to look up their /gnu/store file > > > name? >=20 >=20 > > > I=E2=80=99m not completely clear on how search for substitutes will w= ork, > > > though. Currently, when the user wants to build /gnu/store/xyz, =E2= =80=98guix > > > substitute=E2=80=99 simply fetches http://hydra.gnu.org/xyz.narinfo. = How will > > > that work with GNUnet? Are we going to look up their /gnu/store file > > > name? >=20 > > I=E2=80=99ve considered a solution for that: GNUnet allows one to create > > specific namespace and publish files under this namespace. Unlike > > publishing under the =E2=80=9Cglobal namespace=E2=80=9D where keywords = are used to > > identify a file, when publishing under a specific namespace files are > > identified with a choosen identifier. Moreover, as a namespace is > > basically a cryptographic key pair, and publishing a file under your > > namespace means signing, one=E2=80=99s assured nobody else will publish= under > > her or his namespace. By the way, the private key associated with a > > namespace is named =E2=80=9Cego=E2=80=9D or =E2=80=9Cpseudonym=E2=80=9D. >=20 > > It=E2=80=99s easy to test this feature: >=20 > > # create a `test` ego/namespace > > $ gnunet-identity -C test >=20 > > # list the known egos in the form: `name - public key` > > $ gnunet-identity -d > > test - M2OC987U9LFJHQ8LC9SLCV4Q0ONHJV7FMTFQ2VRPE0M9R9MK5860 > > =E2=80=A6 >=20 > > # index the file `foo.txt` under the `test` namespace > > $ gnunet-publish -P test -t foobarbaz foo.txt >=20 > > # find the file `foo.txt` > > $ gnunet-search gnunet://fs/sks/M2OC987U9LFJHQ8LC9SLCV4=E2=80=A6/foobar= baz > > #0: > > gnunet-download -o "foo.txt" gnunet://fs/chk/PL217ODD8EDSMOIQ3UT0=E2=80= =A6 >=20 > > Now if Alice wants to publish her binaries, she creates an > > ego/namespace and publishes everything under it; Bob adds her > > namespace=E2=80=99s public key to his authorized substitutes list, and = when > > installing `/gnu/store/xyz` the substitute will search for > > `gnunet://fs/sks//xyz`. >=20 > > Instead of publishing an archive we might also directly publish/index > > the build, but I don=E2=80=99t know if it=E2=80=99s viable. >=20 > > Does it seem right to you? >=20 > * Another discusion about guix integration >=20 > > > Instead of using =E2=80=98file-system-tree=E2=80=99, this variant sho= uld probably use > > > =E2=80=98live-paths=E2=80=99 from (guix store), which returns the lis= t of live store > > > items. >=20 > > Well, `file-system-tree` is only used to recursively index a random > > directory=E2=80=99s content (in our case, a single store item). It look= ed viable > > for publishing a single store item, but won=E2=80=99t be good for index= ing at > > once the entire set of live paths; I should ask the GNUnet team how to > > properly index such a huge amount of directories. >=20 > > On my machine, running `live-paths` takes ~2 seconds, but the > > publication of the entire store will probably take much longer anyway. >=20 > > > BTW, I noticed there=E2=80=99s quite a bunch of global variables that= are > > > =E2=80=98set!=E2=80=99. It would be better to avoid that, but I supp= ose the > > > continuation-passing style that the GNUnet libraries impose makes it > > > difficult. >=20 > > Hopefully, using the =E2=80=9Cclosure=E2=80=9D parameters of the GNUnet= API in the > > bindings should reduce the need for global variables, and improve > > elegance of end-user programs. >=20 >=20 > > > > Nitpick: it=E2=80=99s a bit annoying that we have to specify a GNUn= et > > > > configuration file. > > >=20 > > > Yes, GNUnet programs usually look for `~/.config/gnunet.conf`, and > > > `publish-gnunet` does the same. Now, maybe `publish-gnunet` could > > > somehow obtain the config file used by `gnunet-arm`? >=20 > > No, it would need the config file to figure out how to talk to > > gnunet-service-arm (or any other service). And we do support running > > many instances of peers on the same host, which really means the config > > is the only way to find out. >=20 > The rest of ng0 reply: >=20 > >=20 > > On various occasions it was made clear to me that FS isn't ready for > > such > > usage and we would need to extend it if we start working on it. I could > > be > > wrong, but to some degree our implementation of our own designs has some > > mistakes, if I remember Grothoff right. > >=20 > > Bits and pieces without what I came up with in winter 2016: > >=20 > > * anonymous levels aren't necessary for sharing code > > ** update on this: one (or more?) other OS' is looking into Guix+GNUnet > > as well and I'm not sure if they would rely on anonymity. Imo it > > makes > > no sense for the start. anonymity setting 0 would work for a start. >=20 > Anonymity is easily configurable. Sure. > > Before I share my part of the ideas, maybe someone who wasn't involved > > in the on-and-off discussions could add their ideas? Fresh ideas could > > bring new perspectives we haven't seen. > >=20 > >=20 > > For the Guix part I just know that it should be an option, not a > > default. > >=20 >=20 > Oh really? I don't see that appear in the discussion with Remi. The copied file was a collection of work not only of Remi. There's 2 or 3 threads at least. The idea that GNUnet FS distribution should be an option, not a default for Guix is my understanding of how more recent discussions (on IRC and the mailinglist, possibly even AFK chats I had with some of the other developers). My personal idea is to make it a standard in my redistribution of GuixSD, but primarily we want to work on what Guix wants, not what a distro framework in development close to GNUnet wants, for now. Of course I wouldn't complain if Guix would pick GNUnet as default, but we'd need a good amount of testing before we'd make it so. --=20 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys WWW: https://n0.is/a/ :: https://ea.n0.is --3didxgaeqo6zcfqc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEqIyK3RKYKNfqwC5S4i+bv+40hYgFAlpZ6i0ACgkQ4i+bv+40 hYh7mA//efmRjEWch+vdmYylC5QnpLiaNJuTtXgrbfQGbYdFC1Bm1XJ3FkOnNyFa 7IifwOgu7PvOlYW40HiJF3t//MSaX/BVvp23OOBTmJM3t7iXfzRd9phZ/oSRnR+h XbG0wbfPUo/bWVVJY/FKzCEURNWyzsrN4BzU83M4gtjfAfdHmla5o2iOTvxEI6cO zRXtCW+XMUttJ4mXcaqi0u+QwiyM9qrf2+pL/u9wgnOl8Qxn0aDKiKLceU11hgeO MyL17/sjxLqOS/1GK+mOryijIntvuttkcJr6zbB5sSEJxtJAJ3z85JObjoQAPxNc y4OKeHmxgmZA86W6wleoZ/tVXYO2q48XlYplqMrA5pDn9bk9UWDUIKH4ZEZE4HYi o6UNNXYaff0oiHhHXiUHaMCsxFWRW9Iwc3h6o7/4bv2S2TvKqEu3ts9hnOKR2cfR Ybk7JnEAgxiSIy5TuBzo+tkOpV/bLKnkSEdqT3X1GaWbhHiV7YUC3Lo88FCFn4L5 oOdUGd5SnnkR1VOgUaudGzOMwSaaVoT60LkRIyE/N759nH3E7plXEFQR1GxU0V2B gvO2oUWjiMtUMjmB4j34s6yGxpjCdkQnrrhQg2z0pbpWs8MEqvcKR1Ct2LptZ3st +Sdt+a1FsZ7gJgzsvhD5M5DYLoreCf6xSuUH+JgzOkOOlKVKpIQ= =SNid -----END PGP SIGNATURE----- --3didxgaeqo6zcfqc-- --===============6651431606021761902== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers --===============6651431606021761902==--