MSC2666: Get rooms in common with another user

[Half-Shot]

Rendered

Author: @Half-Shot, @ShadowJonathan

Implementations:

• Synapse: Update Mutual Rooms (MSC2666) Implementation synapse#15621 + Implement pagination for MSC2666 element-hq/synapse#19279
• Ruma: Update Mutual Rooms (MSC2666) implementation ruma/ruma#1547
• JS SDK: Update Mutual Rooms (MSC2666) support matrix-js-sdk#3381

Click to reveal Legacy Implementations

• matrix-react-sdk PR: Show rooms in common with another user matrix-react-sdk#4897
• matrix-js-sdk PR: Add _unstable_getSharedRooms matrix-js-sdk#1417
• Synapse (Went through a few iterations)
  • Add /user/{user_id}/shared_rooms/ api synapse#7785
  • Rename shared_rooms to mutual_rooms synapse#12036
  • Remove mutual_rooms update_user_directory check, and add extra documentation synapse#12038
  • Mutual rooms: Remove dependency on user directory synapse#12836

---

SCT stuff:

FCP tickyboxes

MSC checklist

[turt2live]

Overall this doesn't feel like it needs to be an endpoint.

[Half-Shot]

Hello 5 years later 👋

element-hq/element-web#30654 is an implementation that finally uses this information, so could be used as an example of an implementation.

EDIT: I'm also told that many clients have since started using this endpoint, so that comment is mostly moot :)

[tulir]

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.

[tulir]

This has been mostly ready for over 2 years and with element-hq/synapse#19279, everything should be implemented as well

@mscbot fcp merge

[mscbot]

Team member @tulir 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.

[Johennes]

Given that at least some of the foreseen use cases involve presenting the rooms in common to a user, would there be any benefit in including more than just the room ID here? As a drastic example, could the endpoint use the same response format as /publicRooms, for instance?

[tulir]

I don't think any of the client implementations so far have needed extra information. By definition the client is in all the rooms and most likely already has the room state (excluding member list). AFAIK even with sliding sync clients will get the entire room list fairly quickly

[Johennes]

Ok, that sounds sensible. I was just curious and nothing in the proposal seems to touch upon why the response is not richer or more extensible.