rewriting history; Was: Concerns/questions around Software Heritage Archive

rewriting history; Was: Concerns/questions around Software Heritage Archive

[Attila Lendvai]

> 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


let's put aside the trans aspect of this question for a moment, because this question has broad implications, much broader than the regrettable struggles of trans people.

the question here is whether person A has the right to demand that others change their memory of A's past actions (i.e. rewrite history, or else become a felon... or maybe just unwelcome in polite society?).

so, let's just assume that i have decided to prefer being called a new name (without disclosing my reasons).

is it reasonable for me to demand from somebody else to change their memory of my past actions? e.g. to demand that they rewrite their memory/instances of my books that i have published under my previous name in the past? or that they forget my old name, and when the change happened? or that they do not link the two names to the same individual?

if so, then where is the line? what's the principle here? and what are its implications?

do i have the right to demand the replacement of a page in each copy that exists out there? i.e. should it be criminal (or just a sin?) to own old copies? do i have the right to demand that certain libraries must sell/burn their copies of my books and never own them again?

what if i committed a fraud? e.g. i pushed a backdoor somewhere... do i have the right to memory-hole my old identity?

and who will enforce such a right? the government? i.e. those people who already keep an (extralegal) record of whenever i farted in the past decade? where can i even file my GDPR request for that? would that really be a "right to be forgotten", or merely a tool of even tighter monopolization of The Central Database?

what if i'm a joker and i demand a new change every week for the rest of my life? do i have the right to the resources of every library out there? to keep their staff and computers busy for the next couple of decades?

but let's put the technical aspects aside; wherever we draw the line... what are the implications of that for borader society? because i sure see some actors out there who can hardly wait to start erasing certain records at the barrel of the law, including rewriting books of significance... (and while we are at it, i suggest to start preserving your offline/local copies, because we're up to a wild ride!)

humanity has reached an enormous challenge with the complete marginalization of the costs of storing and transmitting information. it's a completely new/different playing field, and how we proceed from here has grave implications. this questions is nowhere near as obvious/trivial as presented in the cited blog post.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“It is only when compassion is present that people allow themselves to see the truth. […] Compassion is a kind of healing agent that helps us tolerate the hurt of seeing the truth.”
	— A.H. Almaas (1944–), 'Elements of the Real in Man (Diamond Heart, Book 1)'

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/18/24 02:10, Attila Lendvai 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
>
> let's put aside the trans aspect of this question for a moment, because this question has broad implications, much broader than the regrettable struggles of trans people.
>
> the question here is whether person A has the right to demand that others change their memory of A's past actions (i.e. rewrite history, or else become a felon... or maybe just unwelcome in polite society?).
>
> so, let's just assume that i have decided to prefer being called a new name (without disclosing my reasons).
>
> is it reasonable for me to demand from somebody else to change their memory of my past actions? e.g. to demand that they rewrite their memory/instances of my books that i have published under my previous name in the past? or that they forget my old name, and when the change happened? or that they do not link the two names to the same individual?
>
> if so, then where is the line? what's the principle here? and what are its implications?
>
> do i have the right to demand the replacement of a page in each copy that exists out there? i.e. should it be criminal (or just a sin?) to own old copies? do i have the right to demand that certain libraries must sell/burn their copies of my books and never own them again?
>
> what if i committed a fraud? e.g. i pushed a backdoor somewhere... do i have the right to memory-hole my old identity?
>
> and who will enforce such a right? the government? i.e. those people who already keep an (extralegal) record of whenever i farted in the past decade? where can i even file my GDPR request for that? would that really be a "right to be forgotten", or merely a tool of even tighter monopolization of The Central Database?
>
> what if i'm a joker and i demand a new change every week for the rest of my life? do i have the right to the resources of every library out there? to keep their staff and computers busy for the next couple of decades?
>
> but let's put the technical aspects aside; wherever we draw the line... what are the implications of that for borader society? because i sure see some actors out there who can hardly wait to start erasing certain records at the barrel of the law, including rewriting books of significance... (and while we are at it, i suggest to start preserving your offline/local copies, because we're up to a wild ride!)
>
> humanity has reached an enormous challenge with the complete marginalization of the costs of storing and transmitting information. it's a completely new/different playing field, and how we proceed from here has grave implications. this questions is nowhere near as obvious/trivial as presented in the cited blog post.
>
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.

