MSC2881: Message Attachments

[MurzNN]

Rendered

Depends on MSC3051: A scalable relation format

Similar MSC: #4274

Status: Closed in favor of inline media references like this:

Check out my photos from FOSDEM 2025:
<img src=\"mxc://example.org/JWEIFJweifjWIeifj\" />" 
<img src=\"mxc://example.org/JWEIFJweifjWIeifk\" />" 
<img src=\"mxc://example.org/JWEIFJweifjWIeifl\" />" 

And especially look at this awesome group photo: 
<img src=\"mxc://example.org/JWEIFJweifjWIeifm\" />" 

What a nice day at FOSDEM 2025!

_To implement this feature, we don't need any server-side changes; this can be implemented fully on the client side (message composer to handle inserting, and renderer to display thumbnails and pop-up galleries).

This idea is described in a separate MSC: #4475

Related issues:

• Attach multiple images (files) to message
• Show albums for multiple images
• Message attachments (multiple photos, files, other messages for forwarding, etc)
• [Redesign: timeline: implement new file transfer UX](Redesign: timeline: implement new file transfer UX element-hq/element-web#7565
• Image galleries & captions element-hq/roadmap#13

Also, look up alternative and more optimal implementation: #3382

Signed-off-by: Alexey Korepov MurzNN@gmail.com

[chayleaf]

Currently Synapse doesn't allow m.relates_to to be an array, so the first option isn't doable as-is, but it's possible to implement with a limited attachment count (1). That also won't allow to reply with images.

[MurzNN]

Currently Synapse doesn't allow m.relates_to to be an array, so the first option isn't doable as-is, but it's possible to implement with a limited attachment count (1). That also won't allow to reply with images.

@pavlukivan Thanks for identifying the problem, m.relates_to is object, not array, and now already late to change it. What do you think about using the separate key in object for attachments? Something like this:

{
  "type": "m.room.message",
  "content": {
    "msgtype": "m.text",
    "body": "Here is my photos and videos from yesterday event",
    "m.relates_to": [
      {
        "m.in_reply_to": {
          "event_id": "$id_of_replied_message"
        },
        "attachments": {
          "event_ids": [
            "$id_of_previosly_send_media_event_1",
            "$id_of_previosly_send_media_event_2",
            "$id_of_previosly_send_media_event_3",
          ]
        }
      },
      {
        "rel_type": "m.attachment",
        "event_id": "$id_of_previosly_send_media_event_2"
      }
    ]
  }
}

Or even we can move attachments to upper level, but, as I guess, Synapse must implement some optimizations to deliver events, mentioned in m.relates_to together with main event (or at least preload them for quicker access).

[chayleaf]

What do you think about using the separate key in object for attachments?

While it seems like a hack, I guess it will offer the best compatibility (old clients won't be required to handle array relations). Of course I'd prefer the option where relations become an array (or similar), but it would require client support to understand the new format at all.

[MurzNN]

While it seems like a hack, I guess it will offer the best compatibility (old clients won't be required to handle array relations). Of course I'd prefer the option where relations become an array (or similar), but it would require client support to understand the new format at all.

I suppose that implementing multiple attachments without array as storage is impossible, and implementing with limitation of only one attachment is useless! Thus we still need to insert the array somewhere :)

And the best way, I think, is to implement some type of arrays in MSC1767: Extensible events in Matrix (and follow it in current MSC) - here is my comment about this #1767 (comment)

[deepbluev7]

Thanks for identifying the problem, m.relates_to is object, not array, and now already late to change it.

Not really. #2674 hasn't landed yet and one could use #3051 instead. But so far there seem to be not enough use cases to allow multiple relations.

[chayleaf]

I think using an array still makes sense, considering it adds very little overhead but adds use cases like this. The only downside I see is it being harder to store relations in the database, as one-to-many is considerably easier to store.

[kevincox]

This seems like a clear answer of "we will need it". It is easy to imagine and we have a real-world use case here.

[chayleaf]

But so far there seem to be not enough use cases to allow multiple relations.

Off the top of my head: replying to multiple message at the same time, or starting a thread from multiple messages could be done with that

[turt2live]

@MurzNN I'm not sure what happened here, but the diff is showing quite a few changes. I would recommend either fixing the branch, or, if preferred, closing this PR and opening a new MSC off a dedicated branch.

[richvdh]

suspect this is the problem:

see #3367

[MurzNN]

@richvdh Thanks for the tip, I've switched to main branch, seems now all is well.

[MurzNN]

There is also a new similar MSC #4274 but got stuck in the discussions too.

For now, I got a fresh idea of handling attachments just inline in the message body, like this:

Check out my photos from FOSDEM 2025:
<img src=\"mxc://example.org/JWEIFJweifjWIeifj\" />" 
<img src=\"mxc://example.org/JWEIFJweifjWIeifk\" />" 
<img src=\"mxc://example.org/JWEIFJweifjWIeifl\" />" 

And especially look at this awesome group photo: 
<img src=\"mxc://example.org/JWEIFJweifjWIeifm\" />" 

What a nice day at FOSDEM 2025!

Seems to implement this feature, we don't need any server-side changes; this can be implemented fully on the client side (message composer to handle inserting, and renderer to display thumbnails and popup galleries).

Additionally, we can extend the message with the list of references to inline attachments, to keep the links as dependencies (especially for encrypted messages) and be able to clean up unused (orphaned) attachments.

But, actually, I am not a Matrix client developer to move this forward with client-side implementation, so let me close this MSC with a conclusion to implement the inline attachments instead.

And if there is someone who wants to move this idea forward, please create a new MSC, and I will be happy to join and help you with the specifications details, and other discussions.

[MurzNN]

Okay, let me try with a new MSC describing a universal approach: #4475 - let's move there!