Nostr notes by evan

One of the big pain points for ActivityPub developers is ...

2026-08-16T18:11:05Z

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!

I wrote up some recommendations about implementing paginated ...

2026-08-15T22:10:44Z

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.

This is a discussion thread for an open issue on GitHub: ...

2026-07-28T21:12:27Z

This is a discussion thread for an open issue on GitHub:

https://github.com/swicg/activitypub-e2ee/issues/83

We had a meeting of the E2EE Task Force. One participant asked ...

2026-07-28T16:34:31Z

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?

julian (npub1mlk…nu5a) ?

So, a few good things about this format (rather than embedded ...

2026-05-14T20:25:29Z

In reply to nevent1q…v4nj
_________________________

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.

For the [ActivityPub API Task ...

2026-01-10T20:01:28Z

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?

Nostr event nevent1qqszndpz733qek98tgm95wemlewyxa5pfej4k8klrumkd7ae5qv8x5szyplplku36vthgj5y3w6sa9env2025pt7zcrq6pc0ypemenqhfhrazu4r99a

2025-09-06T22:21:39Z

In reply to nevent1q…jfrq
_________________________

[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

https://checkin.swf.pub/ is an example ActivityPub API client ...

2025-08-27T02:48:56Z

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?