Skip to main content


So I've been trying to learn more about ActivityPub lately, but it's been pretty hard to get started.

I tried reading the spec, but it's not that helpful. It's vague and hard to understand. I just want to see some examples I can plug into postman. Also, the examples they show are useless without showing the headers you would need to add to the request.

There are some tutorials by Eugen (Gargron). They are ok, but I couldn't get his examples to work. (I'm sure they are great examples, but I don't know enough to debug/modify them to work for me)

There's a whole website that really tries to group all the activitypub info together, common libraries, projects, theres a test suite, but no examples.

So what finally worked? I just downloaded the #Friendica code and started stepping through it in PHPStorm! and I would recommend anyone wanting to learn more about #ActivityPub do the same. Its a little work setting it up, but you can just set breakpoints and watch all the activitypub requests as they happen and see how they are used!
It’s a little bit weird at first, but it helps to understand some of the technologies that came before it: namely, OStatus and the Diaspora protocol.

The big thing is that this is a network comprised of Actors. An Actor is usually a Person, but it can otherwise be an Organization or a Group. Actors perform Activities on Objects - generally, these interactions can be represented in a stream of some kind.

In the ActivityPub world, Actors have an Inbox for ingesting subscribed content (activities and objects from other actors), and an Outbox for dispatching their own stuff, which is then sent out to a collection of Followers. Most implementations have a notion of permissions, in the sense of who is allowed to parse or even receive an Activity.

Of course, the protocol and implementations go way deeper into that, but this is the general gist of how ActivityPub is supposed to work.
LitePub is also interesting here:
Yeah, thanks for the overview @Sean Tilley
It's a pretty big spec and kinda overwhelming,

I haven't even read about OStatus or the Diaspora protocol yet, but I should really look at them too. Maybe I'll do that next week.

I think the biggest problem I had is, if you want to start from scratch, you have to write quite a bit of code just to post a message to mastodon/friendica, and I had a much easier time looking at an existing project's code than writing my own. (I'm lousy at web programming. I mostly write desktop apps in C#)

Also, I just want to say, I'm amazed level of interoperability between all these projects (especially mastodon, pixelfed, pleroma and friendica)
Also check out the #ActivityPub guide to new implementers, and - since it is a 'crowdsourced wiki post - consider making improvements based on your own experience getting started.

#SocialHub community is good for asking questions, and in the archive of topics you may find a lot of helpful stuff.
Yeah, the hardest part is just finding a good starting point. I'm kind of on the fence about forking #Pleroma, but I'd have to double down on my knowledge of Elixir and JavaScript to be any good with it.
Depending where you wanna go and most familiar with, that may be a good starter. There's also #Bonfire in #Elixir which is setting in a new direction I find exciting. And they can need helping hands now that they are moving towards a beta for their Social components.

@kevin are you familiar with the #Fediverse #delightful lists? They can be found at
Very cool! Those are some good lists!
It helps a bit to understand the actor model and realize that activities are messages being passed to an actor.

Sadly AP breaks the actor model *caugh*because Mastodon*caugh* but otherwise it fits the model pretty well and thus could use an alternate transport such as what @pukkamustard is doing.
@pukkamustard What do you mean when you say "Breaks the Actor model"?
In an Actor model system, messages are sent to an actor.

In ActivityPub, sharedInbox breaks the actor model by placing work on the server to filter on whether or not the message should be delivered to the recipient, rather than sending it to multiple recipients.

This violates the principle in an actor model system that an Actor should be the computational unit of work.

The right (tm) way of handling this IMHO is to either not offer a sharedInbox or else to have a special Actor called _all whose job it would be to decide who to deliver to, but by using this concept called a sharedInbox, you violate that principle.