How does ActivityPub relate to ActivityStreams exactly?

[aschrijver]

(I started this issue as a comment to w3c/activitystreams#633 yet this is a more appropriate location.)

There are a lot of thoughts, differences of opinion, and Babylonian confusions, in the ActivityPub developer ecosystem, where I wonder they'd be totally avoidable if only the root cause were properly addressed.

As I referred to recently at swicg/general#44 (comment) do we have clear enough domain models and Ubiquitous (attention to) Language on how AS/AP et al supposed to fit together, such that it leads to shared mental picture, common understanding, and avoidance of confusion? I personally think not.

What I think is a 'mistake' or rather oversight in the grassroots standardization efforts of the dev community since ActivityPub W3C standardization in 2018 is the lack of focus on design methodology for interoperable protocol extensions (if "protocol extension" is the right word, see the SWICG issue above).

What is the exact relationship of ActivityPub to ActivityStreams even? How does AP build on top of AS exactly? How do we suppose to use AS types such that we guarantee highest levels of Interopability on the wire? In the past I have at times described ActivityStreams as "a toolbox of social web primitives to design and build social networking use cases". This is not a good description I think today.

Imho a big problem is how everyone in the dev ecosystem treats ActivityStreams as a lego box of social primitives with which you can build anything, model any app. Just cook with your own mix of AS ingredients to create new semantic sauce and expected dining behavior. And drop that recipe on-the-wire in a combinatorial explosion of accidental complexity. If whack-a-mole driven development (WDD) - maintaining app-by-app custom interop against moving release targets - were a game, this constitutes the level-up mechanism.

• How does AP build on top of AS exactly?
• How are ecosystem developers supposed to build with AS exactly?

What is often said is that AS/AP aren't open standards where following the specs to the letter guarantees any level of Interoperability, since there's too much flexibility, things open to interpretation or left out of scope. And I mentioned regularly I consider ActivityPub et al more of a "protocol framework". But even then it is an underspecified framework, with a quite bad DX.

This can be labeled 'Next version' or it might be a W3C Note. There is opportunity to bring more rigour to the AS/AP specs if exact format, semantics and behavior (message exchange) were defined around the social primitive in ActivityStreams. Put a halt to the downward interop spiral of "every combination goes, so code your protocol flavour" path of protocol decacy and ever increasing WDD overhead. The ActivityStreams Vocabulary specification even gives good suggestions already in 5.8 Activity Type Motivating Use Cases.

I should add that the primers are a good start at providing more clarity, but they are more like fragmentary notes now, and do not convey the overarching picture and design philosophy well. Primers for AS/AP are at:

• ActivityPub primer
• ActivityStreams primer

[samsethi]

Hi Arnold

My whole podcast platform called TrueFans.fm is built using the Activitystreams Standard. We created 30 verbs related to podcasting - play, comment, follow, rate, read, share etc. - using the actor, verb, object structure.

e.g Sam (Actor), Played (Verb) Podnews Weekly Review (Object) for 30 minutes, completed 60% and paid §1000 SATs. (Attributes).

Each user has an Activitystream in their profile. Here is mine. https://truefans.fm/fans/sam?tab=activities - see image 1 below.

We also use the activities to enable our gamification model. So if a user plays a podcast we give them XXX pts but if they listen more than 30% they get double points and 60% triple points etc. If they comment on a podcast they get more points. If they share the podcast they get further points. The gamification points helps us identify SuperFans, Create Leaderboards and issue Reward Badges.

We also connect ActivityStreams to ActivityPub. Every user has their activitystream auto published to our ActivityPub Server - https://www.truefans.social - we also let the user decide in their user settings, what verbs are published or if they prefer not to have any activity published.

Here is my TrueFans ActivityPub Profile. https://truefans.social/@sam - this means anyone can follow a TrueFans social profile or podcast and see their activity in their own ActivityPub instance.

Finally we also enable any user to auto publish their content to Threads, X, Linkedin etc - see image 2 below.

Sam's Activitystream

User Settings for Auto-Publishing Activity to numerous Social Web

[aschrijver]

It looks great, thank you. However, there's not really a problem of building anything with AS, but more to what extent is this built as a "every combination goes, so code your protocol flavour" path I mentioned above. To what extent do you now have an interoperable service that others can integrate with? Does that require WDD against your release train? And how you integrated with AP, was that on trial and error basis until things interoperated enough with Mastodon?

[evanp]

Here's my current best definition of the relationship: Activity Streams is a framework and vocabulary for representing people, objects, and activities common to social networks. ActivityPub is an API and federation protocol that defines how to share objects in AS2 format on the Web, and defines side effects for distribution of some of the AS2 object types. It also defines a mechanism for using other types from the vocabulary, or defining your own types in extensions.

I think there are two things we could do here:

• Be more specific about which properties of each activity type we expect to be included.
• Be more clear about how to use ActivityPub as the basis for building an extension social system (geosocial, groups, events, games, ...) that uses the low-level distribution mechanism.

I'm going to mark this as needs discussion and next version.