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
@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
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.
Due to the long time I neglected brutalinks.tech, tech debt overwhelmed the server and I had to put it down.
It's currently in maintenance mode for the near-medium future, until I manage to get back to it and bring it in working order.
It's likely that the only people disturbed by this development are random spammers, but still, apologies.
@linos my project #FedBOX supports multiple values for the attributedTo property on ActivityPub objects.
The use case this was required for, even though it's not implemented at the moment, was when mods would edit an object that came under scrutiny on the main client that uses FedBOX as a backend, the #brutalinks link aggregator.
Collaborative editing would also work, but there are no clients capable of that at the moment.
@ernest I see you posting more and more about community management and server/service maintenance than coding on the project.
How do you deal with doing both: a maintainer for a project and a community manager ?
I was trying to push people interested in #BrutaLinks in starting their own instances instead of using mine, and seeing how nobody took me up on that, it feels like it's the losing strategy. :D
I keep being on a roll today. I discovered the mystery of why #BrutaLinks doesn't show follows coming from Mastodon.
It actually does, but because they don't have a published date they are ordered at the end of the inbox, so I had to go all the way to the end of the listing to find them. Sigh...
Another one to put on top of the pile of #mastoquirks
One of the small things I managed to do while sick this week was to add support for <link rel=alternate type="application/activity+json"> for all the pages where this makes sense.
So now the instance and the individual users are directly discoverable on Mastodon instances by entering the URL in the search box. (Accepting the follows is not functional at the moment... oops)
Ex instance: https://brutalinks.tech/
Ex user: https://brutalinks.tech/~marius
marius