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

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-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

[[email protected]](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?