Conversations: Quote non-text messages

Created on 24 Jul 2018  路  27Comments  路  Source: iNPUTmice/Conversations

Contacts coming from WhatsApp miss the ability to quote messages which aren't just text, e.g. files, audio, video, and images. It'd be nice to have this.

wontfix

Most helpful comment

Me and some friends are already working on this. Hopefully we'll come out with a generic way of quoting messages based on XEP-0367.

Up until now you can indeed quote. The logic is mostly already there and we are busy implementing the UX and solving a couple of bugs.

We'll try to keep this issue updated as we go.

All 27 comments

stanza analog of html anchor?

To extend this with a related idea - why can't media be _part_ of a message instead of always having to be sent as a separate message?

For example, sometimes I want to highlight a user in an MUC and send them a file -

Ideally, this would go like this.
<me> "user: <file>"

Currently, it goes like this.

<me> "user:"
*I start going through the file selection dance*
<someone else> "unrelated chatter"
*My file is now uploading*
<someone else> "unrelated chatter"
<me> "<file>"

I am told this would require a database schema change, but I'm pretty certain that this is the more modern, more user-friendly, and more consistent behaviour.

Me and some friends are already working on this. Hopefully we'll come out with a generic way of quoting messages based on XEP-0367.

Up until now you can indeed quote. The logic is mostly already there and we are busy implementing the UX and solving a couple of bugs.

We'll try to keep this issue updated as we go.

Is there something new about that feature?

Here are some teaser pics ;)

01
02

Feel free to test the branch if you want.

We plan to make the PR soon

@manchito what do ChatSecure/Dino/Gajim/Legacy users see?

Nice work, great to see this coming along 馃槂 A question - what does tapping the quoted file do? Opening the file might be nice, but that is inconsistent with the inline audio player. Maybe tapping the quoted file could jump to the original message with the file?

@licaon-kter

When Quoting text, clients not supporting XEP-0367 see it as before:

> Original text
Comment

With files & co. they see the URI:

> aesgcm://...
Comment

> geo:52.517036,13.388858
Comment

@contrapunctus-1

Opening the file might be nice, but that is inconsistent with the inline audio player. Maybe tapping the quoted file could jump to the original message with the file?

The latter is the current behaviour

@manchito Could you please outline how and which XEPs you use? XMPP is a federated system after all, it would be great to have an opportunity to discuss this feature, standards-use-wise, before it鈥檚 getting merged in this (rather influential) client.

Ideally, some discussion on the standards mailing list would be great.

(I have a particular interest in this, since "rich" quoting somewhat overlaps with reactions, for which I have some idea, too.)

@horazont we use XEP-0367: Message Attaching

To keep compatibility with non-standard clients though, which still use the ">" method, Conversations sends _both_ the XEP-compliant reference _and_ the legacy quotation.

<message to='[email protected]/ship' from='[email protected]/island id='RgEGnjqy'>
<attach-to id='oldmessage1' xmlns='urn:xmpp:message-attaching:0'/> _XEP-0367_
<body>
> aesgcm://... _legacy_
Nice picture!
</body>
</message>

A standard client then should strip out the legacy quotation if it matches the content (or the file/geo URI) of the referenced message. At least that is what we do. Hopefully this won't be necessary when most of the clients support XEP-0367. Without that addition they just see the comment as a regular message.

Any reason why you chose Message Attaching over References? https://xmpp.org/extensions/xep-0372.html

I think Attaching might lead to suboptimal display in some existing clients. The intent of Attaching was e.g. a bot which replies to and annotates a message, while References was made more for use-cases like yours.

(I heard of clients implementing some stuff based on Message Attaching, but I don鈥檛 know which clients and which stuff off the top of my head, I鈥檒l try to figure that out.)

I think Attaching might lead to suboptimal display in some existing clients. The intent of Attaching was e.g. a bot which replies to and annotates a message, while References was made more for use-cases like yours.

