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

[x86pup]

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.

[x86pup]

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.

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

[ororktn]

As any user input, m.spoiler.reason should be pointed out as injectable.

This is the only nit-pick i could see (together with the lack of sign-off), i'm eager to see this proposal adopted and more widely implemented!

[turt2live]

The core of this MSC is great to see! I've left a couple of comments to give particular bits some attention, though the MSC could do with an editorial pass to ensure it has enough detail for 3rd party implementations and eventual spec writing.

Please also refer to the checklist for other action items. Once completed, let us know in the SCT Office so we can put this back on the to-be-FCP'd list. Thanks!

[turt2live]

We have objects available to us, so I'm inclined to use them.

Suggested change

	In events with an image, video, or audio file, there will be an optional `m.spoiler` field as a boolean. If true, then clients should show a blurred version of the image. If not present, it will be assumed to be false. There will also be a `m.spoiler.reason` field as a text value that will optionally display text for why the image has a spoiler.
	In events with an image, video, or audio file, there will be an optional `m.spoiler` field. When present, the
	client should show a blurred version of the image. If not present or not an object, the image is assumed
	unspoilered (like how images are sent today). The object MAY contain an optional `reason` field for a
	human-readable reason for the spoiler, like with text spoilers.

The example then becomes:

{
  // ...
  "m.spoiler": {
    "reason": "This content is hidden" // optional
  }
}

[turt2live]

explaining mitigations for these issues would be good, even if it's to acknowledge that the issue may be unfixable.

[turt2live]

This proposal is lacking appropriate sign off, making it ineligible for FCP. See the included checklist for details.