Conversation
turt2live
added
requires-room-version
There was a problem hiding this comment.
Implementation requirements:
- Server (supplying)
- Client (using)
- Moderation bot (using)
Appservice (using)Not affected - see MSC4428: Stable identifiers for Room Members #4428 (comment)
turt2live
added
application services
needs-implementation
| Clients MUST use the new `unsigned.stable_id` field as the stable ID. | ||
| Clients MUST NOT use the `sender` field of events as the stable ID. | ||
| A later room version **may remove the `sender` field entirely** on events, | ||
| which would break any client relying on the `sender` field for the stable ID. | ||
| For this reason, clients MUST handle the case where the `sender` is missing (it is Optional). |
There was a problem hiding this comment.
Wouldn't it make more sense to sign the stable id by including it in sender and provide the mapping to the mutable part as unsigned.user_id? It would lead to trouble if the sender isn't signed so I don't see why we want to remove it.
There was a problem hiding this comment.
It would lead to trouble if the sender isn't signed so I don't see why we want to remove it.
I agree. I'm not proposing that we remove the event signature from sender over federation. I am suggesting that this field may change over the client-server API as per "The purpose of this MSC is primarily to introduce a Client-Server mechanism to communicate that the sender is now mutable.".
I will clarify this though since I agree it reads poorly at present.
There was a problem hiding this comment.
Still, I think having the stable id under unsigned seems silly and makes it look like untrusted data.
There was a problem hiding this comment.
Fair point, if we only add the stable ID to a new room version then it can be a top-level field.
| Rather than add `unsigned.stable_id`, we could remove the `sender` and replace it with a `stable_id` field. | ||
| We would do this so in the future if clients do not implement stable IDs they would crash due to the `sender` field not existing, | ||
| rather than parsing the `sender` as a user ID when it is in fact a stable ID. | ||
| This change would be backwards incompatible (as we'd be removing `sender`) so clients would need to opt-in e.g. via a query parameter `?stable_ids=1`. |
There was a problem hiding this comment.
The problem with this proposal in my mind seems to stem from the fact that it is trying so hard to change the semantics of, remove or rename sender even for previous room versions while remaining backwards compatible. I don't think that's a good idea as it'll just lead to confusing behavior between clients that do support this and those that don't.
There was a problem hiding this comment.
The proposed change in isolation is backwards compatible because the stable ID is the sender. If something like MSC4430 lands then yes, this would become a breaking change.
The intent is for:
- clients to be able to become aware of stable IDs
- any client which remains unaware of stable IDs will not see rooms that rely on stable IDs (MSC4430). This mechanism isn't fully fleshed out beyond "filter them out from the sync API".
There was a problem hiding this comment.
It would still have effects on previous rooms:
- If a user is erased, supporting clients will see an "anonymous user" while clients without support will still see the user id. Additionally, deanonymization is as simple as viewing the event source (so, pointless).
- This also allows for changing a user's localpart with the caveat that it is still tied to their old one. Clients without stable id support wouldn't see that change either.
If this mechanism is reserved for rooms with MSC4430 or another proposal that depends on this instead, there would be no disagreements.
There was a problem hiding this comment.
Right, I see your point now.
The rationale for adding backwards compat for earlier room versions is:
- it allows erasure to be expressed in existing room versions (even if it is imperfect)
- it makes it easier for clients to implement support as they can use any room and
/deactivatea user.
I'm not sure these reasons are strong enough to justify the risk of clients disagreeing on the sender of an event in existing rooms. If erasure wasn't trivial to circumvent that would help, but it isn't.
Maybe it would be better to only apply this on a new room version then,
| We could repurpose the `sender` field as the stable ID. This is backwards compatible. | ||
| However, this changes the data type depending on the room version: the `sender` is either a User ID *or* a Stable ID (public key). | ||
| This is particularly concerning for stable ID aware clients, as in order for them to know how to | ||
| parse the `sender` field they either need to figure out the room version (which is fragile as it needs to be kept updated) |
There was a problem hiding this comment.
I think this is preferable. We have room versions for a reason.
We shouldn't expect clients to be able to fully participate in room versions that they haven't been updated to support.
There was a problem hiding this comment.
Room versions primarily exist for servers, not clients.
That being said, it's not a particularly strong arguement because it's a leaky abstraction e.g. clients have to implement the redaction algorithm to know how to process redaction events, they need to know if the room supports creator power levels.
I agree that the lack of a strong way to express room version support in clients does cause friction. I don't think this is the MSC to fix it though. If such a mechanism existed already though, I would use it in this MSC.
I think some resistance also comes from the fact that out of the 12 room versions we have today, only a small subset of them actually required client changes. This means you could be prevented from participating in a room simply because the client author did not add an extra number to the allowed room versions array.
|
Great proposal as a stepping stone towards homeserver mobility and ephemeral user IDs. |
6 participants
Rendered