MSC4319: Room member events for invite and knock rooms in the /sync response

[zecakeh]

Rendered

This was spawned by the discussion in matrix-org/matrix-spec#2181.

Server Implementations:

• Synapse:
  • Own non-stripped m.room.member in invite_state: https://github.com/element-hq/synapse/blob/458e6410e8388fbc6b60b5575850405939bc53eb/synapse/rest/client/sync.py#L450-L462
  • Stripped inviter's m.room.member in invite_state: https://github.com/element-hq/synapse/blob/a6e326582f735e03e420c3b86475388fb5f2656c/synapse/handlers/message.py#L1835-L1839
  • Own non-stripped m.room.member in knock_state: https://github.com/element-hq/synapse/blob/458e6410e8388fbc6b60b5575850405939bc53eb/synapse/rest/client/sync.py#L486-L514
  • Add the state key to invite and knock rooms: Add state key to invite and knock rooms in sync response for MSC4319 element-hq/synapse#19330
• Dendrite:
  • Own non-stripped m.room.member in invite_state: https://github.com/element-hq/dendrite/blob/8d2da78744387e55c28bb8925ae0cc70dd3e02e3/syncapi/types/types.go#L530-L574
  • Does not seem to add the inviter in invite_state.
  • Does not have support for knock_state.
• Conduit (and forks):
  • Own stripped m.room.member in invite_state (common to all forks): https://gitlab.com/famedly/conduit/-/blob/ed5b0514f52f848e53785dee5fe8de63780cf092/src/api/server_server.rs#L2160-2172
  • Stripped inviter's m.room.member in invite_state (Conduit): https://gitlab.com/famedly/conduit/-/merge_requests/766
  • Own non-stripped m.room.member in knock_state (Conduit): https://gitlab.com/famedly/conduit/-/blob/ed5b0514f52f848e53785dee5fe8de63780cf092/src/api/server_server.rs#L2160-2172

Most clients already rely on being able to access the m.room.member events of the knock or invite process, and of the inviter.

The following client implementations also rely on being able to access the origin_server_ts:

• Cinny: https://github.com/cinnyapp/cinny/blob/67b05eeb09c8019fc67564f65ebca3d4b37653c6/src/app/pages/client/inbox/Invites.tsx#L88
• Neochat: https://invent.kde.org/network/neochat/-/blob/c5caffcdf9b250eb5a6c57a40ab951fa188563d1/src/libneochat/neochatroom.cpp?page=2#L1661

This client implementation supports the new state key:

• Ruma: Update support for MSC4319 ruma/ruma#2322

---

SCT Stuff:

MSC checklist

FCP tickyboxes

[zecakeh]

There are implementations for the latest state of the MSC in:

• Synapse: Add state key to invite and knock rooms in sync response for MSC4319 element-hq/synapse#19330
• Ruma: Update support for MSC4319 ruma/ruma#2322

[turt2live]

MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands.

SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable.

MSC authors: feel free to ask in a thread on your MSC or in the#matrix-spec:matrix.org room for clarification of any of these points.

• Are appropriate implementation(s) specified in the MSC’s PR description?
• Are all MSCs that this MSC depends on already accepted?
• For each new endpoint that is introduced:
  • Have authentication requirements been specified?
  • Have rate-limiting requirements been specified?
  • Have guest access requirements been specified?
  • Are error responses specified?
    • Does each error case have a specified errcode (e.g. M_FORBIDDEN) and HTTP status code?
      • If a new errcode is introduced, is it clear that it is new?
• Will the MSC require a new room version, and if so, has that been made clear?
  • Is the reason for a new room version clearly stated? For example, modifying the set of redacted fields changes how event IDs are calculated, thus requiring a new room version.
• Are backwards-compatibility concerns appropriately addressed?
• Are the endpoint conventions honoured?
  • Do HTTP endpoints use_underscores_like_this?
  • Will the endpoint return unbounded data? If so, has pagination been considered?
  • If the endpoint utilises pagination, is it consistent with the appendices?
• An introduction exists and clearly outlines the problem being solved. Ideally, the first paragraph should be understandable by a non-technical audience.
• All outstanding threads are resolved
  • All feedback is incorporated into the proposal text itself, either as a fix or noted as an alternative
• While the exact sections do not need to be present, the details implied by the proposal template are covered. Namely:
  • Introduction
  • Proposal text
  • Potential issues
  • Alternatives
  • Dependencies
• Stable identifiers are used throughout the proposal, except for the unstable prefix section
  • Unstable prefixes consider the awkward accepted-but-not-merged state
  • Chosen unstable prefixes do not pollute any global namespace (use “org.matrix.mscXXXX”, not “org.matrix”).
• Changes have applicable Sign Off from all authors/editors/contributors
• There is a dedicated "Security Considerations" section which detail any possible attacks/vulnerabilities this proposal may introduce, even if this is "None.". See RFC3552 for things to think about, but in particular pay attention to the OWASP Top Ten.

[turt2live]

This proposal looks ready for broader SCT review, at priority 2:

@mscbot fcp merge

[mscbot]

Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people:

• @clokep
• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @tulir
• @erikjohnston
• @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.