MSC3953: Server capability DAG #3953
Conversation
turt2live
added
requires-room-version
| 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.
Rendered
Signed-off-by: Gnuxie Gnuxie@protonmail.com