Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] MSC1228: Removing MXIDs from events #1228

Draft
wants to merge 2 commits into
base: old_master
Choose a base branch
from

Conversation

richvdh
Copy link
Member

@richvdh richvdh commented Oct 14, 2019

Rendered

(this supercedes an earlier Google Docs version of the same proposal)

@ara4n ara4n added the proposal A matrix spec change proposal label May 15, 2018
@turt2live turt2live added the requires-room-version An idea which will require a bump in room version label Sep 6, 2018
@turt2live
Copy link
Member

Related: matrix-org/matrix-spec#220

@ara4n
Copy link
Member

ara4n commented Mar 11, 2019

make it clear that the global->room user ID mapping in the join event is optional

@uhoreg
Copy link
Member

uhoreg commented Apr 16, 2019

@rubo77
Copy link

rubo77 commented Sep 1, 2019

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
Copy link
Member Author

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.

Copy link
Member Author

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.
Copy link
Member Author

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

Copy link
Member Author

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
Copy link
Member Author

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?

Copy link
Member Author

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
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member Author

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.
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for clarifying!

@turt2live turt2live changed the title Removing MXIDs from events MSC1228: Removing MXIDs from events Oct 18, 2019
@turt2live turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021

* It looks like `^Noi6WqcDj0QmPxCNQqgezwTlBKrfqehY1u2FyWP9uYw`.

* Homeservers are responsible for making up user keys for their users. They
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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`.
Copy link

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.

Copy link

@erkinalp erkinalp left a comment

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

proposals/1228-removing-mxids-from-events.md Show resolved Hide resolved
proposals/1228-removing-mxids-from-events.md Show resolved Hide resolved
proposals/1228-removing-mxids-from-events.md Show resolved Hide resolved
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.

@turt2live turt2live mentioned this pull request Mar 1, 2022
6 tasks
@grahhnt
Copy link

grahhnt commented May 21, 2022

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!

@trymeouteh
Copy link

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.

@initpwn

This comment was marked as duplicate.

@neilalexander neilalexander removed their assignment Jan 19, 2023
@xxfogs

This comment was marked as off-topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal requires-room-version An idea which will require a bump in room version
Projects
None yet
Development

Successfully merging this pull request may close these issues.