From 39dc514477b92696509f1b0e6991b2f6a7d9262f Mon Sep 17 00:00:00 2001 From: gnuxie Date: Tue, 9 Sep 2025 16:23:07 +0100 Subject: [PATCH 1/4] Portable and serverless accounts in rooms. --- proposals/xxxx-portable-accounts-in-rooms.md | 141 +++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 proposals/xxxx-portable-accounts-in-rooms.md diff --git a/proposals/xxxx-portable-accounts-in-rooms.md b/proposals/xxxx-portable-accounts-in-rooms.md new file mode 100644 index 00000000000..a5950ad6c95 --- /dev/null +++ b/proposals/xxxx-portable-accounts-in-rooms.md @@ -0,0 +1,141 @@ +# MSC0000: Portable and serverless accounts in rooms + +This MSC is a more ambitious an adaptation of [MSC4243: User ID +localparts as Account +Keys](https://github.com/matrix-org/matrix-spec-proposals/pull/4243) +for [MSC4345: Server ky identity and room +membership](https://github.com/matrix-org/matrix-spec-proposals/pull/4345) +that achieves the follow up goals immediately and securely. + +The following is a quote from MSC4244: + +> User IDs should be public keys because: +> - User IDs as they are today are direct personal data. For [GDPR](https://github.com/matrix-org/matrix-spec/issues/342) +> reasons we would like to be able to remove direct personal data from the immutable append-only DAG. This proposal +> replaces user IDs with indirect personal data. +> - As user IDs are user controlled, spammers set their localpart to abusive messages in order to harass and intimidate others. Redactions +> do not remove the user ID so these messages persist in the room. + +In addition to the above, we go further and remove the server from user ID's completly: + +This is desirable because: + +- Portable snd serverless accounts accounts are now native to this new room model. +- Psuedo identity is supported in the room model for servers and room + admins that wish to immediately implement it. +- Servers can immediately be implemented as relays for P2P clients. +- Within the context of MSC4345, the server key can be rotated without + effecting users or the room. + +## Proposal + +- User ID's in rooms are replaced with an ed25519 public key: + an "Account Key". Leaving and rejoining the same room MUST NOT + change the account key. The account key is encoded as unpadded + urlsafe base 64. An example user ID is: + `@l8Hft5qXKn1vfHrg3p4+W8gELQVo8N13JkluMfmn2sQ` + +- The private key for this account key signs the event JSON over + federation. The event is then cosigned by a participating server + under the terms of + [MSC4345](https://github.com/matrix-org/matrix-spec-proposals/pull/4345). + Just like MSC4243, network requests are not required to verify the + signature of inbound events as all public keys are available in the + DAG. + +- Unlike + [MSC4243](https://github.com/matrix-org/matrix-spec-proposals/4243), + no endpoint or network requests are needed for servers or clients to + verify server ownership over an account, as all events are co-signed + by the room scoped server key. This is both a security and + consistency enhancement. + +### Chanages to room events + +Events must always be sent with the account key user ID. + +### Changes to room membership + +Room membership must use the account key user ID as the `state_key`. + +### Obtaining account and profile information as a server + +We use the same `POST /_matrix/federation/v1/query/accounts` endpoint +from MSC4243, with the exception that the requested server must verify +that the requesting server is participating in common rooms to those +of the queried account key. + +### Obtaining account and profile information as a client + +The account name is annotated in `unsigned.account`. This is the +account name only and not the account name user ID. + +The domain can be found from MSC4345's `unsigned.server_domain`. + +## Potential issues + +### Rotation of account keys + +It's not clear how we can rotate account keys without a server +attesting to a rotation. + +### Profile information in the DAG + +How can we remove profile information from the DAG. The goal is +opposite to the goal of MSC4345 in DAG reproducibility, in an E2EE +context, you don't want that for profile information. + +It's not clear either whether this property is also desirable for +public rooms, and that you want an account's cosigning server to +provide this information instead. I believe it likely is desirable for +the profile information to be mostly ephemeral,because people's lives +change. + +### Backwards incompatibility of user ID's + +The change to user ID's is backwards incompatible, there isn't +avoiding this. We believe even MSC4243 will have to make this change +in the future to enable the same behaviour's in a consistent way. + +## Alternatives + +### MSC4243: User ID localparts as Account Keys + +[MSC4243: User ID +localparts as Account +Keys](https://github.com/matrix-org/matrix-spec-proposals/pull/4243) provides +the prior work for this MSC and much of the inspiration. + +The difference is MSC4243 takes an interative approach towards +portable identity without exploring its implications or making the +changes necessary to facilitate it. MSC4243 also requires use of a +policy server in order to keep the room secure, whereas this proposal +does not, as we depend upon MSC4345 server participation to provide us +security from malicious keys and malicious backfill. + +## Security considerations + +### User accounts can move servers + +Users that were resident to denied servers can migrate their account +to servers that are participating in the room. We assess this is +acceptable because we expect completing the same registration +requirements on the new server as they would with a brand new user +account will be required to migrate an account. + +We expect servers with weak registration requirements or setup for the +use of ban evasion will be identified and removed as they are +currently. However, with the security enhancements of MSC4345, such +servers can no longer join rooms unanticipated. So we have an +advantage. + +## Unstable prefix + +- The endpoint `/_matrix/federation/v1/query/accounts` is + `/_matrix/federation/v1/query/org.matrix.0000.accounts + +## Dependencies + +- [MSC4345: Server ky identity and room +membership](https://github.com/matrix-org/matrix-spec-proposals/pull/4345) +is a dependency From 5ebc7d1f05b17ae25e857f841d027e2e277cc9ea Mon Sep 17 00:00:00 2001 From: gnuxie Date: Tue, 9 Sep 2025 16:25:23 +0100 Subject: [PATCH 2/4] typos. --- proposals/xxxx-portable-accounts-in-rooms.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/xxxx-portable-accounts-in-rooms.md b/proposals/xxxx-portable-accounts-in-rooms.md index a5950ad6c95..ddd53482979 100644 --- a/proposals/xxxx-portable-accounts-in-rooms.md +++ b/proposals/xxxx-portable-accounts-in-rooms.md @@ -16,12 +16,12 @@ The following is a quote from MSC4244: > - As user IDs are user controlled, spammers set their localpart to abusive messages in order to harass and intimidate others. Redactions > do not remove the user ID so these messages persist in the room. -In addition to the above, we go further and remove the server from user ID's completly: +In addition to the above, we go further and remove the server from user ID's completely: This is desirable because: - Portable snd serverless accounts accounts are now native to this new room model. -- Psuedo identity is supported in the room model for servers and room +- Pseudo identity is supported in the room model for servers and room admins that wish to immediately implement it. - Servers can immediately be implemented as relays for P2P clients. - Within the context of MSC4345, the server key can be rotated without @@ -50,7 +50,7 @@ This is desirable because: by the room scoped server key. This is both a security and consistency enhancement. -### Chanages to room events +### Changes to room events Events must always be sent with the account key user ID. @@ -106,7 +106,7 @@ localparts as Account Keys](https://github.com/matrix-org/matrix-spec-proposals/pull/4243) provides the prior work for this MSC and much of the inspiration. -The difference is MSC4243 takes an interative approach towards +The difference is MSC4243 takes an iterative approach towards portable identity without exploring its implications or making the changes necessary to facilitate it. MSC4243 also requires use of a policy server in order to keep the room secure, whereas this proposal From 5e14c362de65387384dcded2aecf26ad7108a3c5 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Tue, 9 Sep 2025 16:26:34 +0100 Subject: [PATCH 3/4] MSC4348 --- ...ccounts-in-rooms.md => 4348-portable-accounts-in-rooms.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename proposals/{xxxx-portable-accounts-in-rooms.md => 4348-portable-accounts-in-rooms.md} (98%) diff --git a/proposals/xxxx-portable-accounts-in-rooms.md b/proposals/4348-portable-accounts-in-rooms.md similarity index 98% rename from proposals/xxxx-portable-accounts-in-rooms.md rename to proposals/4348-portable-accounts-in-rooms.md index ddd53482979..a20f1afc995 100644 --- a/proposals/xxxx-portable-accounts-in-rooms.md +++ b/proposals/4348-portable-accounts-in-rooms.md @@ -1,4 +1,4 @@ -# MSC0000: Portable and serverless accounts in rooms +# MSC4348: Portable and serverless accounts in rooms This MSC is a more ambitious an adaptation of [MSC4243: User ID localparts as Account @@ -132,7 +132,7 @@ advantage. ## Unstable prefix - The endpoint `/_matrix/federation/v1/query/accounts` is - `/_matrix/federation/v1/query/org.matrix.0000.accounts + `/_matrix/federation/v1/query/org.matrix.4348.accounts ## Dependencies From 860518bfe88b3a6078d583ab32002446dccb409a Mon Sep 17 00:00:00 2001 From: gnuxie Date: Tue, 9 Sep 2025 16:35:46 +0100 Subject: [PATCH 4/4] Make differences clearer. --- proposals/4348-portable-accounts-in-rooms.md | 33 ++++++++++++++++---- 1 file changed, 27 insertions(+), 6 deletions(-) diff --git a/proposals/4348-portable-accounts-in-rooms.md b/proposals/4348-portable-accounts-in-rooms.md index a20f1afc995..3219d149084 100644 --- a/proposals/4348-portable-accounts-in-rooms.md +++ b/proposals/4348-portable-accounts-in-rooms.md @@ -106,12 +106,33 @@ localparts as Account Keys](https://github.com/matrix-org/matrix-spec-proposals/pull/4243) provides the prior work for this MSC and much of the inspiration. -The difference is MSC4243 takes an iterative approach towards -portable identity without exploring its implications or making the -changes necessary to facilitate it. MSC4243 also requires use of a -policy server in order to keep the room secure, whereas this proposal -does not, as we depend upon MSC4345 server participation to provide us -security from malicious keys and malicious backfill. +The differences between this and is MSC4243 are + +- MSC4243 takes an iterative approach towards + portable identity without exploring its implications or making the + changes necessary to facilitate it. + +- MSC4243 requires use of a policy server in order to keep the room + secure, whereas this proposal does not, as we depend upon MSC4345 + server participation to provide us security from malicious keys and + malicious backfill. + +- Because MSC4243 takes an iterative approach, the User ID format does + not need to change. This provides the argument that the MSC is + non-breaking. But the reality is different because of the security + implications that the MSC imposes on clients and servers. We believe + that the MSC still imposes breaking changes on clients that interact + with power levels and also moderation. It also mandates changes in + clients to ensure that unverified users are shown in a safe way. + +- MSC4243 embeds the domain into the account key user ID, which always + allows for that information to be faked at the DAG level. Clients + must be protected by servers from this with consideration to replace + User ID's in client formatted events. This likely will be a + complicating factor for that MSC when events interact with the power + level and access control mechanism of the room. + + ## Security considerations