Skip to content

MSC3953: Server capability DAG#3953

Closed
Gnuxie wants to merge 13 commits intomatrix-org:mainfrom
Gnuxie:gnuxie/capability-dag
Closed

MSC3953: Server capability DAG#3953
Gnuxie wants to merge 13 commits intomatrix-org:mainfrom
Gnuxie:gnuxie/capability-dag

Conversation

@Gnuxie
Copy link
Copy Markdown
Contributor

@Gnuxie Gnuxie commented Jan 7, 2023

Rendered

Signed-off-by: Gnuxie Gnuxie@protonmail.com

@Gnuxie Gnuxie changed the title MSC0000: Server capability DAG MSC3953: Server capability DAG Jan 7, 2023
@turt2live turt2live added requires-room-version An idea which will require a bump in room version proposal A matrix spec change proposal s2s Server-to-Server API (federation) room-spec Something to do with the room version specifications unassigned-room-version Remove this label when things get versioned. kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Jan 7, 2023
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.
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@Gnuxie
Copy link
Copy Markdown
Contributor Author

Gnuxie commented Dec 11, 2025

This MSC is now superseded by a new approach with MSC4345: Server key identity and room membership

@Gnuxie Gnuxie closed this Dec 11, 2025
@turt2live turt2live added the obsolete A proposal which has been overtaken by other proposals label Dec 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. obsolete A proposal which has been overtaken by other proposals proposal A matrix spec change proposal requires-room-version An idea which will require a bump in room version room-spec Something to do with the room version specifications s2s Server-to-Server API (federation) unassigned-room-version Remove this label when things get versioned.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants