I’m a little bit confused by:
Federated servers MUST perform delivery on all Activities posted to the outbox according to outbox delivery.
The following is required by federated servers communicating with other federated servers only.
I understand it like this:
if only C2S is implemented, then there is no delivery between actors.
And that sounds strange, doesn’t it? Why should there be no delivery without federation?
If the client is a stateful actor, and different servers are providing different specific capabilities (ex: a calendar, a budget planner, a sleep tracker), then having a Client that successfully interoperates with each Server without having to implement a different REST API means the client is free to choose other methods to interact with the outside world – it could be ActivityPub federation (in which the “C” in C2S could also be the “S” in S2S or only federating public calendar view of the actor, the “S” in C2S also being the “S” in S2S) or something else.
This C2S thinking was the original impetus for ActivityPub, and S2S was the second thought. Which is inverted to today’s landscape.
ok, that sounds exciting. Maybe the view of activityPub is a bit different for all of us. I plan to implement an activityPub server and not a server that “only” speaks activityPub. That’s probably what makes it so complicated for me. So I want to cover as many useCases as possible on the server and not specialise. and if there are things that are not possible, the server should be extendable.
For now, I think I will handle each new activity in each servers outbox in a federated way and also do the http delivery for actors, that are on the same server.
If Jane@serverA sends a message to her followers and her followers collection contains 100 Actors from serverB, so serverB receives 100 HTTP Request? Or did I read something over?
Yep. There’s a solution available in the form of sharedInbox but that breaks the Actor model.
I will mark a received activity as “already received” and manage the internal delivery myself. Do you see any problems? I would then only actually process one http request and ignore others.