- From: a <a@trwnh.com>
- Date: Tue, 23 Dec 2025 15:51:35 -0600
- To: Johannes Ernst <johannes.ernst@dazzlelabs.net>
- Cc: Cristiano Longo <cristianolongo@opendatahacklab.org>, public-swicg@w3.org
On Tue, Dec 23, 2025 at 1:51 PM Johannes Ernst <johannes.ernst@dazzlelabs.net> wrote: > > Your base diagram — two users on server 1 interacting with two users on server 2 (e.g. slide 5) — is, I think, closer to “AP at one glance” than what is currently on activitypub.rocks, for which one needs to have some understanding already about the basic architecture. > I disagree about it being "closer" or "the basic architecture". The slides with "Social A" and "Social B" show *one possible instantiation* of ActivityPub, where the inbox and outbox seemingly live within "Social A <www.server1.org>". I wouldn't be able to say for sure because the slides *neglect to mention the inbox and outbox entirely*, which makes them a poor "AP at one glance" because they don't illustrate the primary mechanisms of AP: the outbox and the inbox. What the diagrams in the slides PDF illustrate is instead "the basic architecture" of federation. It fails to capture or account for the possibility of Alice POSTing directly to Charlie's inbox, or that Charlie has an inbox at all. Perhaps a better diagram would take the existing activitypub.rocks diagram and clone it to the right mirrored, 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.
Received on Tuesday, 23 December 2025 21:52:19 UTC