Finally figured out why I hadn’t had much luck with edited posts on Micro.blog making their way to Mastodon. Mastodon requires an “updated” date, not just “published”. Fine, but these are the little things that make interoperability in the fediverse essentially trial and error.
@manton Does this mean updates might automatically percolate out to Masto? That would be helpful for me—I seem to be incapable of posting without typoes.
@oddevan HTTP signatures are one of the least-specific parts. I'm sure you've seen it, but Mastodon's own security docs are a good starting place.
@manton 🥳 Horray! Thanks for fixing that. I’m curious, will that work for only posts going forward, or prior ones too?
@jarrod Just for posts going forward. There might be a way to trigger it for older posts that were updated. Will have to think about that.
@manton but out of a purely semantic perspective, why wouldn't you add the updated date if you executed an update?
@mariusor I think adding the updated date makes sense. I'm still surprised it didn't accept it, but I get the reasoning. My point is that none of this is in any spec (although it is documented for Mastodon).
@manton What's not in the spec? This is the Activity Vocabulary annotation for the "updated" Object property[1]:
> updated
> URI: https://www.w3.org/ns/activitystreams#updated
> Notes: The date and time at which the object was updated
What more does it need to be said ?
[1] https://www.w3.org/TR/activitystreams-vocabulary/#dfn-updated
@manton I realize maybe I pigeon holed on the wrong thing you were saying. Did you mean the spec should say that updated is mandatory?
If so, then I'm afraid that's a Mastodon quirk, regular ActivityPub servers should most likely accept Objects without it. :D (At least mine do)
@mariusor There are dozens of properties in ActivityStreams, most of which are rarely used in a real server. This is more about the definition for the "Update" activity, e.g. something like "to send an edited posts to followers, servers should use the Update type and include an updated date field". The spec example for "Update" only includes a URL, not even a full post object.
@mariusor Yep, that's what I was trying to say. I agree it does seem like a Mastodon quirk to me too. I'm just complaining that there are a lot of quirks across the fediverse. 🙂 Although I'm confident that things will smooth over as there are more test suites, updated docs, etc.
@mariusor @manton Well, one thing the spec doesn't say is that "updated" is intended to be a machine-readable field that's useful for "most recent wins" conflict resolution.
On my first read through, I thought "published" and "updated" were meant to be displayed to users, like you'd see on a news article. That is, referring to when the piece of writing was published or updated, as opposed to the ActivityPub object which represents it.
@YurkshireLad Sort of. The spec is not really defined in enough detail to build everything. There are a few little things that Mastodon filled in between what is explicitly documented.
@mariusor Well, a journalist might write an article on April 12th, then find out on April 14th that there's a mistake that warrants a revision. Now we've got an article which was published on the 12th and updated on the 14th.
Then on the 16th they spot a trivial typo which they want to fix, but doesn't need to be announced loudly. The user-visible updated date is still the 14th, but the #ActivityPub object has to have a more recent timestamp, or the edit may not propagate.
@mariusor @manton Or similarly, they might write an article on the 12th that doesn't get posted to the #Fediverse until the 15th. Now the user-visible publication date and the #ActivityPub "published" property have different values.
@YurkshireLad @manton @mariusor @FenTiger
What does "follow it exactly" in this context mean? #ActivityPub has a flexible extension mechanism. That mechanism is sort of outlined, but not well enough. Ideally extensions are well-defined, consistent, have specs & docs for formats and behavior that's easily found, have a process for standardization to encourage further reuse and contributions/maturity. Are discoverable in registries, compliance profiles, etc.
Without all that, we have "quirks".
@manton actually, I think this is a fault in mastodon. The AP spec is almost entirely SHOULDs, so I can't really say that it's not implemented correctly in this case. But, the specified behavior is to update the local cache of remote objects, as they are presented in the Update activity.
