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.

[ShadowJonathan]

Current Status

With #4035, I have applied a lot of changes that will need a new unstable_features tag. However, I want this discussion to be resolved first before I go ahead and do that.

After that, implementations need to be updated to match, and only then will I request FCP again.

[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.