One of the big pain points for ActivityPub developers is supporting HTTP Signature in their servers. The Fediverse uses an out-dated draft standard, draft cavage 12. There's a helpful ActivityPub and HTTP Signatures report from the SocialCG, but it's still kind of a slog.

Some server software has begun the pivot to the release version using double-knocking, capability discovery, or something else.

To track support for RFC 9421, I added an adoption matrix to the ActivityPub HTTP Signature repo. I grabbed all the software listed on FediDB, and laid out a matrix of whether it accepts RFC 9421 signatures for GET and POST or sends RFC 9421 for GET and POST. I also included a way to find relevant bug-tracker issues.

https://swicg.github.io/activitypub-http-signature/RFC9421

It would be a huge help to get some more eyes and data on this adoption matrix. If you know about a Fediverse server package's support for RFC 9421, including your own, please make a PR against the RFC9421.md file in the swicg/activitypub-http-signature repo.

Thanks!

I wrote up some recommendations about implementing paginated collections.

https://ghost.evanp.me/implementing-pagination-for-activitypub-collections/

tl;dr (read the full article for the whys):

• Have big pages – 128 or 256 items per page.
• Inline the items for small collections.
• If you're already using offset pagination, change to cursor pagination ASAP.
• If you're implementing from scratch, consider using bucket pagination.

There's a new draft of the basic profile for Social API Servers from the ActivityPub API Task Force:

https://swicg.github.io/activitypub-api/basicprofile

It covers some very basic features for getting an interoperable set of clients and servers working together to provide simple social networking functionality.

I've found at least four different formats used on the Fediverse for the X-RateLimit-Reset header:

• A datestamp (Mastodon)
• Unix epoch in seconds
• Time offset in seconds (N seconds from now)
• Unix epoch in milliseconds (Holos)

It's possible to use some heuristics for these (looks like a date, looks like an integer, range of the integer), which are pretty reliable.

The new RateLimit headers from IETF are very nice, but don't seem to be well-supported yet.

So, one part of the popular imagination about ActivityPub I've seen is the idea of server federation.

I think the idea is that if two servers have interacted in some way, all (?) public (?) content from one server will be sent to the other server, and vice versa.

This comes up a lot with new servers; people ask to have a post shared broadly so that their server rubs shoulders with others, getting the federated feed flow going.

ActivityPub does in fact have a mechanism defined for this:

> Additionally, if an object is addressed to the Public special collection, a server MAY deliver that object to all known sharedInbox endpoints on the network.

As far as I've seen, most (?) servers don't implement this; it would overwhelm small servers pretty quickly.

However, some (?) servers do implement it for some (?) activities, especially profile update and delete activities.

Is this the origin of the idea that new servers need to have their content shared around? Are people misunderstanding the way that relays work? Is it just a trick to get your content shared?

In the HTTP Signature Report we suggest a double-knock strategy for deploying RFC 9421. Basically, try RFC 9421 first, and if you get an error, downshift to draft-cavage-12 and try again.

I just realised, in testing with Pixelfed, that this doesn't work if the remote server doesn't check signatures in the Web routes. Pixelfed returns a 200 response for POST requests signed with RFC 9421, but its backend workers reject the input because Pixelfed doesn't understand RFC 9421. So, it silently swallows activities with RFC 9421 signatures.

I think there are a few other strategies to try. One is tit-for-tat: if a host sends you POST requests signed using RFC 9421, you should be able to send them back with RFC 9421. Another is checking for the Accept-Signature header. Finally, you can use an allowlist/denylist based on nodeinfo, the Server header, or the User-Agent header.

Has anyone else figured out a good way around this?