MSC3995: [WIP] Linearized Matrix #3995
Conversation
turt2live
added
requires-room-version
turt2live
changed the title
|
|
||
| This architecture ends up looking something like this: | ||
|
|
||
|  |
There was a problem hiding this comment.
These diagrams need a legend
| sign the object twice. During validation, if the domain implied by the `sender` matches the `hub_server`, | ||
| do not expect an LPDU signature. | ||
|
|
||
| ### Redaction algorithm changes |
There was a problem hiding this comment.
MSC2176 also protects content.invite on m.room.power_levels
| * The [event auth API](https://spec.matrix.org/v1.6/server-server-api/#get_matrixfederationv1event_authroomideventid) is | ||
| supported. | ||
|
|
||
| * [Joins](https://spec.matrix.org/v1.6/server-server-api/#joining-rooms), [invites](https://spec.matrix.org/v1.6/server-server-api/#inviting-to-a-room), |
There was a problem hiding this comment.
Joins in particular are ugly for a LM implementation:
- There's a bunch of fields the hub doesn't know or care about
- The participant server needs to know who the hub server is before they create a join event (see this and this)
- The participant can't deal with a
/send_joinresponse that isn't the linearized DAG, which is problematic - The same "participants can't hash their own events" stuff applies here too (the join can be rewritten)
- Overall, the join steps feel like they're too DAG-driven to make sense in a LM world
| * The [event auth API](https://spec.matrix.org/v1.6/server-server-api/#get_matrixfederationv1event_authroomideventid) is | ||
| supported. | ||
|
|
||
| * [Joins](https://spec.matrix.org/v1.6/server-server-api/#joining-rooms), [invites](https://spec.matrix.org/v1.6/server-server-api/#inviting-to-a-room), |
There was a problem hiding this comment.
Likely a future MSC, but we need to define how a LM participant server discovers the hub server without an invite (ie: joining a public room)
| * The [event auth API](https://spec.matrix.org/v1.6/server-server-api/#get_matrixfederationv1event_authroomideventid) is | ||
| supported. | ||
|
|
||
| * [Joins](https://spec.matrix.org/v1.6/server-server-api/#joining-rooms), [invites](https://spec.matrix.org/v1.6/server-server-api/#inviting-to-a-room), |
There was a problem hiding this comment.
Invites for m.linearized servers need to route through the current room's hub
| they persist rooms (they continue using a DAG). | ||
|
|
||
| * **Hub**: A server which accesses the room using a linked list on behalf of other *participant* servers. | ||
| This server can be DAG-capable, but does not need to be. |
There was a problem hiding this comment.
Having given this a quick read, this line really confused me from a language perspective. I see that a hub server may or may not also be a DAG-capable server, but for clarity I would keep the roles separate and say something like:
| This server can be DAG-capable, but does not need to be. | |
| A single server can be both a hub server and a DAG-capable server, but does not need to be. |
There was a problem hiding this comment.
Sorry, I'm struggling to parse the concern and suggestion here. The text is already keeping the roles separate and being clear which role ("DAG-capable") is optional? The suggestion feels like it's saying the hub server doesn't need to be a hub server, at least.
| a future change will introduce a different style of 3rd party invite. Clients and users of unstable Linearized | ||
| Matrix should avoid triggering Rule 4.4.1 or Rule 6. | ||
|
|
||
| The full set of changes are: |
There was a problem hiding this comment.
We also need to prevent the last user from the hub leaving until the hub transfers, somehow. We do not however want to prevent bans from happening, which means we might need a force-transfer mechanism?
| The [auth events selection algorithm](https://spec.matrix.org/v1.6/server-server-api/#auth-events-selection) | ||
| is additionally changed. Currently the selection algorithm is roughly the same for all room versions, but the | ||
| changes here will bring it formally into the room version specification. A new condition is added to state that | ||
| any event with a `hub_server` top level field must reference the `m.room.hub` state event (if any). |
There was a problem hiding this comment.
also the m.room.hub should reference the previous m.room.hub event, if any.
|
|
||
| ## Proposal | ||
|
|
||
| ### Room structure |
There was a problem hiding this comment.
This MSC states that it wants to support a multi-hub model, but goes on to describe what a single (or canonical) hub model looks like, including hub transfers and associated auth rules. A major security issue with a canonical hub model is it's possible to splitbrain the room fairly easily: just ban/kick the hub server from the room. This could be done with ACLs or kicking/banning all of the hub server's users from the room.
An obvious counter to this might be to require that the last user from the hub server can't be removed from the room (ie: they can't leave, and can't be banned), and that server ACLs do not apply to the canonical hub, however this raises yet another security issue: the hub server is now given the green light to spam the room to death because it can't be removed. Further, a malicious server could trigger a hub transfer to itself and start spewing spam.
Or, we'd somehow allow the hub server to participate in the room when it's not actually a member, but that becomes difficult to track for fanout purposes. Specifically, every server which is in the room needs to be aware of this out of band server, and that server still can't be ACL'd from the room because it'll cause a rift in the room.
Instead, if we actually adopt a multi-hub model then the ACLing concerns largely disappear, assuming we add some heuristics on how to pick a fallback hub when all the hubs are banned. It doesn't seem right to allow a server to participate in the room out of band, so we'd still be ensuring that participants talk to a hub that's actually joined to the room.
To identify hubs in this model, servers would look for m.room.hub state events with state keys being domain names of those servers. The domain implied by the sender must match the state key. Normal state event sending rules apply as well: this allows rooms to define "trusted" or "preferred" hubs by only allowing room admins to send m.room.hub state events. A server would be considered a participant (for fanout purposes) if it advertises m.linearized: true on /key/v2/server and is not a listed m.room.hub in the room.
For heuristics when there's no m.room.hub state events in the room, or when they're all banned in some way, we'd rely on power levels and finally the room creator. If a user with explicit power level (ie: not users_default) has enough power to send m.room.hub state events, including considerations for state_default and events_default, then those user's servers are eligible hubs. If no such users exist, or the servers are no longer members of the room, then the server implied by the room creator is used as a hub. If that server is no longer in the room (or banned), then any of the remaining servers in the room can be assumed to be a hub server.
Note: I'm fairly sure there's a case in here where there's just no communication between servers, but will work that out as part of incorporating into the MSC.
We'd also stick a flag in the content on the m.room.hub event to denote whether it's "current", to handle cases where the hub server no longer wishes to be a hub server. This flag would not be protected by redaction so that the hub can opt-out even if it no longer has power in the room by having the sender self-redact (though power levels can prevent this too: maybe we special case it, or accept that sometimes hubs can't opt-out?)
There was a problem hiding this comment.
I think the heuristics in particular need work, but the general aim is to ensure there's at least 1 hub in the room for the participant servers.
Part of the idea behind LM is you're theoretically able to implement a participant-only homeserver, though maybe we give up on that idea and instead require implementations to act as hub and participant, eliminating the concerns of not having a single hub (the fallback would be "become a hub" rather than "find a hub algorithmically"). However, that also takes us a step closer to just implementing state res considering that would be the only thing farmed out to a DAG-capable server, and all the LM servers would be federating through DAG-level fanout.
| but does preserve all other fields as per MSC2176. | ||
| * `hub_server` at the top level is newly protected. | ||
|
|
||
| ### Auth rule changes |
There was a problem hiding this comment.
We should also talk about how rejection works. Currently in the I-D we assume that we can just not append the event, but is that realistic?
| events appropriately. | ||
|
|
||
| This model provides fully decentralized communications as a feature to Matrix, a feature we'd like to keep, | ||
| however is complex when aiming to adopt Matrix as an interoperable chat protocol, such as with the emergence |
There was a problem hiding this comment.
This sections seems extremely incomplete. The MSC implies that the current model is too complex for adopting as an interoperable protocol; but it fails to specify why that is. Where does this complexity lie, in what ways does it pose a problem for this usecase, and what makes this a problem of the protocol rather than of the implementers?
Given the context, this seems like a crucial thing to specify, and it's odd that a proposal (even if a draft) has been written without specifying that upfront; it seems like putting the cart before the horse. Government regulation is often an opportunity to force unwilling parties to implement something that they would rather not, but that would be beneficial to society as a whole, precisely because they are enforced regulations and you do not need to rely on economic motivations.
I feel like such a situation applies here as well; the DAG model of Matrix is a crucial part of its resiliency (towards both technical outages and misbehaving participant servers), and while it is complex to implement correctly, I feel that it is nevertheless important to maintain these properties. Therefore, if the proposal is to weaken these properties, then it should really be supported by a considerable stronger rationale than the current implied "large tech corps don't like it".
| @@ -0,0 +1,530 @@ | |||
| # MSC3995: Linearized Matrix | |||
There was a problem hiding this comment.
Readers: This MSC is based on the 01 and some of the 02 drafts within the IETF. It does not reflect the 03 draft.
Rendered (recommended)
Implementations:
⚠⚠ This is not considered final and might change dramatically. This MSC exists to show what we're thinking about, but is not representative of the final proposal.