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

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.

@naturzukunft I'm actually making heavy use of the filtering capabilities in #FedBOX: https://federated.id/inbox?maxItems=100&object.type=Person&type=Create

@julian that's an acceptable compromise, in fact it's #FedBOX uses both methods for threading. :D

@drahardja @dgoldsmith

@naturzukunft the server (the one I'm most focused on) is called #FedBOX: https://github.com/go-ap/fedbox

As a client I'm working on a link aggregator called #brutalinks: https://github.com/mariusor/brutalinks

I'm sure I made plenty of mistakes, but I have to admit I find it surprisingly satisfying to be able to operate on a data type that I can overlay on top of the existing #FedBOX storage engines and get native and *fast* querying for them.

The indexes are quite chunky despite being built on top of roaring bitmaps because there's so many "indexable" elements in an #ActivityPub object. (Currently I'm indexing the type, the content, summary, name, preferredUsername, the recipients, the actor and the object)

As I explore some more, I hope I streamline some of these issues, and make the whole thing more robust.