Subscription proxying
We want to allow a server to forward notifications to another server.
To reach this objective, with @sylvain @alexbourlier, we think of an Subscription Proxy which would forward any notification entering it to every of its subscribers.
After some specifications investigation, it looks that we don't need this approach, instead we could extend LDN with ActivityPub - The same way we're doing it for backlinks - leading to this scheme:
Implementation side, we already use the ActivityQueueService to send LDN-compliant notifications, we're only missing the "Subscribe to /inbox/" part.
Two solutions:
- Use the global
/inbox/
of the server, but each server will have only one endpoint for "all of its relays" - Add a new model to manage inbox of each containers -
/job-offers/inbox/
for example - and plug the subscription part on it
Second one is more compliant to the AP specification and feels cleaner.
Some implementation sharing the approach: pub-relay, Activity-Relay, Mobilizon do it natively.
Notice that it's the same system that's used for end user notification and for activities within a federation on Mastodon. On our system, those federation activities are the "backlinks" and we're already compliant.
Sources: LDN spec, social-web-protocols spec, ActivityPub followers collection, .
Old accounting Protocol