Discussion about extending #ActivityPub C2S vs non-AP protocol to support keys residing client-side and not on server.
Was an accidental property of a proposal to keep separate business logic synchronized between two instances.
Also I'm writing walls of text. Soon I'll be writing full-length position papers.
@cj I'm still reading through the thread, but I'm feeling like there's a confusion at the root of the problem.
The users B and C send C2S Activity requests to their specific outboxes on their specific servers. Their servers federate the Activity to the inbox belonging to the Actor that owns the collection on server A. If the federation request fails for any of the servers, it's up to them how they inform the generating actor.
Maybe I'm missing some finer points, but I don't understand why the Activity on the servers B and C outboxes need to be identical to what can be found in the inbox of server A?
They are different entities, and they can exist independently from eachother.
Maybe thinking about the problem in email terms, would help:
I can send an email from my server, (I have it in my Sent) but on the destination server it can be bounced, marked as spam, etc. and it's not going to exist in an Inbox.
@mariusor That's not the key point that I got from this particular developer. The root cause is trying to generate an activity on server A that triggers specific side effects affecting data on server B. So the typical flow of "generate activity A, federate S2S everywhere that this is occurring" doesn't work since B needs to do the actual processing and pass/fail it.
Having A 1:1 S2S the activity to B, and then B triggering the mass-federation with its Activity after the side-effects have taken place doesn't work: How do people verify B isn't spoofing A and just "making stuff up" and pretending A told it to do that?
Hence, B needs to be able to send an activity that is massively S2S federated, and the general population need to be able to verify the integrity (B's signature), linked-data ownership (IRI deref + B signature) and non-impersonation (A signature)
@mariusor Also, having A mass-S2S its Activity (including B) in order to trigger B doesn't work: what if B needs to be able to reject it due to race conditions, constraints, other business logic? Everyone else is out of sync thinking A did something, when B didn't.
@cj ugh, I think I'm lost already between A/B as servers actors. :(
In the simplified model I have about these interactions I still don't understand why there's a problem. Actor B posts to outbox instance B (authenticated somehow). Instance B federates to server A's inbox (using actor B's private key that server A verifies when receives the Activity) and everybody is happy. (?! aren't they)
@cj in the scenario presented actor B is already known to server A (because he's a "moderator" whatever that means) so their key doesn't even need to be dereferenced.
Is the problem related to instance to instance (S2S) message authentication?
@mariusor Your previous message almost had it. Actor A is the one trying to get its Server A to tell Server B to do specific application logic without creating an account on Server B and locally triggering the action there.
So Server B has a forge or data and Actor A on Server A is a moderator who wants to send Activities to Server B to do things. But it is Server B that needs to federate different Activities out to indicate the changes without implying it is spoofing Actor A.
This is expressable in ActivityStreams vocab. A posts a Create Activity, the object of which is the Create Activity for B to process. This asserts A has made a request without asserting that B has Accepted it. B can Accept or Reject, directly or Tentatively. If B processes the Create, the Create from A can be referenced as origin. For Activities where target and origin aren't normally defined, naive implementations should pass them through
Umm, the context attribute seems semantically correct for this, rather than origin
@yaaps Is this all under S2S? I'm going to assume so...
"This asserts A has made a request without asserting that B has Accepted it."
I disagree. If A has a Create C1 wrapping a Create C2, the `id` on C2 and it's objects cannot be known to A until B actually processes C2's normal side effects. So any signing A does on C1 won't match the C2 actually created by B. Doubly so if B adds new properties or modifies the requested C2 or it's objects in any way.
This is why I prefer C2S
@yaaps Since C2S is set up to be an actual request-based system, whereas S2S is designed for peer-based system. C2S gives the S side authority to modify the incoming Activity before distribution. Adding `id` etc. Doing that in an S2S environment would break fundamental assumptions IMO.
If your point was about C2S and not S2S, then such double layer wrapping isn't needed anyway since the C side can directly request a Create.
You are correct about my error. The delineation between the S2S and C2S is in the ActivityPub spec proper, which I start implementing tomorrow. Treating this interaction as C2S is semantically correct and less verbose
I think that the context attribute provides the necessary mechanism to demonstrate that there was a properly signed request when the original signature no longer applies. Thoughts?
@yaaps I don't consider it an error just a different option. When it comes to the tech detail I would defer to you since it sounds like you're going to implement it very soon, and 'context' does sound appropriate.
I did make a mistake in that I was focused on the (minimal) semantic differences between AP C2S and S2S. When you post to an outbox, it's C2S. The semantics of the payload differ mainly in that C2S is more permissive
Servers need AP C2S for core functions like allowing Person Actors to post to a Remote Group. This is in addition to my long-running discourse about failing to use C2S for local clients generally breaking functionality that would be available if they naively relayed AP through their inboxes to connecting clients
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!
We adhere to an adapted version of the TootCat Code of Conduct and follow the Toot Café list of blocked instances. Ash is the admin and is supported by Fuzzface, Brian!, and Daniel Glus as moderators.
Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!