The new link can be found at: https://forgefed.org/spec/#previousversions
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).
Software > ForgeFed by @fr33domlover describes the application domain of Code Forge software.
- 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
previousVersionsin the spec you find they have totally different meaning in the context of the forge. - The JSON-LD example has
as:Noteas 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.