We don't need "enforcers" here or put the "burden of proof" on people.


MSavoritias

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[pelzflorian (Florian Pelz)]

The guix-daemon does the hashing, so guix-daemon would have to be fixed
to override integrity checks (and it would have to be patched
retroactively in every time-travel).  Noone likes touching guix-daemon
(until it is rewritten in Guile), so I can imagine it would be
frustrating.

Now ftfy is not in Guix, but if Software Heritage deleted the data,
their customers might be equally frustrated.  It is SWH’s obligation to
delete the data, but looking at how rare GDPR action is and how
frequently Icecat’s TPRB add-on lays bare GDPR violations, if they do
not follow the obligation, there likely will not be legal action or the
legal action can be dismissed somehow.

The problem is, such inaction by SWH may be relevant for Guix’ Code of
Conduct, as pointed out by MSavoritias.

Regards,
Florian

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[Simon Tournier]

Hi,

On lun., 18 mars 2024 at 12:10, MSavoritias <email@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

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[Daniel Littlewood]

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.toutoune@gmail.com> wrote:
>
> Hi,
>
> On lun., 18 mars 2024 at 12:10, MSavoritias <email@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
>

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[Andreas Enge]

Hello all,

Am Mon, Mar 18, 2024 at 12:26:18PM +0100 schrieb Simon Tournier:
> Therefore, it would be more constructive if you come with a
> proof-of-concept allowing “history rewrite” and strong “software
> identification” property

the one thing I can think of, and which would allow time travel to coexist
with history rewriting, is an additional layer of metainformation.

First of all, when rewriting history, all commits from the bifurcation
to an alternate universe must be signed again by the person doing the
"time split"; so there is a loss of information there.

Second, we need to create a table that associates every old, lost commit
hash to the corresponding new commit hash; this should also be signed by
the person rewriting history.

Of course this will have to be continued to the future: If Guix has n
commits and m history rewrites, then the m-th rewrite may have to create
a table of n entries that link commit hashes of the m-th rewrite to those
of the (m-1)-th rewrite. Total memory would become m*n entries.

When doing time travel to a commit hash, one would need to check whether
it is available in the current, m-th history rewrite; if not, one would
need to look for it in the (m-1)-th rewrite and map it to a commit hash
in the m-th rewrite; if not, one would have to look for it in the (m-2)-th
rewrite and map it to a hash in the (m-1)-th rewrite, and then check
whether or not it has been overwritten in the m-th rewrite. The total
time complexity would be m look-ups in tables of size n each.


It is a lot of effort; and probably for little gain, since we cannot
eradicate each and every fork of the Guix git repo. The old data will
still be available at SWH, and probably at random forks on lots of random
forges all over the world. As Simon, I think that history, fundamentally,
cannot be rewritten: What has happened in the past, has happened in the
past. If you have done some public activity as the person known as X, and
then change your name to Y, you cannot prevent your past activity to be
known under identity X. Also, the time split would have to be publicly
documented somehow; if we add as rationale for a history rewrite "person X
is now known as Y", not much is gained compared to just keeping the old
commits. Not documenting the rationales for history rewrites would not help
to instill trust in the codebase, and probably not solve the problem either,
since it is quite likely that the request by person X to now be addressed
as Y will have been made on the mailing list or some other public forum.

So my impression is that the .mailmap approach in the Guix project is a
good compromise between acknowledging the wish of people to be known under
identity Y, and what can reasonably be achieved to hide identity X.

Well, there are things people can do individually:
1) Use a pseudonym P from the start instead of X (which is admitted in
   the Guix community, just look at a few of the names: there are pseudo-
   nyms with clearly made-up first and last names, there are very obvious
   one-word pseudonyms, and maybe some of the names that look like real
   names are not from the persons' passports, who would know).
2) This does not help, of course, if you are already known as X and want
   to be known as Y. Then either you can somehow make the change publicly,
   and transfer your reputation and also the information that you used
   to be known as X, or disappear as X and reappear as a new person Y
   and lose X's reputation. Doing both is impossible, I would say.

