- From: Benjamin Goering <ben@bengo.co>
- Date: Tue, 23 Sep 2025 03:55:50 -0700
- To: Cristiano Longo <cristianolongo@opendatahacklab.org>
- Cc: Social Web Incubator Community Group <public-swicg@w3.org>
- Message-ID: <CAN+OhBPA0CbhOwOBBDuooinWSJeebxNQZmQUMvxGsOc4WF0XXQ@mail.gmail.com>
tl;dr keep calm and add some hashes. append a hashlink <https://datatracker.ietf.org/doc/html/draft-sporny-hashlink> or ni <https://www.rfc-editor.org/rfc/rfc6920> To mitigate this, you can record not only the location of the liked object, but a cryptographic commitment <https://en.wikipedia.org/wiki/Commitment_scheme> to the specific representation of the object that was liked. consider using something https://github.com/w3c-ccg/hashlink (nice because you can tack them onto existing https URLs). did-core defines the hashlink hl parameter as available on all DIDs. https://www.w3.org/TR/did-1.0/#did-parameters or, if you dont mind linking to another uri scheme, and/or want to use an IETF RFC, you might also consider https://www.rfc-editor.org/rfc/rfc6920 The subset of the ActivityPub interactions that do this end up in a hash DAG https://en.wikipedia.org/wiki/Hash_chain You can also just start using the cryptographic commitment / hash as the ActivityPub Object ID itself, and treat the activity's original 'id' value (should it depend on a specific https host, for example) as a secondary locator for it (the URL will eventually break anyway, either by going offline permanent, MITM, or any other network partition) ActivityPub was always a https://en.wikipedia.org/wiki/Content-addressable_network This is very similar to how FEPs are named based on the hash of their title. That's because that scheme was suggested by AP Editor Christine, who also heavily evangelized this kind of content addressing on the fediverse 5+ years ago in https://gitlab.com/spritely/golem/blob/master/README.org Like most of the things above, it uses SHA2-256 as the commitment scheme. That writeup uses magnet: URIs with urn:sha256 URIs, which have been around for like 15+ years in p2p systems, and imho are a good choice too. and more recently <https://dustycloud.org/blog/how-decentralized-is-bluesky/> (from Christine): > indeed I intentionally fought for and left open the possibility within > ActivityPub of adding content-addressed posts, and several years ago I wrote > a demo <https://gitlab.com/spritely/golem/blob/master/README.org> of how > to combine content addressing with ActivityPub. But nonetheless, even > though such a thing is spec-compatible with ActivityPub, *content-addressing > is not done today on ActivityPub*, and *is* done on Bluesky. Christine's 99% right. While Mastodon and the companies that seek to interop only with it do not do content addressing, small pockets of ActivityPub networks do perform content addressing and have for years. For example, pukkamustard presented an implementation of ActivityPub that used content addressing at ActivityPub Conf 2019 in Prague. https://conf.tube/w/gWVYjsGbCLXJ5XAaDpSJRD how it does content addressing https://inqlab.net/projects/eris/ zooming back out.... keep calm and add some hashes. append hashlink <https://datatracker.ietf.org/doc/html/draft-sporny-hashlink> or ni <https://www.rfc-editor.org/rfc/rfc6920> or magnet links On Mon, Sep 22, 2025 at 10:12 PM Cristiano Longo < cristianolongo@opendatahacklab.org> wrote: > Hi all, > > let us consider the following scenario: there is a Notes object with the > content "I hate Hitler". Now I can distribute a Like activity referring > to this object, as I hate Hitler too. But, few moments later, the author > update the text to "I love Hitler". Then there is a Like object having > me as actor and targeting a Note object in favour of Hitler. > > The same could apply also to other scenarios, for example accepting to > buy something that changes. Of course, it could apply also in a most > generic web scenario, for example when we agree to some privacy policy > or code of conduct. > > I wonder if someone else faced this issue in some way. > > Any contribution is welcome, > > CL > > > >
Received on Tuesday, 23 September 2025 10:56:07 UTC