@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