MSC discussion: Custom emoji/stickers and interactions with authenticated & linked media

[turt2live]

The SCT strongly believes that when an event is redacted the media associated with that event should also be redacted. Custom stickers/emoji generally work by re-using MXC URIs between events, breaking the association of event to media object. With this in mind, the SCT is aiming to determine an order for which feature needs to pass FCP first, or which feature needs concrete alterations to support the other.

This issue exists as a discussion place as there's no obvious MSC which would be best to host. Note that while no MSC has been FCP'd the discussion is very much abstract. The common assumptions are:

• Clients will have a way to know which "sticker/emoji packs" the user has access to.
• Packs contain MXC URIs for each of their stickers/emojis, usually uploaded by the creator.
• Media will be linked with events to allow it to be redacted when the event is redacted.
• Users would like to use emoji images in reactions.
• The ecosystem as a whole will be undergoing a relatively difficult migration as we move over to authenticated (linked) media.

MSCs which implement different parts of the above assumptions include the following, though they are at odds with each other:

• MSC2545: Image Packs (Emoticons & Stickers) matrix-spec-proposals#2545 - Image packs (emoticons and stickers)
• MSC1951: Custom sticker packs and emoji (mk II) matrix-spec-proposals#1951 - Custom emoji and sticker packs (in relation to 2545 above)
• MSC4027: Propose method of specifying custom images in reactions matrix-spec-proposals#4027 - Custom images in reactions
• MSC3916: Authentication for media matrix-spec-proposals#3916 - Authentication for media
• MSC3911: Linking media to events matrix-spec-proposals#3911 - Linking media to events

With all that context, the question is how would custom emoji/stickers be impacted if media were linked to exactly one event? Are there considerations beyond MSC3911's copy API needed? What problems do client authors forsee in a linked media world? Ideas on how to resolve the concerns raised by these questions is also extremely welcome, with the only unmovable requirement being that media must be redacted when the associated event is redacted.

Where applicable, the SCT will translate the outcomes of the discussion here to MSCs/action items.

[spaetz]

Outch, yeah. But you will have to have media anyway which is not linked to a single event, just think avatar images. So emoji will have to be treated similarly...

[turt2live]

Avatars are expected to be linked to events too, with the media being copied to get a new media ID for each event.

[turt2live]

The existing sticker and image event types would indeed be affected, though sticker events in the current spec aren't much more than an annotated image. The sharing and distribution offered by sticker packs in particular causes issues, as do inline images.

You mentioned maybe needing a bulk API - why is that? How frequently are you expecting the API to be called?

As for the specific design of MSC2545, that might be best to discuss on the MSC itself. State events have a very different meaning than just replacement, so there's two distinct concepts. The difference between them is out of scope for this thread, but can be covered in one of the many discussion rooms.

As for copying Discord/killing the protocol - expanded thoughts are welcome here. We're not linking media because we want to copy Discord, it's because we want to be able to delete it when the associated event is redacted/deleted. Currently the media lives on, which is a massive privacy issue irrespective of the authentication considerations. What are your specific concerns regarding a migration?

[turt2live]

It sounds like a particular issue with MSC2545 if it would require the need for a bulk API to copy media - that should probably be listed on the MSC itself.

Reference counting should also be recorded on the relevant MSC.

I honestly have no idea when Discord launched the feature - it's something that we've always wanted to do, and finally have time for though. Any other coincidental timing is just that - a coincidence.

I'm fairly sure that MSC3911 has a backwards compatibility clause, but this sounds like a concern for the relevant MSC anyways.