He/him. Board member at [CoSocial.ca](http://CoSocial.ca ).

Research Director, Social Web Foundation.

Director of Open Technology at Open Earth Foundation (OEF).

Author of "ActivityPub: Programming for the Social Web" from O'Reilly Media.

Founder of Wikitravel, StatusNet, [identi.ca](http://identi.ca ), [Fuzzy.ai](http://Fuzzy.ai ).

Creator of [pump.io](http://pump.io ). Co-creator of GNU social.

Co-chair of the Social Web Working Group at W3C. Co-author of ActivityStreams 2.0. Co-author of ActivityPub. Co-author of OStatus.

Grad student in CS at Georgia Tech.

In Montreal, from San Francisco. Greek, Arab, American, Canadian, cook, gardener, runner, dad, husband.

Last Notes

seekItem is a new spec for finding objects by id inside collections:
https://swicg.github.io/activitypub-api/seekitem
It can help with catching up on a collection, or with determining membership in a collection.
In our ActivityPub API Task Force meeting today, we decided to move this spec forward to CG-DRAFT status. That means that we intend to make it a CG-FINAL report, and we're soliciting implementations and comments.
I've implemented it twice on the server side, in activitypub-bot and onepage.pub. It was easy, since I already had internal functions for seeking items inside a collection with indexed lookup, so O(log N) complexity.
I am working on using it on the client side; for example, confirming that if A follows B the B is in A's following collection and A is in B's followers collection. It's a hassle with serial access, but I think it can be quite quick with seekItem.

2026-10-04 17:05:23 UTC

- reply

I added a FEP today: https://codeberg.org/fediverse/fep/pulls/945

2026-09-03 22:55:00 UTC

Would it be helpful to add an (optional) logical clock mechanism to ActivityPub?
https://en.wikipedia.org/wiki/Logical_clock
For example, to handle Delete before Create or Undo before the activity being undone?

2026-08-16 18:11:05 UTC

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](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12). There's a helpful [ActivityPub and HTTP Signatures](https://swicg.github.io/activitypub-http-signature/) 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](https://swicg.github.io/activitypub-http-signature/#how-to-upgrade-supported-versions), [capability discovery](https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md), or something else.
To track support for RFC 9421, I added an [adoption matrix](https://swicg.github.io/activitypub-http-signature/RFC9421) to the ActivityPub HTTP Signature repo. I grabbed all the [software listed on FediDB](https://fedidb.com/software/), 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](https://github.com/swicg/activitypub-http-signature) repo.
Thanks!

2026-08-15 22:10:44 UTC

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.

2026-07-28 21:12:27 UTC

This is a discussion thread for an open issue on GitHub:
https://github.com/swicg/activitypub-e2ee/issues/83

2026-07-28 16:34:31 UTC

We had a meeting of the E2EE Task Force. One participant asked for a way to participate in discussions without using GitHub. I think having a topic here on activitypub.space would be a great way to do that, and the task force agreed (notes here: https://pad.w3.org/p/ActivityPub_E2EE_Task_Force_28_Jul_2026).
How do we add a space for it, like the other task force spaces?
@npub1mlk…nu5a ?

2026-05-14 20:25:29 UTC

- reply

So, a few good things about this format (rather than embedded objects):
1) The page is much more cache-friendly. The only thing you have to keep track of for `Last-Modified` headers is the state of the page -- not the state of every single object in the page.
2) It can handle a lot more items in a single page. If an URL is about 256 bytes on average, you can have about 100 or even 200 items in a single page and still have a well-performing payload in the low 10s of kiB ranges.
3) The activities can be cached, too. You might not need to load all of them.
I lean towards big pages with URLs now. See https://tags.pub/user/linux/outbox/5 for an example.

2026-05-07 18:51:21 UTC

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](https://www.w3.org/TR/activitypub/#shared-inbox-delivery) 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?

2026-01-10 20:01:28 UTC

For the [ActivityPub API Task Force](https://github.com/swicg/activitypub-api), I started an issue to discuss [OAuth client reputation systems](https://github.com/swicg/activitypub-api/issues/44).
A reputation system tracks which OAuth clients are known good, known bad, or unknown. Servers could use this information to limit what clients can do. For example, a server could prevent users from logging in with a known bad client.
The reputation could be based on human curation and review, or on automated collection of evidence from historical behaviour of the client.
I'm trying to find examples in the OAuth ecosystem of this kind of reputation systems -- either local or distributed.
App store approval (and user reviews) are a good example for native apps. [OpenBanking](https://www.openbanking.org.uk/directory/) keeps a client directory that needs human curation and review.
I don't have examples from OAuth -- especially with [dynamic registration](https://datatracker.ietf.org/doc/html/rfc7591) or [CIMD](https://cimd.dev/).
Any ideas?

2025-09-06 22:21:39 UTC

- reply

[smallcircles@social.coop](https://activitypub.space/user/smallcircles%40social.coop) you might be happy to see that there's a new ActivityPub API task force:
https://github.com/swicg/activitypub-api

2025-08-27 02:48:56 UTC

https://checkin.swf.pub/ is an example ActivityPub API client that implements the Geosocial schema for ActivityPub -- https://github.com/swicg/geosocial for details.
I've been testing it with https://onepage.pub/ which has a pretty good implementation of the API. I'm interested in trying out some more servers, though; especially the OAuth 2.0 implementations.
Right now, I know of Pleroma as an API implementation. Also, maybe Mitra, maybe Bonfire? Any other implementations of the API to recommend?