Re: "ActivityPub at one glance" diagram

I’d like to point out that when people talk about ActivityPub, they might mean two distinct concepts:

1. A particular technology standard defined in a particular document from the W3C, possibly including all dependencies.

2. The “ActivityPub stack”, a stack of technology standards and non-official conventions that make today’s Fediverse possible. This includes ActivityPub, the W3C standard, but also HTTP Signatures, Webfinger, and a long list of best practices, e.g. to make sure one’s implementation interoperates with Mastodon.

When I hear people say “ActivityPub", in my personal experience, it feels like they mean “ActivityPub stack” about 90%+ of the time, and the particular standards document almost never. (Except among standards insiders, such as this group here, but that’s hardly the audience for publicly facing websites.)

And when they want to learn about ActivityPub, so far I have yet to encounter anybody who just wants to learn about the ActivityPub standards document. Instead, they want to know “how do I interoperate with what’s out there already” using the ActivityPub stack.

Based on that, I believe activitypub.rocks needs to speak far more to the "ActivityPub stack”-interested audience, rather than limit what it says to what the W3C standardized, and that’s what we need a diagram for. (If that can, without overloading the graphics, clearly identify which parts are the ActivityPub standard, and which other parts are not, all the better.)

Happy Holidays :-)



Johannes.


> On Dec 23, 2025, at 17:11, a <a@trwnh.com> wrote:
> 
> On Tue, Dec 23, 2025 at 6:28 PM Darius Kazemi <darius.kazemi@gmail.com> wrote:
>> 
>> I did misunderstand "post to outboxes" as "post to inboxes" so my "bypassing federation" comment was indeed not really meaningful.
> 
> "POST to inbox" doesn't "bypass federation" either unless you have a
> problem with me using curl and think the only valid POST requests
> should come from a fedi instance's delivery worker. The distinction
> doesn't really make sense to me.
> 
>> I do think that when developers go to ActivityPub.rocks they want to learn how to make federated software. [...] The purpose was to show example code and get a developer up and running. It was not to explain the suite of specs known at the time as HTML5, or to even explain how the tech worked. The point was to get people quickly making things with the technology, and it's an enormous missing layer in our ecosystem and always has been.
> 
> Well, two responses to this, really:
> 
> 1) Making federated software doesn't require ActivityPub, and
> implementing ActivityPub doesn't require federation.
> 2) If you want people to "quickly [make] things with the technology",
> then the reality of federation makes that a lot harder, because a
> "quick" AP server is only a small part of the minimum viable stack
> needed to communicate. 90% of the difficulty is in what to do *after*
> you implement ActivityPub, if you want to trigger certain behaviors
> across dozens of divergent softwares which fundamentally do not agree
> on those behaviors.
> 
>> The existence of these non normative websites should be, imo, to get people using the tech. To the extent that a diagram helps with that, great. If people want Correctness, they go to the spec. If people want Reference, they go to MDN. I posit that if people want to get up and running, that's what ActivityPub.rocks should be for.
> 
> "Using ActivityPub" does not start and end with the fediverse. The
> fediverse is a popular application of ActivityPub in some form, but
> the fediverse could also stop using ActivityPub and still be "the
> fediverse". This already happened with OStatus, which was the original
> "fediverse".
> 
> I can appreciate that "correctness" is the domain of a spec, and
> "reference" is the domain of a documentation site, but I don't see a
> reason why activitypub.rocks should be incorrect or not referred to.
> We can have all kinds of resources on the website. It would be better
> if those resources didn't misrepresent the underlying technology,
> though.
> 
> In particular, a diagram for the ActivityPub section should still
> illustrate inboxes and outboxes:
> 
> - POST to outbox is how we publish activities.
> - POST to inbox is how we send notifications.
> -- POST to outbox typically triggers POST to inbox.
> - GET from outbox can be used to view published activity streams.
> - GET from inbox can be used to view received notifications.
> 
> The section on the fediverse can delve deeper into what to do after
> that -- what form should those activities take, and what do softwares
> typically do when receiving activities of a certain form.
>

Received on Wednesday, 24 December 2025 03:56:15 UTC