MSC4348: Portable and serverless accounts in rooms #4348
Conversation
Gnuxie
changed the title
Gnuxie
changed the title
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Server
- Complement tests
| - 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. |
There was a problem hiding this comment.
We need to be clear about whether servers do own accounts or whether participating in the room from multiple servers at the same time is possible.
There was a problem hiding this comment.
It seems like there would be no way to enforce this other than through a change in membership otherwise
|
|
||
| The domain can be found from MSC4345's `unsigned.server_domain`. | ||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
I'd like someone to talk to me about E2EE in the context of this MSC because I actually have no idea how tf E2EE already works on Matrix.
| - Within the context of MSC4345, the server key can be rotated without | ||
| effecting users or the room. | ||
|
|
||
| ## Proposal |
There was a problem hiding this comment.
We need to specify how precisely the server co-signs the event that has first been signed by the account key. And how this interacts with authorization rules, event creation, and room creation.
| - Portable snd serverless accounts accounts are now native to this new room model. | ||
| - 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. |
There was a problem hiding this comment.
This isn't necessarily true. There are situations where MSC4345 would require cooperation from an account key.
| ### 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. |
There was a problem hiding this comment.
This implies that the membership event of a user needs explicitly tying to the co-sigining server's participation, and if either the co-singing server key or the account key are revoked, then the membership event cannot be used to authorize events.
I think that it is ok for a new membership event to be created with the same account key co-signed by a new server.
2 participants
Rendered
Signed-off-by: Gnuxie [email protected]