@Johann150 raises a feature request for being able to view earlier versions of an activity or object before an Update was received. In the case where an object is Created and then Updated, someone receiving the Update who didn’t receive the Create first would have no way of knowing what was contained in the original version. Someone fetching the object without having received either of the activities would be able to know that it was edited based on the presence of the updated property, but likewise would not be able to retrieve any additional information about previous versions.
Looking at the existing Activity Vocabulary we see that the only existing way to do this would be in the case that context was published, although this requires that the context MUST be a Collection, and you would have to dig through all the items to filter for Update activities (plus the initial Create). Additional issues arise from the ordering of Collections not always being consistent, but in general you will still have to traverse the entire context collection.
Therefore it likely makes sense to propose a new property called something like history or revisions. If there is any prior art or some existing specifications that could apply here, it would be helpful to know about them.
I just quoted you in relation to a Mastodon quirk around editing, and included an aside on the “everything is a Note” practice. I want to add the general observation (not to you, as you are aware and advocate of the semantic linked data fedi) that this suggestion is also in the category of protocol hacks (for the sake of pragmatics, I well understand).
It makes no sense if every app in Microblogging business domain makes reference to the Code Forge application domain protocol extension namespace if they need revision control.
If you read the 12 occurrences of previousVersions in the spec you find they have totally different meaning in the context of the forge.
The JSON-LD example has as:Note as its type, but it really refers to a “comment” on a patch or ticket. Revision control in ForgeFed represents a common denominator of what’s found in common (preferably FOSS) forges. And might be maturing in a direction that makes it unsuitable for the general case.
Need: Standard Revision Control mechanism for ActivityPub Objects
The whole idea of linked data is that we’d build first using common open-standard vocabularies. Use them lego bricks to compose intricate domain models.
Instead of:
Use forge federation property to hack revision control in mastodon, and let post-facto interop trickle this down in on-the-wire current reality.
We might have:
Revision Control for ActivityPub Objects (bounded context under domain-driven design)
ForgeFed delegates to (maybe expands with forge-specifics) standard AP Revision Control.
Mastodon implements (preferably as-is) standard AP Revision Control.
One challenge is that the Update behavior in ActivityPub has serious issues and I believe it’s flawed from a Linked Data graph-oriented perspective. (I’ve discussed these issues in other threads.) I think that would behavior need to be fixed before it makes sense to discuss how to represent revision histories, although they are clearly related topics.
I see two meta issues. My impression is that some of the most influential people working towards revising the spec don’t have a very deep understanding of Linked Data (and, therefore, JSON-LD). Given the relatively unconstrained semantics of pure JSON data, thinking primarily in those terms prevents them from seeing the Linked Data issues. The second meta issue is the (very reasonable) resistance to “fixing” the spec if it results in backwards incompatibility. That means we’re stuck with at least some of the broken parts. To be fair, it would be very difficult to untangle the current mess.
I agree. Imho an ActivityPub v2.0 track should be started. New major version meaning breaking changes can be made. This v2.0 should be the re-evaluation of v1.0 and the resulting ecosystem installed base. Then taking lessons-learned and realign the protocol to the original broad-scope social networking objectives. For any implementer, like Mastodon, the choice to stick with v1.0 and maintain its on-the-wire reality, or follow the commons-based ecosystem that moved on.