The slow release¶
But not really though. This is actually the release that brings the biggest improvements to user facing page load speeds. But that’s only because our storage backend du jour (the fielsystem one) is becoming very slow on small-to-medium size activity collections[1].
More caching¶
This problem with the storage layers is something that we definitely need to investigate further, but for the moment we patched over it by using caching at FedBOX’s handlers level.
This was simpler than expected and it works by adding a simple map between the served item’s IRI and the ActivityPub Object that represent it (be it a simple Object, Actor, Activity or a Collection).
We needed to take into account also the fact that the results are different depending on an Object’s recipients (Public vs. non public with specific recipients), so the mapping function we used had to be based on a combination of authenticated user besides the accessed IRI.
We also takled the very “simple” issue of cache invalidation, which in our case actually was pretty simple. We invalidate the cache entries (which, if you remember, are mapped by IRIxAuthUser) when we process incoming Activities.
The specific mechanism is to search for the Activity’s Actor’s Outbox, and for the Recipients’ Inbox URLs and invalidate all cached entries that contain them. We also need to invalidate the inidividual object and collection caches for the activity itself (and the global /activities collection), and for the Activity’s Object and it’s containing collection.
Eg, the actor was https://example.com/actor/jdoe we search for all entries in cache matching https://example.com/actor/jdoe{/outbox} and invalidate them.
Show user’s scores in go-littr¶
Another small improvement, which funnily resulted in a lot of changes having to be made, was adding back the scores[2] for the logged in user and for any user profile page we’re visiting on go-littr.
Spec compliance improvement¶
During the #ApConf2020 there has been some work done on the new ActivityPub compliance suite[3] developed by cj I noticed that FedBOX is not actually compliant when it serves deleted objects because it didn’t respond with a 403 Gone HTTP status header. This has now been fixed.
#updates #october #new-release
[1] This happens because filtering works by scanning through the whole collection and applying filters on each individual element. Then each activity loads its corresponding Object, Actor or Target that the user requested for, which implies another scan and filtering. Overall the process touches the “storage” a lot of times, and for the backends that are not database backed, we probably we’ll need to invent our own indexing schema that would prevent full collection scanning.
[2] These scores are not calculated in the same way as other link aggregators do it, as a reflection of the community’s approval for the user, but represent their “positivity score”. That means it’s calculated based on the number of Likes and Dislikes they have dispensed on items.