Content-Addressed system and history?

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi,

On sam., 16 mars 2024 at 08:52, Ian Eure <ian@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