MSC4104: Auth Lock: Soft-failure-be-gone! #4104
Conversation
Gnuxie
changed the title
We need to say explicitly that all `m.auth_lock` events that have been created that match the `auth_event` are considered.
It's allowed because servers will still retain the history and an admin can easily recanonicalise the state so that joining servers can see the relevant history again.
turt2live
added
requires-room-version
| The receiving server must combine the `extremities` from both events | ||
| such that the canonical history becomes C -> B -> A. |
There was a problem hiding this comment.
What if Alice sees Chelsea send B -> A but Bob sees C -> A instead, because Chelsea crafted two extremities from the same event, delivering one to Alice's HS and the other to Bob's HS?
There was a problem hiding this comment.
This is a better example. However, provided Bob receives Alice's m.auth_lock, then Bob would reject any further events sent by Chelsea referencing A or C. Bob could also send their own m.auth_lock referencing Chelsea's prior membership that includes C within extremities. Then Alice will be able to pull in C when Alice gets Bob's m.auth_lock. Alice could then redact C.
Though this presents another problem when Bob is unprivileged and can't send m.auth_lock. The reason why we give bob the capability to send m.auth_lock is because we trust that he will observe and apply Alice's m.auth_lock and not leak more of Chelsea's events to us. And this means he's most likely already a room admin. This is a problem that already exists that soft failure doesn't prevent either element-hq/synapse#9329. It would be nice to find some kind of solution.
There was a problem hiding this comment.
Maybe negotiation of extremities could to considered separately, such that servers with unprivileged users could propose them and room admins could preview them and choose to accept or reject them. That does feel a little bit like over engineering for and entrenching a bad state of affairs though. But at least it's something that would work.
There was a problem hiding this comment.
Also, I should probably clarify somewhere in the proposal that we don't propose eagerly issuing an m.auth_lock with every ban, we simply do not soft fail anymore. If we then see events being authorized that would have normally been candidates for soft failure, the room admin or their tooling would then issue m.auth_lock. In principle, this should reduce the number of instances where element-hq/synapse#9329 occurs.
There was a problem hiding this comment.
negotiation
I'm forgetting that a server can ask for the prev_events, find the diverged extremity provide a preview to an admin and allow them to choose incorporate it, all without manual intervention from another server (other than continuing to participate)
There was a problem hiding this comment.
@dkasak I have rewritten the potential issues section to try cover this concern and all the solutions that I have discovered so far
| We counteract this issue by requiring that servers maintain all | ||
| existing `extremities` and their `prev_events`, regardless of | ||
| whether they are missing from the `extremities` field of | ||
| an `m.auth_lock` event. |
There was a problem hiding this comment.
But what is "existing" at the point of receipt of the m.auth_lock event could differ across different servers participating in the room. Wouldn't this strategy lock them into having diverging views of the room?
There was a problem hiding this comment.
No, because users on those servers can issue their own m.auth_lock events for the same locked_event_id, which would allow them to converge again. Am I understanding this correctly as the same problem described in the second paragraph of https://github.com/matrix-org/matrix-spec-proposals/pull/4104/files#r1494856367 ?
| @@ -0,0 +1,204 @@ | |||
| # MSC4104: Auth Lock: Soft-failure-be-gone! | |||
There was a problem hiding this comment.
I'm finding the proposal very hard to understand, and there seems to be some deal breakers in the potential issues section, like being able to lock all auth events and effectively locking the room..?
I suggest adding diagrams for each scenario to explain what is going on.
I am very interested in a solution better than soft failure, so if I can understand this proposal better than maybe this is something we can work with. However, the scenarios presented here make it seem like this is not the final form of this proposal.
There was a problem hiding this comment.
However, the scenarios presented here make it seem like this is not the final form of this proposal.
It isn't, the MSC is still draft.
I'm finding the proposal very hard to understand
Is there a way to improve this outside of diagrams for the scenarios in the potential issues section?
I am very interested in a solution better than soft failure
Me too but I no longer know if this is the right approach
There was a problem hiding this comment.
Diagrams for normal operations would help too! Diagrams are great.
As of yesterday I think I now have an idea of how we can do away with soft fail, but I need to check various scenarios and think more on the performance implications. The gist is CALM theorem + state resolve literally all events.
There was a problem hiding this comment.
CALM theorem
I'm unfamiliar with CALM, is this the best resource to explain what this is?
Rendered
Signed-off-by: Gnuxie Gnuxie@protonmail.com