Andreas

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/18/24 15:35, Andreas Enge wrote:

> Hello all,
>
> Am Mon, Mar 18, 2024 at 12:26:18PM +0100 schrieb Simon Tournier:
>> Therefore, it would be more constructive if you come with a
>> proof-of-concept allowing “history rewrite” and strong “software
>> identification” property
> the one thing I can think of, and which would allow time travel to coexist
> with history rewriting, is an additional layer of metainformation.
>
> First of all, when rewriting history, all commits from the bifurcation
> to an alternate universe must be signed again by the person doing the
> "time split"; so there is a loss of information there.
>
> Second, we need to create a table that associates every old, lost commit
> hash to the corresponding new commit hash; this should also be signed by
> the person rewriting history.
>
> Of course this will have to be continued to the future: If Guix has n
> commits and m history rewrites, then the m-th rewrite may have to create
> a table of n entries that link commit hashes of the m-th rewrite to those
> of the (m-1)-th rewrite. Total memory would become m*n entries.
>
> When doing time travel to a commit hash, one would need to check whether
> it is available in the current, m-th history rewrite; if not, one would
> need to look for it in the (m-1)-th rewrite and map it to a commit hash
> in the m-th rewrite; if not, one would have to look for it in the (m-2)-th
> rewrite and map it to a hash in the (m-1)-th rewrite, and then check
> whether or not it has been overwritten in the m-th rewrite. The total
> time complexity would be m look-ups in tables of size n each.
>
>
> It is a lot of effort; and probably for little gain, since we cannot
> eradicate each and every fork of the Guix git repo. The old data will
> still be available at SWH, and probably at random forks on lots of random
> forges all over the world. As Simon, I think that history, fundamentally,
> cannot be rewritten: What has happened in the past, has happened in the
> past. If you have done some public activity as the person known as X, and
> then change your name to Y, you cannot prevent your past activity to be
> known under identity X. Also, the time split would have to be publicly
> documented somehow; if we add as rationale for a history rewrite "person X
> is now known as Y", not much is gained compared to just keeping the old
> commits. Not documenting the rationales for history rewrites would not help
> to instill trust in the codebase, and probably not solve the problem either,
> since it is quite likely that the request by person X to now be addressed
> as Y will have been made on the mailing list or some other public forum.
>
> So my impression is that the .mailmap approach in the Guix project is a
> good compromise between acknowledging the wish of people to be known under
> identity Y, and what can reasonably be achieved to hide identity X.
>
> Well, there are things people can do individually:
> 1) Use a pseudonym P from the start instead of X (which is admitted in
>     the Guix community, just look at a few of the names: there are pseudo-
>     nyms with clearly made-up first and last names, there are very obvious
>     one-word pseudonyms, and maybe some of the names that look like real
>     names are not from the persons' passports, who would know).
> 2) This does not help, of course, if you are already known as X and want
>     to be known as Y. Then either you can somehow make the change publicly,
>     and transfer your reputation and also the information that you used
>     to be known as X, or disappear as X and reappear as a new person Y
>     and lose X's reputation. Doing both is impossible, I would say.
>
> Andreas
>
Rewriting history is the wrong question imo. I dont think a request to 
change all of the history of Guix will be accepted anyway.

A much easier thing to do is to change the approach in the future. And 
let all the past history untouched.


MSavoritias

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[Andreas Enge]

Am Mon, Mar 18, 2024 at 04:03:20PM +0200 schrieb MSavoritias:
> Rewriting history is the wrong question imo. I dont think a request to
> change all of the history of Guix will be accepted anyway.
> A much easier thing to do is to change the approach in the future. And let
> all the past history untouched.

I was well thinking about the future history as well as the past one...
Everything we do now becomes unmutable history in the future; so the
question how we can rewrite an a priori unmutable history remains the same,
regardless of the date when person X wants to be known as person Y: Also in
the future, someone may wish to travel to a time before the change.
And the fundamental problem of history rewriting remains; I do not see
how we could simplify it. So I do not think that it is "a much easier
thing to do". Please feel free to prove me wrong by making a concrete
suggestion!

