spaetz
commented
11 months ago 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...
Open turt2live opened 11 months ago
spaetz
commented
11 months ago 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
commented
11 months ago Avatars are expected to be linked to events too, with the media being copied to get a new media ID for each event.
turt2live
commented
10 months ago 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
commented
10 months ago 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.
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:
MSCs which implement different parts of the above assumptions include the following, though they are at odds with each other:
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.