Re: About linked data integrity issues: protecting from updates

>  It would be impractical if a `Like` activity gets invalidated every time
its `object.replies.totalItems` changes

The like shouldn't be 'invalidated' because its referent has a new version.
The like is still 'valid'. It's just clearly a like of an older version of
the resource.

With the hash, every UI has enough information to know that the original
like was not liking the text of the latest version, and can decide not to
imply that the person liked the maliciously updated message. Of course, a
lot of platforms may choose not to mitigate this risk because they think
they might lose users if the like counts aren't as high as possible. This
is one of the tensions that has led platforms to move away from displaying
vanity metrics like like counts.

What's not practical is assuming that just because someone liked an earlier
version of a URI, that it's reasonable to render that they liked all future
versions of that resource, which is unfortunately a common design/UI
paradigm on social web today, but should be corrected. e.g. dont show the
liker's face next to a note, if the like wasn't for that version of the
note. It might still be reasonable to include it in a like count. But
clicking on the like count should probably make clear when the like was for
a representation/version of the object that is not the latest/current one,
otherwise we have the exact attack from the top of this thread. The way to
mitigate it is:
1) on write, add information about the specific representation that was
liked and
2) on render, UIs should use that information to avoid implying someone
liked something they didn't

But there's more nuance when a resource is updated than that the old likes
are 'invalid'. The old like is still valid, but for a representation of
that resource other than the latest version. The attack can't be mitigated
at the protocol/data level alone, only in conjunction with the UI Designers
in a specific context/application.







On Thu, Sep 25, 2025 at 8:54 PM Daiki "tesaguri" Mizukami <
tesaguriguma@gmail.com> wrote:

> On 2025-09-23 14:46, a wrote:
> > if you want to refer to information that you don't want to change,
> > then you should include that information as it was presented at the time.
> I think embedding the whole document (which may be a very long
> `Article`) can be problematic in terms of copyright and privacy.
>
> Using hashes as suggested by Ben sounds more viable in that regard:
>
> On 2025-09-23 19:55, Benjamin Goering wrote:
> > 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>
>
> But still, there is a problem that an object's content (and hence its
> hash) can change without its author explicitly revising it, due to side
> effects. It would be impractical if a `Like` activity gets invalidated
> every time its `object.replies.totalItems` changes. So you probably want
> a mechanism more sophisticated than just hashing the whole document.
>
> I have discussed the same problem on Fediverse Ideas before (still
> unresolved): <https://codeberg.org/fediverse/fediverse-ideas/issues/45>.
>
> --
> Daiki "tesaguri" Mizukami
> <mailto:tesaguriguma@gmail.com>
> OpenPGP primary key: <openpgp4fpr:f706f9bbb8f63cde5f40298fdf5eb02be5c2542e>
> Preferred encryption subkey:
> <openpgp4fpr:070890df2d99c08fd4de0904331a46f78b53c8a5>
> Fediverse: @tesaguri@fedibird.com<https://fedibird.com/@tesaguri>
> Matrix: @tesaguri:matrix.org<https://matrix.to/#/@tesaguri:matrix.org>
> GitHub:<https://github.com/tesaguri>
> Keybase:<https://keybase.io/tesaguri>
>
>