In the W3C Social Web Working Group, we recommended the Activity Pub and Activity Streams groups to adopt linked data standards. While they adopted some, others were not considered. The benefits of this selective approach are still uncertain.
To address this, I suggest the following modifications to Activity Streams / Activity Pub:
Implement versioning in the context, similar to other systems. Currently, AS has a single, mutable context. This context has evolved over time with the inclusion of more terms, including protected ones. However, the version remains unchanged. I propose we introduce versioning, which would likely be a minor adjustment.
Make the AS vocabulary both human and machine-readable. Currently, it’s primarily human-readable, which hampers linked data compatibility, validation, and extensibility. This can be rectified by mapping the existing AS vocabulary to the appropriate URL indicated by the context. The solution could be as straightforward as relocating a file or incorporating data from one file to another on the W3C server.
Elevate both JSON and JSON-LD to be first-class in Activity Pub. This can be achieved by adding a @vocab term set to urn:json:, thus permitting any new JSON term to be recognized as linked data without the necessity of drafting an FEP. Once a term is established, it can be developed into an FEP. Until then, it can remain “plain old JSON”, which aligns with the majority of the web today. This would also allow existing JSON APIs on the web to be treated as linked data. This is another one-line adjustment.
With these three alterations, we could significantly improve the standards compliance of AP/AS. Although they seem minor, they might justify a major version upgrade. We must remember that version 1.x doesn’t strictly adhere to the linked data standard, and it might choose to continue on this path, which is entirely acceptable.
I think any standard work for the Fediverse needs to start with the question: How can I make it testable? The Activity* documents are fine if one interprets them more as guidelines than strict standards. One needs a pretty radical frame shift from how they are written to arrive at something testable and thus enforceable.
Second, ActivityStreams does not have the Client/Server separation of ActivityPub. It will be necessary to introduce it, in order to handle Client side signing/encryption. As far as I know, all current signing is done server side.
Hey, Melvin. I think you have a mistaken idea of the state of AS2 and AP.
They are at final state, published, and implemented in dozens of software projects.
Any modifications would require upgrades across the network. They might break the network. They will take hundreds if not thousands of person-hours to implement.
There is not a chartered group to revise the specs, so any new versions would be in competition with the official, final version.
As a rule of thumb, anything you want to do on the Fediverse should be implemented in its own namespace as an extension.
there are already versioned comtexts available as activitystreams-history (they’re just not advertised well)
I have a question for you, Melvin. For people who want to experiment with Linked Data standards, is it possible to use Activity Streams 2.0 objects with Solid?
We would like to try, but there are some inconsistencies. Perhaps they would be “paper cuts” or road blocks. It’s definitely something people want to try, and implementation will yield what the answers to that are.
Solid is quite high standards compliance, except for the html part, which is not specified (sort-of strangely). AP/AS are close to it.
I think it’s a great exercise and I know its something that people want!
This could be good. Are the versions of the context URIs?
There used to be a test suite. We needed it to become a REC. Maybe we could start it up again.
Yes I’m aware. But it was several years ago. There’s enough water under the bridge to innovate based on what we’ve learnt, or to fix common issues.
Awesome, thanks! Out of curiosity, how did you find this?
i forgor i think it was a github issue somewhere…
Main sticking point here is the social graph aspect. If you remember during the SWWG a robust social graph was one of the use cases. But we never finished it.
Solid had a working demo of the social graph at the time, where you could browse from profile to profile. But it needs to be profiles from all the different networks.
A social graph is the basis of interoperability with solid, though there can be some short cuts, generally what you would need is one canonical identifier for each system, that is distinct from the document ie of type Person.
From that formation of AS objects, sending to inbox, and processing is not the hardest thing. But it’s built on the foundation of the graph which provides the discovery and routing.
Certainly, it appears that, for the foreseeable future, our main focus at the W3C will be on addressing existing bugs and errata. We might also consider the promotion of certain Notes or Reports, such as those stemming from FEPs, into our Community Group work items through an established process.
The points in my original post could well get fixed during the errata process. The context versioning system was a good find.
Although a new W3C Recommendation or charter is not currently within scope and could take years to develop, preliminary groundwork could be initiated in areas like Codeberg, Mastodon, or other sectors within the free software community.
Such efforts could potentially lay the foundation for enhancing the specification, or even pave the way for a future W3C charter – although it is recognized the latter as a considerable undertaking.
Given the open-source nature of much of the Fediverse today, that seems to be where most new work is happening.
This comment from @nightpool suggests that there is limited appetite in mastodon to be part of the semantic web, right now.
I think this is a missed opportunity as a standards based approach offers semantic interoperability, extensibility and scalability. But without mastodon the network effect will be be reduced, in any case
So, I guess it’s a difference in understanding of what a “robust” social graph would be. Every ActivityPub actor has a
following collection and a
followers collection, enabling a directed social graph between actors.
I think there are a few things I’d hope for to make that graph more robust, like:
- providing information about the nature of the relationship
- representing bidirectional relationships
- having random access to relationship data – for example, to find whether A follows B, you have to scroll through A’s
following collection, which may have hundreds or thousands of pages.
I think it would be interesting to create extensions to explore this functionality.
@eprodrom all good ideas, I think
Edit: in more detail
- different relationship types e.g. friends - good!
- robust could mean that user from network A could follow user from network B (including but not limited to AP)
- the use case in SWWG was called browsing the friendship graph, a browsable graph of users like in facebook would tell in story, maybe it can be done in some instances today
- by having a graph as infrastructure many new apps and use cases could reuse the base infrastructure
There’s a lot in there, so perhaps more food for thought for the next version. It will be interesting to see how Meta build out there new offering.