This seems like the exact same thing as what you just said (except it's not a bot). Message Attaching was actually used for this originally too, so I think it would be fine. If another client displays things slightly differently, it will still get the point across that one message was referencing another.

@SamWhited
The idea of attaching is that the attached message might be shown out-of-order right below the target message. This might be confusing and unintended. Sorry, I didn鈥檛 make the difference I expect clear in my previous post.

The idea of attaching is that the attached message might be shown out-of-order right below the target message.

Exactly how a client displays it shouldn't matter; if it does I probably need to tweak that in the XEP to make it less strict.

UPDATE:

A receiving client MAY choose to show the attached message next to or below the indicated message in whatever display is used for messages or can choose to display the attachment in another way (including as a normal message, completely ignoring the attach-to element).

Showing a message with a quotation out of order would be not-so-great. While other message attachment use-cases such as bots which add meta-information profit from this feature. Likewise, attachments might very well be hidden by default et cetera et cetera. It is semantically very different from a reference/quotation in my opinion.

Showing a message with a quotation out of order would be not-so-great.

Yah, I suppose that's fair. Maybe a message could be considered an attachment if it's already in the same thread? Or maybe attaching just needs to be made more specific to the bot use case and something similar be created for quotes but with that specific idea in mind. Or maybe an attribute could be added to attachments with an enum of reasons so the client can decide how it wants to display it? Eg. use='followup' or use='quote' or similar?

@horazont

Any reason why you chose Message Attaching over References? https://xmpp.org/extensions/xep-0372.html

Message Attaching fits well our use case of commenting a message by its id. We do not see References supporting this. The nearest one would be 3.4, but it does not allow a body and does not specify the way a message can be uniquely identified. Furthermore, even if 3.4 covered our use case other use cases outside our scope would still have to be implemented in order to be compliant with the whole XEP.

Additionally, Message Attaching seems simpler and fully specified while References seems more like a Proto-XEP than a finished specification.

It's true that the terminology used in Message Attaching is a little misleading when it comes to referencing a message, but the logic is right. The small change @SamWhited proposed would solve the issue with the different display possibilities and we could add it right away to our implementation. We would then propose something like use='reference' or use='comment'.

We renamed the branch to message-attaching.

@maanAlbalkhi I tried to ask via XMPP but you're rejecting messages from strangers, FYI:

I'm drafting an update to Message Attaching that includes a "type" element that can be set to either "followup" or "reference". A value of "followup" means the traditional behavior: eg. a bot might be sending more info about a link that an end user sent previously and clients may choose to re-order the messages to place the followup after the original message, or display it in some other way. A value of "reference" means that the messages should not be reordered and clients may choose to display a link to the original message, or display it as a quote, etc.

Does this cover your use case? Anything else you feel is missing? I'll also try to put in a few more security considerations and fix some poor wording. Suggestions for the terminology are welcome if those don't sound good too.

Hello!
Is it possible to make the reply functionality support XEP-0201 -- threads? When you reply to a message you can pass the thread identifier in your message stanza. When having a thread identifier in a message every party can embed the original message with all the contents (including attachments) to the response message.

This approach has some positive side effects, like when you're communicating with some software-driven entity (a bot) this entity can identify the original message too.

@SamWhited

Does this cover your use case?

Thank you for the update. The value reference would fit our case.

Anything else you feel is missing?

Currently, we would just suggest the integration of legacy quotations.

@SamWhited

I tried to ask via XMPP but you're rejecting messages from strangers

Sorry for that. I wrote you directly.

Currently, we would just suggest the integration of legacy quotations.

What are legacy quotations?

Also, the message you sent me was OMEMO encrypted but I don't use OMEMO and can't read it. Also I still can't reply, it says you're rejecting message still (and I don't give presence subscription to people I don't know for the most part, sorry).

EDIT: I got your message with no OMEMO that time, but still can't reply, sorry :)

Hello.
don't you think that sending message back as attach is silly? Partner have the message already, so it would be better to point him what message do you mean. It would be ideal with XEP-0201 Threads. And when partner gets message with link to other one (with thread feature) he can stylish message view on his side as he want.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Bump

This is not feasible from a technical perspective before the rewrite.

Was this page helpful?
0 / 5 - 0 ratings