Stickers have incomplete / invalid documentation around encryption

[jplatte]

Link to problem area: https://spec.matrix.org/latest/client-server-api/#msticker

Issue

According to the spec, m.sticker's content has a mandatory url field. However according to tulir, m.sticker was supposed to be like m.room.message with "msgtype": "m.image", just with a different event type such that the url field is only required for unencrypted stickers and there's a file object for encrypted ones instead (which is not specced at all).

Can I send a PR adjusting the spec to match that understanding, or is more discussion / an MSC or somesuch necessary?

cc MSC1158 (Sticker messages)

[turt2live]

I can't find evidence that stickers were designed to be copies of m.image messages, but it's probable that implementations support it that way.

This would normally require an MSC to fix, but I think it's much more important for us to get extensible events through FCP instead. This would fix the image representation issues in the process.

[jplatte]

This would normally require an MSC to fix, but I think it's much more important for us to get extensible events through FCP instead.

I don't understand what this means for my suggestion of sending a PR adjusting the spec to what at least Mautrix implements. Would that be accepted, or not?

[turt2live]

I can't speak on behalf of the entire spec core team on the issue, but I suspect it would not be accepted. The stickers feature was intended to promote reuse of MXC URIs, which translates to unencrypted files. It's considered a spec bug that we don't have encrypted sticker support, but not in a way where we can avoid an MSC.

Opening an MSC to add Mautrix's implementation would largely get deprioritized in favour of extensible events, given limited bandwidth from the SCT.

[jplatte]

Okay, then the thumbnail_file field of type EncryptedFile should be removed from the ImageInfo type (info field) under m.sticker? And maybe a note could be added that encrypted stickers are not supported.

[turt2live]

Possibly, or we focus our efforts on extensible events and deprecate all event definitions in the client-server API :D

I'd honestly suggest we put our energy towards ensuring Extensible Events (and the associated Events Specification, separated from the Client-Server API) is what we're looking for feature-wise. The events spec doesn't yet have an MSC, but should hopefully have something soon.

[dkasak]

Possibly, or we focus our efforts on extensible events and deprecate all event definitions in the client-server API :D

What would this mean in practice? Even extensible events have some standard event definitions, no? So I'm not quite sure what's being suggested.