Am Mon, Mar 18, 2024 at 04:00:38PM +0200 schrieb MSavoritias:
> On 3/18/24 15:12, Simon Tournier wrote:
> > Again, this is an incorrect frame, IMHO.  Software Heritage (SWH) do the
> > things you granted them to do.  SWH respects the “ethical” definition of
> > “free software”.
> You are bringing the legal argument again. The argument that you can do what
> you want with Free Software is based around a licence which is a legal
> construct of states.

I think there is a misunderstanding here, rooted in the use of "you" in
"you can do what you want". We need to be clear about whom we are speaking.
There is SWH, and what they can do is a result of the free license. The
other question is what we as the Guix community want to do (and can do);
I would suggest to concentrate in our discussion on the latter, which is
where we have agency.

Andreas

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/18/24 16:19, Andreas Enge wrote:

> Am Mon, Mar 18, 2024 at 04:03:20PM +0200 schrieb MSavoritias:
>> Rewriting history is the wrong question imo. I dont think a request to
>> change all of the history of Guix will be accepted anyway.
>> A much easier thing to do is to change the approach in the future. And let
>> all the past history untouched.
> I was well thinking about the future history as well as the past one...
> Everything we do now becomes unmutable history in the future; so the
> question how we can rewrite an a priori unmutable history remains the same,
> regardless of the date when person X wants to be known as person Y: Also in
> the future, someone may wish to travel to a time before the change.
> And the fundamental problem of history rewriting remains; I do not see
> how we could simplify it. So I do not think that it is "a much easier
> thing to do". Please feel free to prove me wrong by making a concrete
> suggestion!

Actually gitlab already is facing something like that and they are doing 
what was proposed elsewhere: mapping of UUIDs to display names

https://gitlab.com/gitlab-org/gitlab/-/issues/20960


So no reason we couldn't do something like this.

>
> Am Mon, Mar 18, 2024 at 04:00:38PM +0200 schrieb MSavoritias:
>> On 3/18/24 15:12, Simon Tournier wrote:
>>> Again, this is an incorrect frame, IMHO.  Software Heritage (SWH) do the
>>> things you granted them to do.  SWH respects the “ethical” definition of
>>> “free software”.
>> You are bringing the legal argument again. The argument that you can do what
>> you want with Free Software is based around a licence which is a legal
>> construct of states.
> I think there is a misunderstanding here, rooted in the use of "you" in
> "you can do what you want". We need to be clear about whom we are speaking.
> There is SWH, and what they can do is a result of the free license. The
> other question is what we as the Guix community want to do (and can do);
> I would suggest to concentrate in our discussion on the latter, which is
> where we have agency.
>
> Andreas

Right fair. As I have said before SWH does break Guix CoC effectively 
right now.

So what Guix does from this point on will effectively dictate if the CoC 
is valid or not.


MSavoritias

>

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[Andreas Enge]

Am Mon, Mar 18, 2024 at 04:33:49PM +0200 schrieb MSavoritias:
> Actually gitlab already is facing something like that and they are doing
> what was proposed elsewhere: mapping of UUIDs to display names
> https://gitlab.com/gitlab-org/gitlab/-/issues/20960

Interesting, thanks! It is something that maybe could be implemented by
Savannah, but it would probably require a bit of thought. And yet again,
somehow the mapping uuid<->"real" names would have to be public (people
would "git clone" commits with uuids, and would need to locally replace
them by "real" names); so people can always keep copies of the mapping
over time.

I am also not quite sure about the signing process for committers;
in principle keys are enough, but in GPG they are tied to email addresses,
and I do not know whether we use this in Guix.

In the end, my impression is this will not achieve much more than what we
already have with the .mailmap approach. In a sense, everyone would use
a pseudonym (their uuid), and then we would keep a mapping between these
pseudonyms and, well, "real" names or other pseudonyms chosen by the
contributors...

Hm, this could indeed be implemented exactly with .mailmap, no?
We would need to enforce that authors use a uuid of a specific format,
and potentially an empty or dummy email address, or another uuid.
Then we could keep a .mailmap file. The history of "real" identities
would still be visible in the git history, but as said above, anyway
we could not prevent people from storing the association information
over time.

