I have finally I made significant progress on this.
The final code looks like this:
https://github.com/go-ap/filters/blob/master/bytes_filter.go#L199
For a list of filters that #GoActivityPub uses, we generate two patterns for Quamina: one for a denormalized raw document, and one for normalized raw document (they usually are stored in a normalized form, where an Activity's object/actor properties are flattened to their IRIs, but we can't know which it is unless we unmarshall it, which we want to avoid)
Another improvement from my complain from 4 days ago is that I was regenerating the patterns and initializing quamina for every new document, instead of one time per collection load.
One good thing of my extended sabatical from corporate employment is that while I'm working on #GoActivityPub there's so many things to do, that as soon as something interesting catches my eye, I can go explore it and learn a new thing that can be used, adapted or added to one of the components of the library or its adjacent tooling and applications.
Currently, I'm excited to replace the existing HTML sanitizer for TrustedTypes and setHTML in #ONI as they're finally making its way to Firefox.
I've started my exploration of using @timbray's Quamina project for saving some compute time in the filters module of #GoActivityPub
Currently the GoAP storage backends iterate over resources (usually stored as raw JSON bytes), unmarshal them into GoActivityPub object structs, and *only* then apply the custom filtering logic on those objects. Since the majority of the objects generally fail the filtering logic, all that JSON decoding is wasted compute time and makes things slower.
Ideally quamina will allow me to check the raw JSON payloads directly against the filters, streamlining the execution and speeding things up. 
I ran the new go1.26 go fix tool on the #GoActivityPub modules and I was surprised how little improvements it had to suggest.
Most of them were due to minimal version being pre generics and pre interface{} -> any change.
I started adding #C2S #proxy_url support for #GoActivityPub services and it looks like it's easier than I imagined it initially.
On the server side, implementing the proxyURL handler doesn't need any new additions as it shares 90% code with other handlers that return #ActivityPub objects.
On the client side, I'm creating a new http.RoundTripper that can use the proxyURL transparently for the caller.
As a developer in your client code you only do a regular request for a remote URL, and the round-tripper handles the proxying part transparently if it has all the available bits: a server that supports proxyURL and a valid OAuth2 session towards that server.
My project that converts #SourceHut wiki repositories into static websites is finally getting to the point where it works quite well.
I've integrated it into my flow for the #GoActivityPub documentation and it looks decent (in my biased opinion), the docs themselves are not great, but I'll do another pass over them before we release a v1 of the library.
After much faffing about, I have implemented the dynamic #OAuth2 client creation for #GoActivityPub services using the Client ID Metadata Document[1] that's been proposed as a replacement(?) for RFC7591 (Dynamic Client Registration Protocol).
The changes are in both the Authorization service and in the BOX #ActivityPub client to server helper.
[1] https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/
This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed.
I'm happy to say that we finally have a logo for #GoActivityPub, courtesy of @andycarolan 🙇
If anyone is using the latest versions of mattn/go-sqlite3 module you might have an unpleasant surprise if your tables contain JSON data in BLOB columns and the table is also using STRICT.
Since sqlite 3.45.1 it's encouraged to move those columns to TEXT.
https://sqlite.org/json1.html#the_json_blob_input_bug
I spent two days trying to find why the #GoActivityPub sqlite storage
has started to fail out of the blue (well, not really "out of the blue", rather an unfortunate congruence of dependency updates and adding extra stress to the json payloads saving/updates).
marius