Description
In SAI, users are supposed to watch, with webhooks, the reciprocal Social Agent Registration of all their contacts. This allows them to know when a new resource has been shared with them. Eventually they will then create/regenerate a Delegated Data Grant for all the apps that have requested access to the same type of resource.
On my local ActivityPods Pod provider, I host 500 users. Since these users have had a lot of interactions, we can assume that each one of them has an average of 50 connections to other users. This means that there are 500 x 50 = 25'000 connections to manage.
To watch if one of their contact has shared a resource with them, the server needs to create a webhook Solid Notification channel for each of these connection. This means creating 25'000 Solid Notifications channels.
For security reasons, we also need to have a unique URL for every receiving webhook. In ActivityPods, we keep track of this unique URL with a custom Webhook resource. So we need 25'000 of these resources as well.
This means we have to create 50'000 resources just to keep track of the communication between our 500 users. And I consider this as a small server.
But creating the Solid Notifications webhook channel is not all ! In a multi-host environment, we must also deal with the case when the server of the sender or recipient goes down. Should the Solid notification channel or webhook be deleted? In fact, the server must continually ensure that the communication channel stays open between the users. If it fails, then users may miss some important update.
Alternative
With ActivityPub, you have one way to communicate with any user: their inbox.
No need to pre-establish a webhook connection beforehand.
Security is guaranteed by HTTP signature.
If a Social Agent Registration has been updated, a single activity can be sent to notify about the update:
{
type: "Update",
actor: "https://mypod.store/alice",
object: "https://mypod.store/alice/path/to/social-agent-registration",
to: "https://mypod.store/bob"
}
The server could even be more direct and notify about the DataGrant that has been created (
Create > interop:DataGrant). This way, the recipient doesn't need to go through the whole Social Agent Registration to find what new data grant has been shared. We would not need to deal with all these immutable data, that are great in theory, but difficult to manage.