Re: "ActivityPub at one glance" diagram

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 01:11:59 UTC