> Right fair. As I have said before SWH does break Guix CoC effectively right
> now.
> So what Guix does from this point on will effectively dictate if the CoC is
> valid or not.

Well, the CoC is valid on our communication channels; so what SWH does with
our software is outside its scope (that is governed by the license).

Andreas

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/18/24 17:14, Andreas Enge wrote:

> Am Mon, Mar 18, 2024 at 04:33:49PM +0200 schrieb MSavoritias:
>> Actually gitlab already is facing something like that and they are doing
>> what was proposed elsewhere: mapping of UUIDs to display names
>> https://gitlab.com/gitlab-org/gitlab/-/issues/20960
> Interesting, thanks! It is something that maybe could be implemented by
> Savannah, but it would probably require a bit of thought. And yet again,
> somehow the mapping uuid<->"real" names would have to be public (people
> would "git clone" commits with uuids, and would need to locally replace
> them by "real" names); so people can always keep copies of the mapping
> over time.
Sure. But we can only say about Guix not everything else.
> I am also not quite sure about the signing process for committers;
> in principle keys are enough, but in GPG they are tied to email addresses,
> and I do not know whether we use this in Guix.
I hope we don't because i use ssh to sign commits personally :D
>
> In the end, my impression is this will not achieve much more than what we
> already have with the .mailmap approach. In a sense, everyone would use
> a pseudonym (their uuid), and then we would keep a mapping between these
> pseudonyms and, well, "real" names or other pseudonyms chosen by the
> contributors...
>
> Hm, this could indeed be implemented exactly with .mailmap, no?
> We would need to enforce that authors use a uuid of a specific format,
> and potentially an empty or dummy email address, or another uuid.
> Then we could keep a .mailmap file. The history of "real" identities
> would still be visible in the git history, but as said above, anyway
> we could not prevent people from storing the association information
> over time.

Nicknames may change tho. UUIDs are not in any way meaningful to humans 
so i doubt we would need to change them.

I have changed nicknames once for example.

>> Right fair. As I have said before SWH does break Guix CoC effectively right
>> now.
>> So what Guix does from this point on will effectively dictate if the CoC is
>> valid or not.
> Well, the CoC is valid on our communication channels; so what SWH does with
> our software is outside its scope (that is governed by the license).
>
> Andreas


My question was more like:


In the next Guix Days or any Guix conference, do we allow SWH to 
participate if this matter is still unresolved?

Because we would be basically inviting people that don't respect the CoC.


MSavoritias

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[Tomas Volf]

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

On 2024-03-18 12:08:48 +0000, Daniel Littlewood wrote:
> 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".

I do not think the situation is as black and white as you put it here.  I
believe the question of "should something be done" needs to be further split
into two sub-branches.  "should something be doable effective from some point in
time" and "should something be doable retro-actively".

For the former, I think most people here would agree that yes, and there already
is a mechanism for that (.mailmap).

For the latter, I do not think you can just "dismiss" it.  While I agree with
you there is a little value in the act of Guix preserving wrong metadata by
itself, any history-modifying operation would have quiet large impact on the
ecosystem, so that needs to be taken into account as well.  And it that light I
would say yes, preserving wrong metadata (when viewed from this angle) does have
a value.

And I say this as a contributor perfectly matching your example of "signed their
commits wrong", which is why you will find me in the .mailmap.

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[Attila Lendvai]

> not an expert in guix internals) the only reason we care about
> identity is that it's part of git commits.


identities are deeply intertwined with trust (our best predictor of future behavior is past behavior). and how trust is facilitated by the tools and processes (including the social "technology") can make or break any group effort.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The direct use of physical force is so poor a solution to the problem of limited resources that it is commonly employed only by small children and great nations.”
	— David D. Friedman (1945–), 'The Machinery of Freedom' (1973)

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[indieterminacy]

