From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id CFyYFyY9z2H74AAAgWs5BA (envelope-from ) for ; Fri, 31 Dec 2021 18:25:58 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id oKMuECY9z2H9XwAAG6o9tA (envelope-from ) for ; Fri, 31 Dec 2021 18:25:58 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D1F01AD92 for ; Fri, 31 Dec 2021 18:25:57 +0100 (CET) Received: from localhost ([::1]:59122 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3LfB-0000p6-1P for larch@yhetil.org; Fri, 31 Dec 2021 12:25:57 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54612) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3LeJ-0000kR-KX for guix-devel@gnu.org; Fri, 31 Dec 2021 12:25:03 -0500 Received: from [2a00:1450:4864:20::42d] (port=41871 helo=mail-wr1-x42d.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n3LeH-0003KZ-Ks for guix-devel@gnu.org; Fri, 31 Dec 2021 12:25:03 -0500 Received: by mail-wr1-x42d.google.com with SMTP id a9so56864426wrr.8 for ; Fri, 31 Dec 2021 09:25:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=b4R2PPWcV2EJiivvEduy31kMGgY/7Hprjrqe6TUlDAs=; b=BUQivXUs44l7OL9+v+tWP4QVMuB0xikNUIuenflcY3jyVvGP9qp0+LTJ3zwGAbxHzW UBY+b4MPHgJQfGl+ztPNPqSPEUv1FGhYN9Rd1f+WPjnikdkOItAVjoRxTI2UdiViCp2n PvNO1zcZ83JwfxJXucVybswPWjiv5NKsAaJ6KI33kiTn8MOhd5LciL99P2JwtbuHEQ5a ODSMJg4j9Uf71DkjHM3iT2pxkC360B0B+y4M3hb0ygHAybCy4JSFBWnntH5ddnQTjwg/ rDeNDJphODJ9uMVge7GVCrYxtyuvmzhBtdZBM35MRgmgOKEnXNVhjv81SDTpZbaXUv6v po9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=b4R2PPWcV2EJiivvEduy31kMGgY/7Hprjrqe6TUlDAs=; b=4kfV4N255QyR/4Nn1KVeWNhGoMe81DuLhoSqAvWoPt+1RXqg8mvMhCeO7h2j89uP7I g5mrt2lhIjmiBKMXaNWdxvaZ1Rf90tzbmcU5T3JNffF3WOq09aXLbi4zXLPbGAGl6S+n nZIMzY5vUs0I/3J7aGfMXPdtMmEm6zTZuUgK1FdvmGRIvHJfrGt4hp6+0ynTf71D4HxY CT2ppp0REgPcVaeCV4qKUwufAZQrbSrToRpLmuYRAqd1Rn4xYOFPfhxZYgCZwBuLHfbx FlliVPBUylkUAQQrFTCMaROXDGTFhlXdCcWnPU+JYszn3jXXGC0HfHpp4wgB5ugMM31x 6vRA== X-Gm-Message-State: AOAM532uGahbd/GxUj37hLpbklotQY8DrKgmu37/sF2q7E9FJ1BHZc23 AaRpZSww4gBspqGXiDK2JiLESJ3pHBbrww== X-Google-Smtp-Source: ABdhPJxpk2xK6yyI3KvajisbVz3/0evTJyc0uyMUUvoRYS8wWu/TNhRdOk6/+u1Lv7M6qnhqg8TBGw== X-Received: by 2002:a05:6000:1141:: with SMTP id d1mr30848481wrx.2.1640971500009; Fri, 31 Dec 2021 09:25:00 -0800 (PST) Received: from lili (2a01cb04061b8800e2568b9190e03e61.ipv6.abo.wanadoo.fr. [2a01:cb04:61b:8800:e256:8b91:90e0:3e61]) by smtp.gmail.com with ESMTPSA id v1sm31615776wru.45.2021.12.31.09.24.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Dec 2021 09:24:59 -0800 (PST) From: zimoun To: Liliana Marie Prikler , Ricardo Wurmus Subject: Re: On raw strings in commit field In-Reply-To: References: <6e451a878b749d4afb6eede9b476e5faabb0d609.camel@gmail.com> <86y243kdoo.fsf@gmail.com> <899587fb6a76ddfa37d197d3d0fd23cdc7ad8592.camel@gmail.com> <867dbmi7pf.fsf@gmail.com> <3d448fe42f0c43574db96fa26aecd7da5fd5a95d.camel@gmail.com> <86k0flpnx5.fsf@gmail.com> <9a5e3e7f44155146d731dd5a97450a9ff9dff5ab.camel@gmail.com> <87bl0xglul.fsf@elephly.net> <86ilv46hls.fsf@gmail.com> Date: Fri, 31 Dec 2021 18:21:19 +0100 Message-ID: <86bl0w667k.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::42d (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::42d; envelope-from=zimon.toutoune@gmail.com; helo=mail-wr1-x42d.google.com X-Spam_score_int: 6 X-Spam_score: 0.6 X-Spam_bar: / X-Spam_report: (0.6 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1640971557; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=b4R2PPWcV2EJiivvEduy31kMGgY/7Hprjrqe6TUlDAs=; b=nVO8XtZMy9GflvQ7wx0DYgyxiRcXSV7tPto7ThoPiyky+BkGEBv4SUKDt1j8NI+7XFzCEI Qjj8MQnFwxjNxFTejtLjAqfMf7AjcXn+0Vxzj6Bs9G6mzTASV8gl8SPFaiiKjvsVsTmX+e E+ZnZJgCdS8EGR2MwVFYP8bCSEFdSUvIL9WP0orQ3IY3sgMBz7yPiLwm3nCVZ1+UIi2hI3 UFelD9AXLlrNn9Fzyn6ORaf5T3huk4V3TeJD2/NFF5dOYekeank/p2r5CR/p9iuimlxAPI CaFoQkwYOYzQMW+MzSg+dKX9r5OxVebVcg4rvYsKG5xEBycHL2J61HB5sRsuGA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1640971557; a=rsa-sha256; cv=none; b=FTDPKBKH84UQJu53dVW5uuORUSFrv14Yb1fKPhrl2xz2BujGjEbOHYqmmHofDD/ubOvbXh NTCBlfi4GguMXVSEjqPrCK9lBqnUYQn7qkTFFgvHZQ41FfLCclm9nrVgDc+s+yYCcH9b6m bYZp4S2lpLG9xZ7dnuQ4b3JULad82QOa7jyTH2YhN9KydG3e6rshXKSVI9LPKWoXU1Q/bv IeoKHzy7eTHCCHMeEJpeFfSeRpJnT3TzwMGgO70y5lhT2zEeqxl9oq+adr1TaYRUzNYAjq X9JdKwRYaRo614L45rBSdbN4TK4thwgj1wd51zb5928EHI4BWJ4arQw/5LMC7g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BUQivXUs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -6.08 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BUQivXUs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: D1F01AD92 X-Spam-Score: -6.08 X-Migadu-Scanner: scn0.migadu.com X-TUID: m5E0a8qOjAqL Hi, On Fri, 31 Dec 2021 at 16:19, Liliana Marie Prikler wrote: > You're also missing the part in which it currently relies on a single > server to do all this, but there are plans to move it out to multiple > ones, i.e. adding fallbacks/redundancy to your fallback mechanism, > which for the record is a good idea to have. I do not see why you guess I am missing a part. Anyway. Redundancy adds one kind of robustness: resilience. Obviously it helps. For sure, I want that too because it is the straightforward, an =E2=80=9Cea= sy=E2=80=9C and =E2=80=9Cquick=E2=80=9D way to have robustness. However this assumes a= ll the redundant nodes of the web of nets will be still up, at least enough to have this=E2=80=A6 robustness. Me too, I hope Guix will be popular and all redundancies still running when I will be old or dead. But I will not bet on that assumption. What Timothy is doing with Preservation of Guix and a window of ~2years shows that any web of nets is really fragile. I do not see why the one we are building around Guix will be different. Instead of trying to have robustness by adding more and more, from my point of view, it appears to me the occasion to rethink and try to have robustness with less. I agree with you that various fallbacks is one good direction to go. SWH is one thing because it is currently well supported (by UNESCO for instance). But many others are also worth. Maybe IPFS or GNUnet are worth. >> It is a difficult topic to know what information the =E2=80=99uri=E2=80= =99 field >> should contain for robust long-term; a topic with a lot of unknowns, >> although many solutions are around, they are a strong change of >> habits and changing my own habits is already hard, so a collective >> change is a big collective challenge. :-) > > We're going back to Cantor's argument for raw commits. I'm not opposed > to using commits as value of the commit field (let-bound commits > reflected in the version, that is), but let's not forget that this > robustness argument still presupposes that the (commit tag) binding is > the point of failure. This probably holds to some degree for "npm- > something", but we also have a fair amount of e.g. GNOME-related > packages which we trust to have robust tags and the only reason we > don't use mirror://gnome to refer to them is because it's not in GNOME > mirrors (yet).=20 Because this point of failure for tag potentially exists, the counter-measure would be to add more (check integrity, fallback to other servers, etc.) and even it could be impossible if the tag changed and propagated to all. I am not saying neither that we have to replace tomorrow all the tags by commit hashes. My point is just that this tag in the =E2=80=99uri=E2=80=99= field does not appears to me a correct design. For sure, I agree it is convenient but I think it is not The Right Thing. Sadly, I do not know what The Right Thing is =E2=80=93 and commit hash is probably not The Right Thing bu= t it seems to me a direction to explore. >> For instance, SWH promotes swhid instead of DOI for referencing the >> publications.=C2=A0 I am not sure it is really popular outside a small >> French subgroup. ;-) > > Completely off-topic, but=C2=A0isn't part of the point of DOIs that you c= an > fetch the revised paper as well? I can understand putting OpenData > behind an SWH ID rather than a DOI, but the paper itself? Why? If you find it off-topic, fine. My point is to say that DOI (extrinsic) is not known to not be The Right Thing for referencing and intrinsic identifier is really better but it seems hard to convince people to switch. For instance, DOI is known to be fragile because it relies on an external centralized mutable index to have the bijection between the identifier and the content. If today I cite doi:123abc then tomorrow when you reach this very same identifier doi:123abc, then you have no guarantee that it is the same content. Obviously, it is not an issue by itself, but in scientific context where fraud is something, once the centralized mutable index is corrupted, done! Because SWH-ID only depends on the content itself, it allows decentralization and integrity check. Do not take me wrong, I am not comparing Git SHA-1 hash with an integrity check. :-) Well, maybe the interested reader can give a look at: All in all, I was trying to point that this extrinsic vs intrinsic thing is bigger than =E2=80=99git-fetch=E2=80=99 and commit hash vs tag and the r= oot appears to me in exploring what the =E2=80=99uri=E2=80=99 field should contain. Th= is DOI was an example to show the topic is not easy. >> Somehow, find some rationale =E2=80=93readability, matching versions, et= c.=E2=80=93 >> and then find counter-measures of their flaws to keep extrinsic >> values =E2=80=93tag, revision, etc.=E2=80=93 is, for what my opinion is = worth, not >> the correct level or frame when thinking about robustness and long- >> term. > > For what it's worth, I don't think content addressing everything > (particularly relying on a single service to do so) is robust in the > long term, it just introduces larger failure points. The only robust > way of increasing robustness is to add more fallbacks and redundancies > (and actually use them). We disagree; especially on =E2=80=9Conly robust way=E2=80=9D and =E2=80=9Ca= dd more=E2=80=9D. And from my side, now I exposed all, I guess. ;-) Cheers, simon