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 label May 15, 2018
@turt2live turt2live mentioned this pull request Aug 14, 2018
1 of 6 tasks
@turt2live
Copy link
Member

@turt2live turt2live commented Sep 28, 2018

Related: #778

@ara4n
Copy link
Member

@ara4n 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 uhoreg commented Apr 16, 2019

In https://matrix.to/#/!QtykxKocfZaZOUrTwp:matrix.org/$15554460481373RDcFM:ericmartindale.com?via=matrix.org&via=half-shot.uk&via=linuxgaming.life

matrix.to Remove

The Official Matrix HQ - please come chat here! | https://matrix.org/docs/spec | To support Matrix.org development: https://patreon.com/matrixdotorg | Looking for hosting? Check out https://upcloud.com/matrix!

, martindale suggested looking into W3C DID for decentralised accounts.

@rubo77
Copy link

@rubo77 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

This comment has been minimized.

@richvdh

richvdh Oct 14, 2019
Author Member

@martindale suggests: Public keys should not be revealed until the first message is sent; use a hashed value instead.

This comment has been minimized.

@richvdh

richvdh Oct 14, 2019
Author Member

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.

This comment has been minimized.

@richvdh

richvdh Oct 14, 2019
Author Member

@martindale suggests: ed25519 doesn't support hierarchical keys; recommend secp256k1 instead

This comment has been minimized.

@richvdh

richvdh Oct 14, 2019
Author Member

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

This comment has been minimized.

@richvdh

richvdh Oct 14, 2019
Author Member

@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?

This comment has been minimized.

@richvdh

richvdh Oct 14, 2019
Author Member

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

This comment has been minimized.

@richvdh

richvdh Oct 14, 2019
Author Member

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.

@turt2live turt2live changed the title MSC1228: Removing MXIDs from events [WIP] MSC1228: Removing MXIDs from events Dec 7, 2019
@neilalexander neilalexander self-assigned this Feb 11, 2020
We could change this to:

* inviting server builds a partial invite event
* inviting server PUTs to `/_matrix/federation/v3/invite/<event_id>/<target_mxid>` on invited server

This comment has been minimized.

@grinapo

grinapo Feb 11, 2020
Contributor

Excuse me asking but it is not completely clear to me how the inviting server knows which is the invited server?

Either we invite someone by knowing his/her user_key (which isn't associated to any server) or the mxid (which is similarly isn't associated to any server, and any similarity between the postfix label and homeserver names are purely coincidental), in any case if the user never have joined any locally known room then we seem not to have any knowledge about his/her whereabouts, of in fact, existence.

Global lookup systems (like DHT) are usually used to look up the location of a cryptographically identified resource in distributed networks (or get a negative response of non-existence after a timeout) but as far as I know we don't have that.

(I feel a slight similarity to the room_id problem, eg. joining a room by not using an alias, where we're supposed to know or figure out one or more originating servers.)

This comment has been minimized.

@uhoreg

uhoreg Feb 13, 2020
Member

My understanding is that we are still going to have mxids of the form @ localpart:servername, and if you move servers, then you would get a new servername (and possible different localpart), and all your room mappings would be updated. So the servername part of your mxid will always be the server that you're contacted at. If you've moved servers, then I guess your old server should return an error code if someone tries to talk to you (maybe even including a forwarding address).

Question: should we remove unverified mxid mappings from join events before
serving them to the clients, to stop client developers relying on it and
breaking everything?

This comment has been minimized.

@uhoreg

uhoreg Feb 26, 2020
Member

We may need to give details on how to use the user keys to find user devices and device keys in order to do e2e.


### Examples

`m.room.create`: signed by both the room key and the `user_room_key` of the

This comment has been minimized.

@ara4n

ara4n May 10, 2020
Member

we haven't defined "room key" at this point - might be better to call it the room ID's key?


For now we do the same thing (ie, make an attempt to verify the mxid
mappings in the join events we receive, and time them out quickly). In
future we might optimise this so the the mappings are verified lazily.

This comment has been minimized.

@ara4n

ara4n May 10, 2020
Member

@richvdh how would this work in practice? are you suggesting that you reject events from the DB in retrospect having lazily verified the mapping, and send these to events as redactions of some kind?

@ShadowJonathan
Copy link
Contributor

@ShadowJonathan ShadowJonathan commented Sep 3, 2020

Some feedback to the use of Curve25519 keys; has the usage of multihash been considered somehow? Or some combination of a CID key, or a Linked-data Key that can be used for this purpose?


* It looks like `^Noi6WqcDj0QmPxCNQqgezwTlBKrfqehY1u2FyWP9uYw`.

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

This comment has been minimized.

@runiq

runiq Jun 12, 2021

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`.

This comment has been minimized.

@runiq

runiq Jun 12, 2021

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)

This comment has been minimized.

@erkinalp

erkinalp Jun 12, 2021

User room IDs and keys are specific to that room, hence they are versioned by the room version.

This comment has been minimized.

@erkinalp

erkinalp Jun 12, 2021

The root key of the user is not, hence that needs to be versioned separately.

Copy link

@erkinalp erkinalp left a 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 erkinalp9035@gmail.com

@@ -0,0 +1,327 @@
# MSC1228: Removing MXIDs from events

This comment has been hidden.

@erkinalp

erkinalp Jun 15, 2021

Title change suggested, as this is not limited to user identifiers:

Suggested change
# MSC1228: Removing MXIDs from events
# MSC1228: Identifiers revamp

Signed-off by: Erkin Alp Güney erkinalp9035@gmail.com

This comment has been minimized.

@neilalexander

neilalexander Jun 15, 2021
Member

Might be worth noting that MSC2787 is supposed to supersede MSC1228.

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.
Comment on lines +12 to +15

This comment has been hidden.

@erkinalp

erkinalp Jun 15, 2021

Suggested change
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.
The general idea presented here is to use a pseudoynm in many places where we
currently use user IDs. The current `@user:server` then becomes a user alias;
the mapping between alias and the psuedonymous ID is public but can be removed
in the future.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment