@graves501 you can take a look at this project which makes use of all the modules under the #GoActivityPub library and provides an easy to setup instance for one person:
https://git.sr.ht/~mariusor/oni
One demo instance is at https://marius.federated.id
It's going to be rough to use, but please write to the mailing list I have set up for the projects with your questions, and we can at least improve the docs. :D
I'm being driven up a wall by a Heisenbug I have with the #GoActivityPub HTTP-Signature plumbing.
On a multi tenant #ActivityPub service where I have two Actors, one of them can interact with the Fediverse at large without any issue, while the other gets HTTP Signature validation errors for every request.
There's no suspicious difference between the two private/public key pairs of the two actors. (I've even tried using the same key pair)
Sigh...
Working hard on implementing a bare-bones version of RFC 7591: dynamic creation of OAuth2 clients.
Hopefully this helps generic fediverse clients like AndStatus to authorize users with #GoActivityPub based services.
I've had a ticket to implement IndieAuth for the same purpose since forever, but somehow this felt easier in the moment.
@naturzukunft in #GoActivityPub we support a Create activity with a list of objects as an Object.
However for your specific case, when creating an object which depends on another object, I usually create them using two separate Create activities.
I use this when I push a note that has many tags: first I create the tags (if not existing) and second the note with the tags.
Sad to say NGI Zero didn't accept my grant request for #GoActivityPub.
I am a bit disappointed if I'm honest. I hoped that a library that threads new ground for developers for both client and servers applications would have fit their criteria very well. I might not have made the case well enough I guess.
@hongminhee in #FedBOX and #GoActivityPub there's a cascading of behaviour for each ActivityPub object type, so you can call code on a Person/Group/etc, making the assumption that it has the more limited shape of a regular Object.
Since Go doesn't have more fancy types of polymorphism, I had to use some very ugly work arounds to be able to make this work. :( Sometimes I wish I was still working on a more powerful typed language, or a dynamic typed one.
Well, fixing this took way more than it should.
And it's another of those issues where I optimized too early in the life of the #GoActivityPub project and it now bit me in the behind. I split the library into too many modules, which granted are pretty independent functionally, but they create a web of dependencies that is hard to navigate sometimes.
The problem was that one of the modules that I forgot I modified in order make tests pass was not pushed upstream, and all the storage backends depended on it to be fixed.
Oh man, why did I ever think that implementing multiple storage backends for my #activitypub service was a good idea?
Having to backport new features across 4 versions is becoming a bit of a pain in the butt I have to say.
It's a painful realization that I come to that no matter how much effort I put into making my #ActivityPub server be fast it's still going to suck if in order to build a meaningful page for a user the client needs to do many requests.
So the #brutalinks link aggregator now makes use of asynchronous collection fetching and then content rendering is being done from local storage.
This decreased the loading times to probably less than half of what they were before.
However I still need to find a good model for aggregating and balancing all the sequential loads with an eventual asynchronous sequential sending of activities.
After what seems like a thousand years I have started replacing some synchronous client to server #ActivityPub fetch requests with loading the same information from an indexed cache in my link aggregator.
I think I've started the work on inbox/outbox async fetch and indexing around 3-4 months ago, and only now I am able to make proper use of it.
I guess I should have used a real RDBMS instead of reinventing the wheel on every turn. :D
The experiment of using roaring bitmaps as the foundation for indexing #ActivityPub objects is half successful and half not.
The good news is that soon I'll be able to replace the #brutalinks client access to it's activitypub backend with something that's built on top of local storage that makes use of the indexes, therefore being much, much faster.
The bad news is that adding indexing to the storage backends themselves didn't result in too much performance gains, but I just suspect I'm doing something wrong.
Another piece of risky code that relies on Go compiler internals is added to the Rube Goldberg machine that is the #GoActivityPub library... Sigh.
The link to the code: https://git.sr.ht/~mariusor/ssm/tree/af069f49e3607f1233a0680bb779d236c8dcb897/item/error.go#L86
The full(working) example can be found here: https://pkg.go.dev/github.com/go-ap/filters#example-SearchIndex
Since I'm such a fan of handmade programming, I find myself this fine eve implementing document indexing from scratch(ish) for my #GoActivityPub library storage backends.
I think I'm on the third, or fourth iteration, maybe even fifth if counting from when I started doing the same work for a different project, of #TUI editor elements using #bubbletea for the #GoActivityPub data types.
It's so frustrating doing UI. :(
For the past couple of days I've kept being frustrated by building the TUI elements for the vocabulary module of the #GoActivitypub library.
I reached the point where I need to take a break from it, and to keep me busy I just found a way to include #bandcamp player embeds in the posts of the metal release bot.
Currently it looks like this, but just imagine it with embeds instead of "Band - Album title". :D
I often struggle with working on non-trivial, long standing projects because when I sit down to do the work after some hiatus, I can't seem to find the pain points I wanted to fix quickly enough.
It feels like trying to get a bandaid off when you can't find an edge where it comes unstuck easily enough.
The largest piece of bandaid that I wasn't able to get unstuck from the ActivityPub adjacent work is getting the HTTP-signatures working well with the rest of the fediverse (by which I mean Mastodon).
Today I might have got the corner of another little bit of bandaid unstuck which hopefully will help in the long run.
