Private container to cache resources shared with me

Context and use case

If tomorrow we used SAI for the Welcome to my place app, the performance would most likely be very bad.

In my own account, about 50 people shared 300 events with me. And I need to list them by date, filtering out events that are in the past.

I have also created about 30 events. It would be easy to sort these with a SPARQL query or with our upcoming container SHACL filtering. But I cannot do this with the 300 events shared with me because I only have their URIs, and I can't do any filtering before I GET them.

So if I switched to SAI, I would need to load 50 Delegated Data Grants (DDG), and then 300 Data Instances (events) linked from these DDG. After I've loaded all these 350 items (+ my own 30 events), I would need to order and filter them, to display (in the end) 10 events per page.

Since browsers do not fire more than 15-20 requests at the same time, it would probably take several minutes just to display these 10 events -- something that it is not acceptable to any modern user.

I'll point out this is a problem that is general to Solid. The lack of real applications make it less visible.

Proposed solution

In ActivityPods, we cache (in the user's storage) the resources that are shared with them. Right now, they are cached in the same LDP container as the resource that they created ourselves, but it could be a different container. Thanks to this, it's easy to filter and order resources (with a SPARQL query and, tomorrow, with SHACL shapes)

The cache is kept up-to-date thanks to ActivityPub: whenever a resource is updated, the resource owner sends a UPDATE activity to all users with whom the resource has been shared. This mechanism has been implemented since 2022 and it works very well.

I don't think there would a philosophical problem of using the user's storage for cache, as long as these data are kept private, and can only be seen by the user (and the applications that have been granted interop:All right on the given resource).

Alternative

The alternative could be to cache data in the local browser. But on the first load or when using a new device, the performances would still be terrible. Will users be ready to wait several minutes for an application ? Most likely they will leave before.

Another problem with local cache is that the browser cannot know if a resource has been updated so to have fresh data, it will still need to query ALL data. This can be done in the background, but that will have bad impact on the server and I don't think it's such an elegant solution.

No files, tests, or implementation entry points are named. Start by reviewing the existing ActivityPods cache and its ActivityPub UPDATE mechanism, then define how a separate private container would store shared resources and support filtering and ordering; done means the cache remains private, stays current after updates, and can serve the described queries.