Re: "ActivityPub at one glance" diagram

I did misunderstand "post to outboxes" as "post to inboxes" so my
"bypassing federation" comment was indeed not really meaningful.

I do think that when developers go to ActivityPub.rocks they want to learn
how to make federated software. If we look at the history of "rocks"
domains relative to W3C standards the original (I think) is html5rocks.com,
which in its original form looked like this

https://web.archive.org/web/20101103105120/http://www.html5rocks.com/

You can see example code, working demos, tutorials, video presentations.
You can find articles that provide, for example, one developer's
interpretation of CSS flex box:

https://web.archive.org/web/20101022142606/http://www.html5rocks.com/tutorials/flexbox/quick/

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.

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.



On Tue, Dec 23, 2025, 3:55 PM cristianolongo@opendata <
cristianolongo@opendatahacklab.org> wrote:

> It Is Just an introductory slide  showing what i suppose was the First
> goal when AP had been proposed.
>
>
> Il 23 dicembre 2025 23:18:01 CET, Darius Kazemi <darius.kazemi@gmail.com>
> ha scritto:
>
>> Okay, but I do not think that we can explain ActivityPub *in its
>> entirety *in one glance. I think that far more useful than something
>> technically complete and accurate but overwhelming is a diagram that is
>> simplified but gets the point across and perhaps has a note that says
>> "simplified, please see diagram X for the full map".
>>
>> The problem with
>>
>> https://activitypub.rocks/static/images/ActivityPub-tutorial-image.png
>>
>> is that it is correct but not very useful. The problem with a diagram
>> that shows you can post straight to outboxes bypassing federation is that
>> it doesn't describe ActivityPub in use today by 99% of message volume.
>>
>> Perhaps what Johannes is looking for is a diagram of "How ActivityPub can
>> work in a federation context". Federation is the hardest part to get across
>> to people, and one of the issues is that federation itself is not specified
>> by ActivityPub, or indeed ANYWHERE. ActivityPub is a spec that supports
>> federation, and federation is left as an exercise to the reader.
>>
>> -Darius
>>
>> On Tue, Dec 23, 2025 at 2:11 PM a <a@trwnh.com> wrote:
>>
>>> On Tue, Dec 23, 2025 at 3:51 PM a <a@trwnh.com> wrote:
>>> >
>>> > to show what happens in the "rest of the world". The complete "AP at
>>> > one glance" would therefore be:
>>> >
>>> > Actor --> POST --> outbox --> POST --> inbox --> GET --> actor
>>> >
>>> > A lazy rendition of this using the existing activitypub.rocks graphic
>>> > as a base can be found indefinitely at
>>> >
>>> https://files.mastodon.social/media_attachments/files/115/771/056/837/692/305/original/e5fb9d66d668fec0.png
>>> > for visual aid.
>>>
>>> I would like to amend this slightly. The fuller picture would actually
>>> be 2 different flows:
>>>
>>> actor --> POST --> outbox --> POST --> inbox <-- GET <-- actor
>>> actor --> POST --> outbox <-- GET <-- actor
>>>
>>> The first one is the push model, and the second one is the pull model.
>>> Note that the push model revolves around the inbox, and the pull model
>>> revolves around the outbox.
>>>
>>> Another lazy rendition of a visual aid can be found indefinitely at
>>>
>>> https://files.mastodon.social/media_attachments/files/115/771/149/975/931/569/original/3eb69315559461b2.png
>>> with the colors/directions fixed and demonstrating both flows.
>>>
>>>