MSC4014: Pseudonymous Identities #4014
Open
+73
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
turt2live
added
requires-room-version
ara4n
reviewed
May 10, 2023
turt2live
changed the title
ara4n
reviewed
May 11, 2023
| ##### 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
Draft
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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