@julian This is exactly my point 1 from here: https://socialhub.activitypub.rocks/t/desired-changes-for-a-future-revision-of-activitypub-and-activitystreams/4534/10

My opinion is that this should actually be the standardised behaviour.

Tbf it feels like Mastodon could assume that the update is the latest one if there is no updated field and only use the updated fields to not apply an update, if the updated field is before the last update. Does that make sense?

@sortekanin@socialhub.activitypub.rocks Yes and no, I can see how that would be logical, but there could potentially be issues if subsequent updates were delivered out of order (due to a variety of reasons one can dream up).

In that scenario you wouldn't want to assume that the undated updated is the latest.

This whole thing could actually be sidestepped if we sent timestamps with our activities, but that's not in the spec, so I guess nobody does it heh.

julian:

This whole thing could actually be sidestepped if we sent timestamps with our activities, but that's not in the spec, so I guess nobody does it heh.

Sounds like another suggestion that could be useful in the wiki post hehe

@julian @SorteKanin

published property can exist on activities too. Some implementation already does this but I don't remember which one

@julian said in `Update(Note)` quirk:

This whole thing could actually be sidestepped if we sent timestamps with our activities, but that's not in the spec, so I guess nobody does it heh.

Not sure what you mean here? Any Mastodon (or misskey or...) Create(Note) has a published property on the Create activity with a timestamp and a published property on the Note object with a timestamp.

@dariusk must just not have noticed

To be fair I have this cool software I'm working on that helps me answer that question immediately

julian:

This whole thing could actually be sidestepped if we sent timestamps with our activities, but that's not in the spec, so I guess nobody does it heh.

This sounds like a wonderful FEP!

thisismissem:

This sounds like a wonderful FEP!

This article published two weeks ago mentions the issue (highlight mine) ..

Another example I personally encountered was a frustrating issue while implementing ActivityPub for this blog: updating a post propagated to Lemmy but not Mastodon. Despite the Update activity being accepted, Mastodon silently rejected it unless the updated timestamp changed—a logical but unofficial requirement. Developers must track down subtle implementation details that aren't formally documented, significantly complicating adoption and usage.

I'd write it off as a Mastodon-ism, but it's actually better to have that property present, so now it is.

So one that's becoming de-facto standard. Ideally if Mastodon introduces such logic, it is up to them to remember to inform the broader developer community via a FEP.

---

Aside: "If all we have is a Note .. "

Overall it is such a pity that everything is to be a Note or else.. And the default pragmatic urge of most devs is to assign app-specific business logic to an existing or custom property within it, to create all the behavioral flavors. And then call it a day "my app works" and throw the protocol decay out in the ecosystem.

There are other improvements regarding revision control as long-time open issues, see e.g. @trwnh's https://socialhub.activitypub.rocks/t/exposing-edit-history-via-activitystreams/2930 (mastodon issue # dd. January 2023). In this issue @stevebate suggests previousversions from the ForgeFed Vocabulary.

What do we do when we "Edit a Note"? Is using the CRUD of ActivityStreams really the best option, or are we really "Creating a Revision". Shouldn't ActivityPub have a proper way to Revision Control across the board?

If my new Fediverse app included both editable and non-editable posts, how I'd hack that in on top of the current mechanism? Just pondering this. It seems we go out of our way not to use the extension mechanism of ActivityPub as it was intended to be used, cramming everything in NoteCrud​. Is that official best-practice for the future fediverse now, I wonder.

Many more examples seen in discussions. The ActivityPub specs state that you may ditch JSON-LD for plain JSON, but doesn't say that the whole idea of a semantic type model should be thrown out of the window as well. In https://socialhub.activitypub.rocks/t/distinguish-between-posts-and-direct-messages/2283 the example is people going out of their way not to define ChatMessage in favor of Note + property-logic.