MSC4014: Pseudonymous Identities #4014
Conversation
turt2live
added
requires-room-version
turt2live
changed the title
| ##### Addressing the "Problems" section in MSC1228 | ||
| - The state keys in the room aliases event is unimportant since v6 rooms removed them from the specification. | ||
| - matrix.to links remain as they are, with the `via=` params formed using verified mxid mappings. | ||
| - Redacting an `m.room.member` event should not remove the `mxid_mapping` field in the case where the `displayname` or `avatar_url` is malicious. In order to remove the `mxid_mapping` field (e.g for PII removal), the account in question should be deactivated or the room in question should be "purged", which would cause the mapping to be removed. This more severe form of redaction has side-effects as deleting the `mxid_mapping` potentially alters routing information as that user may be the last user in the room for that server, and hence should not be triggered by a CSAPI `/redact` call. How this functions at a protocol level is undetermined at this point. The redaction algorithm will remain the same for the purposes of signing events / hashes (so the `mxid_mapping` is removed in this case). This implies 2 kinds of redaction for `m.room.member` events. |
There was a problem hiding this comment.
This doesn't sound good - shouldn't we allow users to remove the mxid_mapping of their messages without deactivating their account or nuking the room?
There was a problem hiding this comment.
The semantics are unclear here. If you remove the mxid mapping you not only remove routing information but you effectively are no longer part of the room in that E2EE will break as other users won't know your user ID, which has ramifications beyond PII removal. If we allow clients to remove the mxid mapping then this is roughly equivalent to leaving the room, in which case just do that?
kegsay
changed the title
kegsay
removed
the
needs-implementation
Considering that matrix-org/matrix-spec#246 has stagnated, is this proposal still being considered? What is missing to get this into the spec and into the servers? |
|
It needs an implementation in Synapse, and then thorough testing, as well as SCT review of the proposal itself. |
Rendered
Server impl in Dendrite:
Clients can join pseudo ID rooms with no changes if they are already using a compatible Dendrite server. This is the public pseudo ID room:
!FMyU3BBTFJ0j2Ab0:dendrite.matrix.org