MSC4267: Automatically forgetting rooms on leave

[Johennes]

Rendered

Fixes: matrix-org/matrix-spec#447

---

In line with matrix-org/matrix-spec#1700, the following disclosure applies:

I am a Systems Architect at gematik, Software Engineer at Unomed, Matrix community member and former Element employee. This proposal was written and published with my gematik hat on.

---

SCT Stuff:

FCP tickyboxes

MSC Checklist

[turt2live]

Implementation requirements:

• Client
• Server

[Johennes]

Server: element-hq/synapse#18196

[Johennes]

Client: matrix-org/matrix-js-sdk#4732

[x86pup]

conduwuit server implementation:
x86pup/conduwuit@35981d5
x86pup/conduwuit@c8a730c

[t3chguy]

I got hung up on this naming. m.leave_implicit_forget or m.leave_auto_forget maybe? Leave without forget sounds like its doing the opposite of

Therefore, servers that
auto-forget rooms MUST advertise that they do so via an m.leave_without_forget
capability.

[Johennes]

Yeah, the current naming is a bit odd. I was thinking of the capability as "I can leave a room without forgetting it" but that makes it reciprocal to auto-forgetting rooms on the server.

You could also think of it inversely like in your suggestion as "I can leave and forget a room in one operation". My only concern with this was that when the capability is enabled, a client actually has less choice. It's not actually that you can leave and forget in one operation but rather that you must.

Maybe I'm just overthinking it though. 😵‍💫

[t3chguy]

m.forget_forced_upon_leave maybe?

[Johennes]

I like that. It's not reciprocal and expresses the coercion aspect. 👍

[ara4n]

it's a bit clunky though - how about just m.forced_forget?

[kegsay]

My only concern is that we may be unduly confident because Synapse has had the config option forget_rooms_on_leave for a long time now. The problem is it defaults to false, so I would like to hear from some people who have been using that option successfully.

[ara4n]

This looks very sensible to me, fwiw. I don't think we need further proof of implementation between 2x servers, given it's also pretty trivial to envisage how it'd work; I suggest we FCP it.

[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 MSC has been proposed as ready for FCP by the author. The next steps are for an SCT member to review it and the implementation to make the determination if it's ready for FCP, then propose FCP.

[turt2live]

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

[richvdh]

I guess this is fine, but: do we have actual evidence of the forget_rooms_on_leave setting causing client-side brokenness? I'm slightly wondering if this is a non-issue, and we can just say that servers can forget rooms when they want.

[richvdh]

In fact: I assume the main problem is that clients which do choose to offer a "historical rooms" section with "forget" buttons don't know which rooms to list in the historic section (because they don't know whether those historic rooms have been "forgotten").

In which case, I don't really think this solves the problem. Doesn't exactly the same problem occur if a user has two clients, and chooses to forget some rooms on one of them?

It feels like maybe we need a special section of (incremental) syncs which lists rooms that have been forgotten since the previous sync.

[Johennes]

I think there are two problems in the current spec:

1. A client has no way to know if the server auto-forgets on leave or not. As a result, it cannot be sure whether or not it should display any of its related UI, such as a "forget" button.
2. The act of forgetting rooms doesn't propagate automatically across multiple clients. As a result, clients that do support historical rooms, currently need to perform initial syncs once in a while to determine the current set of forgotten rooms.

This proposal only tries to address 1 while I think your comment aims at 2. I think both should be fixed but I don't think one fixes the other?

[richvdh]

My thinking was that servers that auto-forget rooms on leave would send out the same notification that a room had been forgotten as when another client did the forgetting.

Presumably clients only show a "forget" button on rooms that have been left but not yet forgotten (a list that would always be empty on servers with auto-forget), so a "forgotten" notification in /sync could solve both problems.

[Johennes]

First of, I think a mechanism for communicating forgotten rooms via incremental sync would be great. We should definitely do this.

I believe some UI usages would still require the capability from this proposal though. A client might want to:

• simultaneously display buttons for "leave" (/leave) and "leave & forget" (/leave followed by /forget)
• offer a setting to toggle what a single "leave" button does (/leave followed or not followed by /forget)
• explain the finality or non-finality of a single "leave" button before issuing a /leave (e.g. in a tooltip or dialog)
• display the empty "historical rooms" view or section alongside some documentation explaining what it is or how it'll be populated

I think these would not be possible or result in confusing UX if the client cannot determine the server's auto-forget behaviour ahead of time?

[richvdh]

fair enough; if those are real use-cases desired by clients, then I can't argue against a capability for it. Could you add them to the doc so that we know what we're trying to fix (and, as importantly, what we're not fixing)?

[Johennes]

I have tried to capture it in 1771d76. Thanks for raising this.

To be honest, I have no evidence that these (or any other forget-related) use cases are particularly strong. The concept of differentiating left and forgotten rooms might be confusing or superfluous to begin with and maybe it shouldn't exist in the spec. However, I think the two problems we discussed above make it hard for clients to actually use this feature and experiment with its UX to then verify what's needed.

[KitsuneRal]

As a client author I wouldn't mind if we didn't even distinguish between left and forgotten rooms on the client side; simplifying the UX and making it clear at least for some servers is the next best thing.
(The "historical rooms" thing effectively never worked right, beyond of the "oh shucks I left the wrong room let me quickly rejoin it" case.)

[anoadragon453]

I agree with the other comments on this MSC that historical rooms is still a confusing topic in the Matrix spec. Nevertheless, this change is an improvement to the status quo.

[mscbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[Johennes]

Spec PR: matrix-org/matrix-spec#2292