Re: "ActivityPub at one glance" diagram

> anybody who just wants to learn about the ActivityPub standards [...]  rather than limit what it says to what the W3C standardized [...]

I don't think it should be "just" or "limit" to anything. I am making
a very simple claim: A website ostensibly named after a spec shouldn't
ignore that spec entirely, or what that spec defines.

> when people talk about ActivityPub, they might mean two distinct concepts

I would hope I've been very clear about the split that you mention,
and I am saying that the website should have both. It doesn't make
much sense to talk only about what to do with activities while
completely leaving out how you got them in the first place.

> I believe activitypub.rocks needs to speak far more to the "ActivityPub stack”-interested audience [...] and that’s what we need a diagram for

If you mean to solicit a diagram for the Fediverse, you would probably
do better by focusing on the various activity types and vocabulary
rather than how an HTTP request is made.

> clearly identify which parts are the ActivityPub standard, and which other parts are not, all the better

ActivityPub is the diagram we've been discussing throughout this
thread, for which you can fill in "rest of the world" like so:

actor --> POST --> outbox --> POST --> inbox <-- GET <-- actor
actor --> POST --> outbox <-- GET <-- actor

The parts that are "not" would slot in behind each actor:

[do something] <-- actor --> [activitypub] <-- actor --> [do something]

For the fediverse, "[activitypub]" would be roughly extended by things
like WebFinger and HTTP Signatures... depending on which software and
which version you are talking about. If you're tracking "supported
Mastodon versions" and that's your target for interoperation, then you
have slightly different requirements for "the latest Pleroma version",
"Misskey 2025.10", and so on... and your requirements drift even
further if you start to consider things like Lemmy, and even further
for something like Funkwhale, and so on.

I would highly encourage not limiting one's view of "ActivityPub" to
"ActivityPub as it is used by Mastodon", even if Mastodon has a lot of
users and has historically driven a lot of interest in ActivityPub.
There is probably extant ActivityPub usage that is not strictly
compatible with Mastodon, that is not very well-known within
Mastodon-adjacent circles, that should be acknowledged. For example,
dokieli can POST activities to your outbox when you perform certain
actions, and this enables a lot of things that are much richer than
just microblogging. The activities it generates would not be
understood by Mastodon, but only because Mastodon places further
restrictions beyond just ActivityPub... and Mastodon doesn't care much
for activities in the first place, as it unwraps them to get at the
side effects, mostly centered around Note objects.

For what ActivityPub defines, it basically boils down to the following:

- "Follow" activities and the "followers" collection
-- "Accept"("Follow") and the "following" collection
- "Like" activities and the "likes" collection
-- (optionally, your own "liked" collection)
- "Announce" activities and the "shares" collection
- "Undo" for the above activities

Beyond that, it is relatively unconstrained, and further constraints
are typically applied by each software. In the "not" diagram above,
the "[do something]" is also up to the software listening to whatever
gets received in the inbox. But to quote myself from earlier in this
email thread:

> It is a monumental task to map out what those
> requirements are for different softwares and different versions

...which likewise extends to what those *behaviors* are for different
softwares and different versions. The same activity might be within
requirements for two different softwares and/or versions, but trigger
different behaviors depending on their understanding and context
(which is typically hardcoded into the software application and frozen
at certain versions).

Received on Wednesday, 24 December 2025 05:06:48 UTC