Hi, On sam., 16 mars 2024 at 08:52, Ian Eure <i...@retrospec.tv> wrote:
> I was also distressed to see how poorly they treated a developer > who wished to update their name: > https://cohost.org/arborelia/post/4968198-the-software-heritag > https://cohost.org/arborelia/post/5052044-the-software-heritag This asks two questions, IMHO. 1. Can the future you decide who were the past you? 2. What is Content-addressed system? About #1, that’s somehow a philosophical question. :-) That’s what the question about changing the public identity asks: you can act on who you are and who you want to be but because the time is not reversal, sadly, you cannot change who you were. It is not possible to collectively rewrite the history. Allowing such process leads to dangerous consequences, IMHO. That’s another story. :-) Do not take me wrong. That’s still an open question and the right to be forgotten is a topic by itself, e.g., legal. We will not address it in the Guix project. About #2, that’s a technical question. By definition of a Content-Addressed system, the key associated to the value is computed by a procedure depending only on the content itself. Therefore, change the content then change the key. Git [1] is probably the tool that have popularized that. Consider a project using Git and you clone it. Now, you have a complete copy of many keys associated to many contents, and also many links between the keys themselves. For instance, the key of the object ’Git commit’ depends on its content which depends on the key of the object ’Git tree’. Now, if you rewrite any content, then it rewrites the key. As pointed, this change might propagate. All the question becomes the authority. Because I also have another copy/clone with the initial set of keys and you have now modified ones, how do we agree what are the right ones? Well, at the size [2] of linked posts, the Git history rewriting is affordable. Now, I am not convinced that the person would try – or even think of – such if this project would have hundreds of contributors and thousands of users. That’s my opinion and I agree it is not an argument. :-) At the level of Guix, allowing a mutable history implies a random availability of binary substitutes. To be explicit, rewrite the Git history of Guix implies the break of: + local Git repositories of Guix developers + regular Guix users and the trust mechanism Somehow, a Content-Addressed system is designed around immutable content. And if one know how to implement a Content-Addressed system relying on mutable content, I would be very interested to know more about it. Cheers, simon 1: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects 2: https://github.com/rspeer/python-ftfy/graphs/contributors