Hi everyone, I think the discussion so far splits into "should something be done" and "what can be done". The "should something be done" is easier to address, I think, so I'll deal with it first. I particularly have Attila's reply in mind.
> let's put aside the trans aspect of this question for a moment, > is it reasonable for me to demand from somebody else to change their memory > of my past actions? > if so, then where is the line? what's the principle here? and what are its > implications? > i sure see some actors out there who can hardly wait to start erasing certain > records at the barrel of the law I do not doubt that there are bad actors who might misuse the ability to rewrite history generally. However, this only allows us to dismiss the technical challenge if there is *no* legitimate use case for rewriting history, ever, in any circumstance. So rather than removing the trans aspect of the question to consider every possible use case (good or bad) of rewriting history, it seems like we only need to come up with a single case that's sufficient to justify altering someone's identity, for it to be worth considering if the technical restriction could be avoided. But then the answer is obvious: Someone might just sign their commits wrong for whatever reason. Is it valuable for a user or for guix generally to preserve metadata in the case where a commit is signed incorrectly? Obviously not. So whether you are sympathetic to the deadnaming issue or not (personally I am) it seems like we can dismiss the question "should we do something about it". As for what could be done, if I understand the discussion so far (I'm not an expert in guix internals) the only reason we care about identity is that it's part of git commits. If that's really all it is, then I wonder if the following scheme would resolve the issue? * Start with git repo A, signed with an identity now considered incorrect for some reason. * Rewrite history to replace the old signer with the new signer. Make no other changes to the content of any commit. This produces repository A'. * Repository A and A' should have identical numbers of commits, and identical content of the code at each commit. Therefore we can set up a one-to-one mapping from the commits of A to the commits of A'. * Store this mapping of "deprecated commits" (pairs of commit hashes, pointing from the deprecated commit to its corrected version) in a database somewhere, and discard repository A. * Whenever we attempt to look up a commit, if the lookup fails, try to look in the deprecated commits database. Perhaps emit a warning that the commit hash is deprecated and should be updated. Note that point 3 (that the content is identical in each commit) could be violated. e.g. perhaps there is a "CONTRIBUTORS" file which also needs to be scrubbed. This would present an algorithmic difficulty (if we actually tried to verify the code is unchanged) but if a trusted maintainer of the project is authorising the deprecation, then we don't actually need to know that the code is unchanged. Note also that this deprecation mechanism would fix the problem for simple forks too. e.g. in the case referenced, if someone packaged a fork of the deadnamed repo, then looking up a commit that was created pre-fork and included the old identity, then looking up that commit could notify the user that the repo should be updated. Does this sound at all sane? Best wishes, Dan On Mon, Mar 18, 2024 at 11:26 AM Simon Tournier <zimon.touto...@gmail.com> wrote: > > Hi, > > On lun., 18 mars 2024 at 12:10, MSavoritias <em...@msavoritias.me> wrote: > > > The right of a trans person to ask a project to not advertise their > > deadname was never in question. > > > > Guix is a place that supports trans people and anybody else that wants > > to change their name. > > There is a difference between “advertise” and “part of the history”. > > Do not take me wrong. The right to be forgotten is one topic. However, > as many people are saying: it is not an easy question. There is legal > questions, technical questions, social questions, etc. > > For what it is worth, Guix is built around the concept of immutability. > This is a core concept and deep in Guix internals. > > Therefore, it would be more constructive if you come with a > proof-of-concept allowing “history rewrite” and strong “software > identification” property [1]. Else, the discussion is leading nowhere, > IMHO. > > 1: https://guix.gnu.org/en/blog/2024/identifying-software/ > > Cheers, > simon >