On 2024-03-18 15:14, Andreas Enge wrote:
> Am Mon, Mar 18, 2024 at 04:33:49PM +0200 schrieb MSavoritias:
>> Actually gitlab already is facing something like that and they are 
>> doing
>> what was proposed elsewhere: mapping of UUIDs to display names
>> https://gitlab.com/gitlab-org/gitlab/-/issues/20960
> 
> Interesting, thanks! It is something that maybe could be implemented by
> Savannah, but it would probably require a bit of thought. And yet 
> again,
> somehow the mapping uuid<->"real" names would have to be public (people
> would "git clone" commits with uuids, and would need to locally replace
> them by "real" names); so people can always keep copies of the mapping
> over time.
> 
> I am also not quite sure about the signing process for committers;
> in principle keys are enough, but in GPG they are tied to email 
> addresses,
> and I do not know whether we use this in Guix.
> 
> In the end, my impression is this will not achieve much more than what 
> we
> already have with the .mailmap approach. In a sense, everyone would use
> a pseudonym (their uuid), and then we would keep a mapping between 
> these
> pseudonyms and, well, "real" names or other pseudonyms chosen by the
> contributors...
> 
> Hm, this could indeed be implemented exactly with .mailmap, no?
> We would need to enforce that authors use a uuid of a specific format,
> and potentially an empty or dummy email address, or another uuid.
> Then we could keep a .mailmap file. The history of "real" identities
> would still be visible in the git history, but as said above, anyway
> we could not prevent people from storing the association information
> over time.
> 
>> Right fair. As I have said before SWH does break Guix CoC effectively 
>> right
>> now.
>> So what Guix does from this point on will effectively dictate if the 
>> CoC is
>> valid or not.
> 
> Well, the CoC is valid on our communication channels; so what SWH does 
> with
> our software is outside its scope (that is governed by the license).
> 
> Andreas

I have happened to stumble across a new initiative concerning UUIDs for 
academic researchers.

Here is their description:
```
ORCID, which stands for Open Researcher and Contributor ID, is a free, 
unique, persistent identifier (PID) for individuals to use as they 
engage in research, scholarship, and innovation activities. We provide 
ORCID to researchers free of charge so that we may realize our vision of 
connecting all who participate in research, scholarship, and innovation 
are uniquely identified and connected to their contributions across 
disciplines, borders, and time.
```

Here are its guiding principles:
```
Our Founding Principles

     ORCID will work to support the creation of a permanent, clear, and 
unambiguous record of research and scholarly communication by enabling 
reliable attribution of authors and contributors.
     ORCID will transcend discipline, geographic, national, and 
institutional boundaries.
     Participation in ORCID is open to any organization that has an 
interest in research and scholarly communications.
     Access to ORCID services will be based on transparent and 
non-discriminatory terms posted on the ORCID website.
     Researchers will be able to create, edit, and maintain an ORCID 
identifier and record free of charge.
     Researchers will control the defined privacy settings of their own 
ORCID record data.
     All data contributed to ORCID by researchers or claimed by them will 
be available in standard formats for free download (subject to the 
researchers’ own privacy settings) that are updated once a year and 
released under a CC0 waiver.
     All software developed by ORCID will be publicly released under an 
Open Source Software license approved by the Open Source Initiative. For 
the software it adopts, ORCID will prefer Open Source.
     ORCID identifiers and record data (subject to privacy settings) will 
be made available via a combination of no-charge and for-a-fee APIs and 
services. Any fees will be set to ensure the sustainability of ORCID as 
a not-for-profit, charitable organization focused on the long-term 
persistence of the ORCID system.
     ORCID will be governed by representatives from a broad cross-section 
of stakeholders, the majority of whom are not-for-profit, and will 
strive for maximal transparency by publicly posting summaries of all 
Board meetings and annual financial reports.
```

While I do not have the focus to make a further evaluation,
I should point out that ORCID is a component of the nascent Open Science 
Network
https://openscience.network/

FWIW, recognising an academic in OSN and being aware of the quality of 
the tooling Bonfire Networks make me wonder whether ORCID has some good 
design principles
https://bonfirenetworks.org/

In any case, it may provide a practical point for comparison given the 
thicket of governance issues this thread has discovered.


Warmest regards,


fsnjfkjlffffjcjcjcdnmddfnfdfnlzxvcllnjnrejvns  v fjfdsjhsv