[WIP] MSC1228: Removing MXIDs from events #1228
Conversation
turt2live
added
the
requires-room-version
|
Related: matrix-org/matrix-spec#220 |
|
make it clear that the global->room user ID mapping in the join event is optional |
|
In https://matrix.to/#/!QtykxKocfZaZOUrTwp:matrix.org/$15554460481373RDcFM:ericmartindale.com?via=matrix.org&via=half-shot.uk&via=linuxgaming.life, martindale suggested looking into W3C DID for decentralised accounts. |
|
This would also make it possible to rename user-ids on deactivation: matrix-org/synapse#5949 |
| 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 |
There was a problem hiding this comment.
@martindale suggests: Public keys should not be revealed until the first message is sent; use a hashed value instead.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
@martindale suggests: ed25519 doesn't support hierarchical keys; recommend secp256k1 instead
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
@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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Some debate over this at https://docs.google.com/document/d/1ni4LnC_vafX4h4K4sYNpmccS7QeHEFpAcYcbLS-J21Q/edit?disco=AAAAB3zzaso, but everybody apart from me seemed to think we should, and on re-reading, I think I agree.
|
|
||
| * Invite and join events include: | ||
|
|
||
| * `mxid_mapping`: field which gives the user's `@user:server` mxid and which |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
turt2live
changed the title
turt2live
added
the
needs-implementation
|
|
||
| * It looks like `^Noi6WqcDj0QmPxCNQqgezwTlBKrfqehY1u2FyWP9uYw`. | ||
|
|
||
| * Homeservers are responsible for making up user keys for their users. They |
There was a problem hiding this comment.
| * 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`. |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
User room IDs and keys are specific to that room, hence they are versioned by the room version.
There was a problem hiding this comment.
The root key of the user is not, hence that needs to be versioned separately.
There was a problem hiding this comment.
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 [email protected]
| 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.
This comment was marked as resolved.
Sorry, something went wrong.
|
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! |
|
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. |
| * 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. |
There was a problem hiding this comment.
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 duplicate.
This comment was marked as off-topic.
This comment was marked as off-topic.
Rendered
(this supercedes an earlier Google Docs version of the same proposal)