The ActivityPub test suite

We just created this topic About AndStatus to discuss C2S
Thanks to @how

Someone on the Fediverse asked for the test suite again. @rocco do you think you’d have some time to work on it? Maybe @yvolk can help as well. What do you people need to help around? I could activate Discourse SSO provider if this can help, @rocco.

Also, the person asking had the impression that ActivityPub is dead because of the test suite being down.
So depending on how bad the old test suite is and how much effort is needed to bring it up again,it might make sense to bring the old test suite back up while a new one is being worked upon, @cwebber.


[ attachment ]

and pinging @dansup


I think the main thing holding back lots of developers from adding ActivityPub support to lots of platforms is the fact that although the AP Spec looks great and seems very good, it is nearly impossible to make much progress with coding because when you try to federate against Mastodon or some other AP site, stuff will not work, and there’s absolutely no way to know what’s going wrong.

Without a test suite tool, the only way to make progress is to get a copy of Pleroma or Mastodon, and install it, run a server yourself, and basically reverse engineer it by watching the HTTP traffic or logging.
Obliviously this is a hurdle not many are going to get over. It’s even worse than that, because both Ruby and Elixir are oddball languages that hardly anyone is using, so the odds are that 99% of the devs that want to implement an AP server are just going to find it nearly impossible.

So the net result is that there is MUCH lower and slower adoption of ActivityPub in the world. Once there’s a test suite available the ecosystem will really take off rapidly, but not until then.

Update: There’s one other alternative that ‘could’ work instead of a test suite tool, and that is a set of complete “Request and Response” conversations for various example scenarios (AP actors and actions), that contains all the HTTP Request headers, URL parameters, and JSON responses, so that there’s no “guess work” having to be done to interpret the spec.


I agree. There is an alternative testsuite. Check Unofficial Test Suite (go-fed/testsuite) created by @cjs . Imho, given this is the only functioning testsuite, it could as well become the Official one :slight_smile:

The testsuite should be made discoverable, though, like with a mention on Same for @dansup’s FediDB (which is out of closed beta, I think?). See Introducing FediDB - DevTools for ActivityPub.

There’s an ongoing discussion related to this: Easing the onboarding of new developers to the Fediverse.


Added to

@cjs @rocco
If someone would propose a session for the Conf about Tests, I would join :wink:
Also authors of various tools are at the Conference, e.g.

1 Like

I would be happy to help find funding to fix the test suite if people step up to implement it.

One of my goals is to add ActivityPub into my project (to make it Federated) and I’d be willing to do implementation in TypeScript and/or Java for a test suite if I had funding, because I could accomplish both objectives at the same time.

But as I said before, we really wouldn’t even need a TestSuite that much (for new apps at least) if we simply had complete JSON examples including both Request JSON and Response JSON for most of the various C2S and S2S use cases.

These examples would add so much clarity that actually most of the other documentation would be not even needed…at least to get something up and running, which is the primary challenge.


This is useful for me too. I have implemented partial ActivityPub support in an open-source Rails app and it would be nice to know if it meets the actual spec or if it falls short.

How about building a Postman collection as a start? It supports fully automated test cases and can generate code in multiple languages.


This sounds like a possible #hackathon topic.

I think a test suite naturally falls into two parts. One part checks protocols which can be accessed anonymously. This involves AP services such as looking up a user’s inbox and paging throug it, as well as non-AP services commonly used with AP, such as webfinger and the other .well-known services.

The other, more complicated part, checks AP support. This will need to be able to create ephemeral accounts on the fly (like, each lasting a few hours, and allow you to follow them and send them messages, with a dashboard showing what has been received.

You should also be able to request that the accounts send you messages— but not to set the content, to stop the validator being used as an anonymous message service. For similar reasons, I’m also supposing that each temporary account would be locked into communicating with a single server, specified at creation time.

You may be interested in the BoF session: The ActivityPub Test suite


thank you! I’ve c&p’d my response there.

1 Like

I won’t be able to participate in the hackathon, but definitely once I have reasonable detailed examples of the JSON inputs/outputs for a ActivityPub service, I’ll add AP capabilities to (link above), and I’m looking for other developers (and/or funding) who can recognize the value of that platform, especially after AP is added!


For the funding part see Scaling Up Cooperation BoF…

4 posts were split to a new topic: Appealing to Users With Examples in Software Demos

Thanks for the link to the funding related stuff. I’m going to submit the Quanta project for that. The project is still pretty much a secret (unknown), and hasn’t been posted to HackerNews or other developer sites yet, although I’ve been developing it for years and it’s fairly robust/stable at this point.

About the jet, that X-15 is the “lorem ipsum” of images! haha. Everyone should use the X-15 for demo content images. :slight_smile:

what is the current state?

Came here after bouncing from many open issues and threads elsewhere (w3c/activitypub#351, go-fed/testsuite#16).

What is the current best course of action for developers looking to validate current implementations of ActivityPub, or write their own?

1 Like

What worked for us was to first develop Lemmy-Lemmy federation, as this allows for easy testing and debugging. Later we started federating with other projects, which obviously brought some breaking changes where we did things wrong, but it wasnt a big deal.