✅ proxyUrl for #FedBOX on the server side and for #BOX on the client side.

Now I have to port the server bits which (like I said previously) are quite simple to #ONI, where it's more important to have them for me personally.

@steve in #FedBOX I'm using the instance actor's regular inbox as a sharedInbox for the others.

I'm not sure in which way you're thinking it can help with federated vs. local timeline though, as the simplest logic to do that (IMHO) is to verify the activities' actors if they belong to the same instance as the actor that operates the "client". And for that it does not matter where they've been received.

And, in my experience, building timelines in clients can't really be done at viewing time due to inherent slowness in the AP fetches required. The clients need to buffer the collections locally and then they can apply whatever logic on top.

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

#go #activitypub #FedBOX

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.

#FedBOX #GoActivityPub

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.

#FedBOX #GoActivityPub

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

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.

#GoActivityPub #brutalinks #FedBOX

So a quick recap for what #FedBOX and #GoActivityPub adjacent projects I started in the meanwhile:

* a single instance fediverse server meant to simplify how FedBOX works (called ONI). https://git.sr.ht/~mariusor/oni

* a TUI interface for operating admin actions on FedBOX/ONI instances. It's meant to serve as a base for a C2S client for them also. https://git.sr.ht/~mariusor/motley

3/

In #FedBOX land, I have finally made progress in excising the OAuth2 routing to its own individual service.

Deploying has increased complexity, but it paves the path for replacing our spit and duct-tape user management to something more robust, like #ory #kratos.

Leftovers in FedBOX are the OAuth2 client CRUD operations, soon to be replaced with automated client creation.

#activitypub #GoActivityPub

Made the export/import functionality of a #FedBOX server work better, with support for renaming the instance.

This was never a feature meant for production use, but more and more I realize how using json as a format is on the high end of terrible. :D

Before taking a break from ActivityPub at the start of the year I was working on bringing all storage types for #FedBOX (the generic #ActivityPub service) to better support persistence of collections.

Finally over the past weekend I managed to bring the sqlite backend (the last remaining) from ~180/458 failing integration tests to just 10/458.

It was definitely a journey.

The best part of this is that it paves the way for any #Golang sql.DB compatible database.

@laxla that's what I'm trying to do with #FedBOX

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

@jenniferplusplus In #FedBOX I use the ActivityStreams context property to point to the ID of the top level object, which is nebulously defined in the spec, and if you squint at it in the proper light, it might actually fit the purpose. :D

@helge

@jenniferplusplus in #FedBOX I use a list of IDs when sending an object as a reply. The list contains all ancestors of said object all the way to the initial grand parent.

It makes it easier to generate trees out of the replies, but it's also maybe a misappropriation of the reply concept. :D

@helge

I made some more progress on the application I plan to bundle as an admin tool with #FedBOX, the generic #ActivityPub server, and #Oni, the no frills single user instance.

It's called #Motely and it looks like this currently.

#GoActivityPub #CharmSH #BubbleTea