[WIP] MSC1228: Removing MXIDs from events by richvdh · Pull Request #1228 · matrix-org/matrix-spec-proposals (original) (raw)
Conversation
(this supercedes an earlier Google Docs version of the same proposal)
yangm97, martindale, Mikaela, swedneck, MazeChaZer, eras, digitalcircuit, cyphar, aaronraimist, MayeulC, and 38 more reacted with thumbs up emoji martindale, Mikaela, swedneck, MazeChaZer, anoadragon453, JochenFriedrich, ptman, aWeinzierl, RotationMatrix, Thatoo, and 11 more reacted with heart emoji
This was referenced
Feb 13, 2019
make it clear that the global->room user ID mapping in the join event is optional
| available for reference at |
|---|
| https://docs.google.com/document/d/1ni4LnC\_vafX4h4K4sYNpmccS7QeHEFpAcYcbLS-J21Q#heading=h.y1krynr6itl4.\] |
| * Each user (currently identified by an mxid) will also have a `user_key`. In |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@martindale suggests: Public keys should not be revealed until the first message is sent; use a hashed value instead.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem with a hash is that it requires a separate mechanism to distribute the actual key; and I'm not sure how we would control access to that key. If I want to start a conversation with a given user, I need their public user_key: what is to say that I should or should not be permitted it?
| * A `user_key` is represented like `~1:dV3hr3yE9SxhsWEGBJdTho777S8ompkJTh`, |
| where `1:` is a version (to allow other systems to be used in future) and |
| the rest is an (unpadded urlsafe-base64ed) ed25519 public key. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@martindale suggests: ed25519 doesn't support hierarchical keys; recommend secp256k1 instead
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's worth noting that we use ed25519 heavily elsewhere in the protocol. Are the advantages of secp256k1 worth the overhead of introducing a separate set of crypto primitives?
| * zero or one verified mxid mappings. |
|---|
| * zero or one incomplete mxid mappings. |
| We extend the CS API to include a `verified_sender_mxid` field on any events |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ara4n says: Whilst i think we should have this present by default to aid stupid clients, should we provide the option to filter it out for clients which know they are smart enough to learn mappings from the async mapping bit of the sync response instead?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my reply: maybe? I'm not sure the added complexity is worthwhile just to remove a field from some JSON which you could otherwise ignore.
| We also add a **new** field to the `/sync` response which tells clients about |
|---|
| mxid mappings as they are resolved. |
| Question: should we remove unverified mxid mappings from join events before |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| * Invite and join events include: |
| * `mxid_mapping`: field which gives the user's `@user:server` mxid and which |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in time, the intention is to replace the mxid with simply a server name.
| The stretch goal is to also remove the association with server names, since for |
| many users, they are the only user on a server and it is reasonable to be able |
| to ask for the removal of any history of `sw1v.org`'s involvement with a room. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At now each homeserver have own unique namespace via domain suffix, this prevent from duplicates in federation for user and room id's. But if we replace them to random keys without domain suffix - how we can prevent making duplicated keys by some homeservers (not only collisions, but also manually created dupilcates on some "evil" homeservers)? Homeserver can't check for duplicates in all federated servers before create key, and after creating keys - it will be too late for change it.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to sign the create event with the key, so you can only use a given public key as a room ID if you have the private key; in essence, you're asking for someone to break curve25519.
The curve25519 keyspace is 2^256, so for a 50% chance of a collison somewhere within the entire space of matrix rooms, we'd need about 10^38 rooms (see https://en.wikipedia.org/wiki/Birthday_attack). That's a huge number.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarifying!
Removing MXIDs from events MSC1228: Removing MXIDs from events
| * It looks like `^Noi6WqcDj0QmPxCNQqgezwTlBKrfqehY1u2FyWP9uYw`. |
| * Homeservers are responsible for making up user keys for their users. They |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| * Homeservers are responsible for making up user keys for their users. They |
|---|
| * Homeservers are responsible for making up user room keys for their users. They |
| * Room IDs also become ed25519 public keys. |
| * They look like: `!Sr_Vj3FIqyQ2WjJ9fWpUXRdz6fX4oFAjKrDmu198PnI`. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do user keys get to have versions, yet user room IDs and user room keys do not? (Sorry if this doesn't make sense, this is pretty much my first interaction with the spec and I came from one of the blog posts)
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
User room IDs and keys are specific to that room, hence they are versioned by the room version.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The root key of the user is not, hence that needs to be versioned separately.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use ed448 as the number of rooms encountered in a single federation may be greater than 2¹²⁸-1
Signed-off by: Erkin Alp Güney erkinalp9035@gmail.com
Comment on lines +12 to +15
| The general idea presented here is to use a pseudomym in many places where we |
|---|
| currently use user IDs. The current `@user:server` then becomes a user alias; |
| the mapping between alias and the psuedonumous ID is public but can be removed |
| in the future. |
This comment was marked as resolved.
Hi, is this proposal still being worked on? Planning to move my community to using Matrix and not having the ability to rename an account is a notable issue for us. Thanks!
rubo77, mildred, owl-from-hogvarts, RainerKlute, orpheuslummis, 0x416c69, soulmerge, RokeJulianLockhart, RasheedAZ, perdakovich, and 6 more reacted with thumbs up emoji
Would this allow for 12 or 24 seed phrases? This way a P2P account will not have a username and password to backup but a seed phrase which can also be used to generate multiple mxids for privacy, allow a different mxid for every public room and contact a users communicates with.
Cryptocurrencies use seed phrases to generate multiple public addresses and private keys, this approach can essentially merge Monero like privacy into Matrix, allowing a user to have multiple mxids for every conversation and room they are in.
Comment on lines +51 to +53
| * For now, each homeserver maintains a one-to-one mapping between |
|---|
| `user_key` and mxid for each of their users. In future, we will look to |
| break this link to allow portability of accounts. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A side note: I imagine that older versions of the CS API, for example, would show the mxid in the fields they're in right now to avoid breaking older clients that rely on parsing an ID (to get just the name or server) for whatever reason.
This comment was marked as duplicate.
This comment was marked as off-topic.
This file contains hidden or 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
[ Show hidden characters]({{ revealButtonHref }})
Reviewers
+8 more reviewers
Reviewers whose approvals may not affect merge requirements