Attach multiple images (files) to message

[MurzNN]

Very often we need to show several images with one text message. At now we must send text message and after (or before) this - send images one by one.

Will be good to implement attaching one or multiple files to message before sending it, and send it with composing message, not instantly when attached as separate message.

[t3chguy]

This is something matrix simply doesn't support

[turt2live]

Related: https://github.com/vector-im/riot-web/issues/5872

[MurzNN]

Can't find an issue or MSC about this on Matrix protocol side, so create new https://github.com/matrix-org/matrix-doc/issues/2289

As implementation, this can be field m.attachments, with list of msc:// urls (and maybe even event_id's for attach messages, eg for forwarding message to other room), in event content.

[MurzNN]

I have added the MSC for implement this feature in Matrix: matrix-org/matrix-spec-proposals#2881

[shoqvalue]

@robintown Thanks for showing me the history here. I don't quite understand why this issue would be several years old and get so little discussion, given how common the feature (combing text and image(s) ) is on Slack. Is this a big technical challenge for Matrix, or is it just something Matrix developers don't see a need for and it needs some lobby efforts by users?

[turt2live]

from the Matrix side, it's technically infeasible in the current structure, but over the years we've been working on fixing that in multiple ways. For instance, there's a change in the pipeline to handle images differently to allow them to have a "caption" specifically, which starts to open up the option of having text+image in the same logical message.

[shoqvalue]

Thank you @turt2live. Is it possible to summarize for me, a lowly GUI designer, not a programmer, exactly what the challenge is in doing this? Is it simply the complexity of federating an image and text together? It feels like content would be content, and the protocol woudn't care whether it contained text, text with image, etc. Obviously, this is probably not the case, but I'd be interested in hearing exactly what is. mainly so I can explain it to others and why it might be a bit of a wait before this ever changes.

[turt2live]

It's backwards compatibility: while we can easily send it, other people might not be able to see it. We just have to get all the pieces put together so we can do the switch :)

[shoqvalue]

Ah, thanks, That makes some sense. But couldn't that be partly remedied with a) a different rule for federated output vs local element messages, or perhaps b) a simple embedded "Note" that when clicked, explained that info may have been redacted due to network compatibility issues? That could both alert the user to the omission, while serving to nudge the matrix client developer that they need to get with the updated program? It just feels like it's such an important feature, providing a much smoother user experience, that's it's well worth the effort, even if it might rankle in some quarters. Admittedly, I don't have to deal with that fallout of such things, so I realize this is easy for me to say, but might be a whole lot harder to actually do. Still, as someone preparing to train a lot of people to use this chat, I am dreading all those nontechnical users who don't care why something isn't like what they've known, if there doesn't seem to be a very obvious surface reason why they can't have it :(

[turt2live]

The problem is all of that behaviour needs to be specified too, so we might as well go the route of fixing it properly the first time for the same effort.

Clients aren't currently smart enough to know what to do with unknown data, so we're trying to make them smarter with Extensible Events.

[kittykat]

Moving to discussions as this is cross-platform 👍