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.
For people interested in #ActivityPub#C2S (client to server), the #GoActivityPub services have gained the ability to dynamically register OAuth2 clients based on RFC7591.
#ActivityPub client to server is severely impaired by "authorized fetch" because usually before building an Activity to send to an Actor's outbox, one would want to validate some of the IRIs they operate on.
For example, I want to build a Follow request for a remote actor (represented by an IRI or webfinger resource). My client won't allow me to add this random IRI as the Object of the Follow and just send it, it wants to dereference it and make sure it's a valid Actor.
However when authorized fetch is enabled on that actor's instance, this dereference will fail, because the client can't generate a valid HTTP Signature for its request. :(
Need a palate cleanser after the past weeks where I worked furiously on storage backends for #GoActivityPub fixing tests and building a conformance suite.
I think I'll try my hand at a static site generator. It would also be part of #NLNet sponsored work, but only tangentially so, as it would form the base for generating the documentation wiki for the library.
After starting the work on the conformance suite for the #GoActivityPub storage backends I, of course, got the nasty surprise that none of the existing ones are actually passing all the tests. :D
On this topic, calling all #Go#developers interested in lending a hand.
I have two major goals for increasing the unit-test coverage in the individual packages that #GoActivityPub is comprised of.
These are tasks that are very accessible even for people new to the #ActivityPub spec and I would prefer to support new developers that want to give it a try than wait until I have time to do them myself.
The only requirement I have is that if you want to help, you already have some public Go projects that I can have a look at.
Point of contact is on this email (after you "deobfuscate" it): goap@federated·id