Conversation
| If we take this view, then what happens to user membership? | ||
| In order to keep users out of the auth dag, their membership has to be treated as entirely virtual. | ||
| Servers that possess membership, and also possess the capability to send events therefore will | ||
| also have the authority to send events with any sender local part. |
There was a problem hiding this comment.
So some initial feedback provided by @FSG-Cat & Nyaaori (not on Github) is that the MSC is still too focused on the sender local part and the concept of senders. As a result the proposal still leans towards / is coupled to current ideas about how to represent users and room members, and it is desirable to leave this open to interpretation at this point.
As a result, it has been suggested that an origin field be added to the top level of PDUs. Granted this is provided from the transactions endpoint, but while backfilling servers currently have to infer the origin from the sender.
| - We don't provide clear semantics for user level bans or attenuation of their capabilities | ||
| - What is the process for transferring a capability to a user via a server from the perspective | ||
| of a client? | ||
| - This is a pretty big breaking change, no client is equipped to deal with this, |
There was a problem hiding this comment.
I believe that it is possible to proxy this room version to clients without changing the client server api depending on how you implement users/members in a dependent MSC, even if sender is removed from the top level of PDUs. Still stands that it probably isn't desirable to emulate the existing behavior and it would just complicate things.
| @@ -0,0 +1,410 @@ | |||
| # MSC3953: Server capability DAG | |||
There was a problem hiding this comment.
This can be seen almost as the opposite of MSC4014 because 4014 demotes the importance of servers in the protocol to merely routing information, and instead it's entirely cryptographic keys all the way down to identify users. I think I prefer that to this proposal.
|
This MSC is now superseded by a new approach with MSC4345: Server key identity and room membership |
Rendered
Signed-off-by: Gnuxie Gnuxie@protonmail.com