From 8065221043bb445dbbae15b66d0ca28115fe7de7 Mon Sep 17 00:00:00 2001 From: Alexey Murz Korepov Date: Fri, 27 Nov 2020 21:31:00 +0300 Subject: [PATCH] Added mentions of similar MSC #2530 and #2529 --- proposals/2881-message-attachments.md | 1 + 1 file changed, 1 insertion(+) diff --git a/proposals/2881-message-attachments.md b/proposals/2881-message-attachments.md index e86a39c7f0..d2d6e30d0a 100644 --- a/proposals/2881-message-attachments.md +++ b/proposals/2881-message-attachments.md @@ -117,6 +117,7 @@ The main issue is fallback display for old clients. Providing the list of links 1. An alternative can be posting media messages as separate events, as it was done earlier, and aggregating them into event via `m.relates_to` field, but clients must do a hide of those events, when aggregating event will be added to the room (like editions), but this will be harder to implement. 2. Other alternative is embedding images (and other media types) into message body via html tags, but this will make extracting and stylizing of the attachments harder. 3. Next alternative is reuse [MSC1767: Extensible events in Matrix](https://github.com/matrix-org/matrix-doc/pull/1767) for attaching and grouping media attachments, but in current state it requires only one unique type of content per message, so we can't attach, for example, two `m.image` items into one message. Maybe, instead of separate current issue, we can extend [MSC1767](https://github.com/matrix-org/matrix-doc/pull/1767) via converting `content` to array, to allow adding several items of same type to one message. +4. There are also [MSC2530: Body field as media caption](https://github.com/matrix-org/matrix-doc/pull/2530) but it describes only text description for one media, not several media items, and very similar [MSC2529: Proposal to use existing events as captions for images #2529](https://github.com/matrix-org/matrix-doc/pull/2529) that implement same thing, but via separate event. But if we send several medias grouped as gallery, usually one text description is enough. ## Future considerations