MSC3217: Soft kicks #3217
MSC3217: Soft kicks #3217
Conversation
Half-Shot
added
proposal
|
|
||
| Given Matrix is designed to be as bridge / remote network friendly as possible while also | ||
| being privacy preserving, it's imperative that we support this use case. | ||
|
|
There was a problem hiding this comment.
Another alternative we should mention is that we could have a different mechanism (e.g. an EDU) to alert clients that it's safe to try to rejoin after being soft-kicked. This would be lighter weight than re-inviting them into the room (no need to write to DAG, doesn't result in doubling the reentry traffic as people go from invite to join). The same EDU could also be used to inform users when a bridge in a room is unavailable (e.g. due to freezing traffic for privacy reasons, or due to the bridge crashing) - i.e. bridge presence. So: "when the bridge says that its presence is available again, clients should try to rejoin the rooms they've been soft-kicked from".
Another alternative could be to let users be force-joined into rooms by whoever soft-kicked them (at the expense of needing a new room version).
There was a problem hiding this comment.
What if these EDUs arrive at users' clients when the bridge is crashing again, though?
| - If the client receives an invite from the user who soft-kicked them, it should autojoin | ||
| the room without prompting. |
There was a problem hiding this comment.
TL;DR: Autojoins could be a abused to test presence of a device.
This might be overly paranoid, but I see that this could be used to test if a user has active devices by soft-kicking them and re-inviting.
Do we have similar recommendations of automatic, non-interactive client-actions already?
Just the knowledge of an active device that has processed the message also isn't likely to be confidential – and those who need the privacy hopefully run a paranoid client.
There was a problem hiding this comment.
Maybe the auto rejoining could be an option in clients? That would address the privacy concerns for those users.
| reasons and the | ||
| current state doesn't allow the client to accurately reflect that. Most clients present a kick | ||
| as a "hard" action where you can no longer see the history of the room and the language | ||
| describes it as a forced removal. |
There was a problem hiding this comment.
Do they? I know Element does it (and I think it's a bad idea because the user has the chat history anyways, so why hide it?), but I haven't checked the others. Suppose all the clients changed their behavior on this, would this RFC still provide a benefit?
| @@ -0,0 +1,91 @@ | |||
| # MSC3217: Clientside hints for a soft kick | |||
There was a problem hiding this comment.
I encountered https://github.com/matrix-org/matrix-doc/issues/3537 while reading the spec on some ambiguity, I believe that that issue is related to the intentions of this MSC, as the leave memberships would most likely not be included in an initial sync (which is the defacto case in synapse at the moment)
Rendered
Implementations:
Co-written with @ara4n