MSC4193: Spoilers on Media

[88572]

Rendered

Implementations:
mautrix/discord#189 (mautrix's matrix to discord bridge)
cinnyapp/cinny#2212 (cinny)

---

SCT Stuff:

No FCP proposed.

MSC checklist

[girlbossceo]

org.matrix is reserved for matrix.org, so you'll need to use something like your own domain for the unstable prefix.

[88572]

I've updated it to my Codeberg Pages site.

[clokep]

Usually it is fine to use org.matrix in a MSC if you'd like. Just include the MSC # in it.

[girlbossceo]

I would just clarify what this alternative does and the limitations of it.

From my brief look at it, it uses Matrix HTML to create an interactive/clickable dropdown to view the image.

The limitation of this compared to the MSC would be that not all clients implement HTML, and HTML on mobile clients isn't very good. Additionally this requires a multi-step process of copying the media URL / MXC URI and running this external tool, and most likely doesn't work in encrypted rooms.

[88572]

I've added a note about the limitations.

[turt2live]

Implementation requirements:

• Client sending spoilers
• Client respecting spoilers

[gingershaped]

Cinny now both respects and supports sending spoilered images. (cinnyapp/cinny#2212)

[Johennes]

The existing spoilers work on all message types that support formatted_body and org.matrix.custom.html.

To send spoilers clients MUST use the formatted_body and therefore the org.matrix.custom.html format, described above. This makes spoilers valid on any msgtype which can support this format appropriately.

Since 1.10 images actually fall into that category, too, through their media captions.

So with this proposal it's now possible to have an image itself be behind a spoiler with its caption behind another spoiler. This made me wonder if we'd need some form of UI guidance on how to treat this situation? For instance, should the spoilers be revealed together or separately?

[88572]

I'd say that spoilers should be done separately.

[tcpipuk]

I'd imagine most people would want to configure each separately, as the caption may tell people what is inside the image to help them know whether they want to view it?

[Johennes]

That sounds sensible and I think c1e9fb4 has addressed it accordingly.

[sumnerevans]

#3725 also provides a way to do spoilers on media.

[88572]

I added a note about that.

[gingershaped]

I noticed while adding support for this MSC in Cinny that it does not allow for m.video messages to be spoiled. Is this an intentional omission?

[88572]

Sorry, that was an accidental omission on this one's fault. Videos can be spoiled, however the example event is for an image and the description only states images. It'll try to fix this in a bit.

[Destinyg133]

Any news on this?

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

Checklist:

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