[Standards] Proposed XMPP Extension: Quick Response

Marvin W xmpp at larma.de
Tue Apr 21 15:58:59 UTC 2020


On 4/21/20 4:51 PM, Tim Henkes wrote:
> The question here is, why make a difference between "legacy" clients and
> clients with support? Why hide that an action was performed from users
> with supporting clients and show that an action was performed to users
> of "legacy" clients?

Well, supporting clients can display the "action was performed"
information different from a normal message, just legacy clients can't.
For example the supporting client could change the design of the button
that represented the action to show that this button was pressed. Or the
message could be formatted differently. Or...

> This mixes things up I think. Messages that are triggered by an action
> are always visible as such, because they contain an <action-selected>
> element. Messages that are triggered by a quick response are not meant
> to be anyhow differentiable from manually types messages.

I as a client developer might want to display the fact that a message
was triggered through Quick Response or not. Right now I can only do
that as the sending client because the information is not preserved in
carbons/MAM. IMO every information that exists locally should also be
stored in MAM so that other devices can pick this information up.

>> In your example: If there would be no way to see the "Merge MR!3", how
>> would I know if the merge request was merged because of my message or
>> that it just happened through the web UI?
> Why do you want to know? In the example of a merge request it does not
> matter at all, the action is just a quicker/more convenient way to
> trigger the merge request in exactly the same way that would be possible
> via the web interface. The bot could also just add "triggered by ..." to
> its merge notification. Can you construct a scenario where this is
> actually relevant?

For a merge request it is highly relevant who merged it. I don't know
any code management software that will not display that to you, except
if you put effort into hiding it.

> Thing is, if the bot defines the body to print when an action is
> selected, the bot can just as well just print that message itself when
> the action is performed. Take the following two options:
> *marvin selects action*
> marvin> /Merge MR!3
> gitbot> MR!3 merged
> vs.
> *marvin selects action*
> gitbot> marvin triggered the merge of MR!3
> I don't see how the first variant would be superior to the second, keep
> in mind that in both cases the bot fully controls what is printed, in
> the first variant by setting the "fallback" body and in the second
> variant by printing it directly.

The second variant is superior if the reply from gitbot is not
instantaneous. Let's say, the reply takes 10 seconds, I'd like to know
that my message was send properly. And in a MUC I'd like others to see
that I already did perform the action, so they don't need to do it as well.

> Hehe true, simple polls could be handled with thumbs up or thumbs down
> reactions, but polls with more options would require mapping emojis to
> options etc. :D A poll bot could obviously offer more functionality,
> like limiting the time for votes, printing cool summaries or even doing
> stuff based on the result of the vote.

Couldn't a bot do time limit, summaries and anything else also when the
vote is based on reactions? And mapping to emojis is really straight
forward given that there are the keycap emojis (1️⃣). I know a vote bot
based on reactions exists for Slack.

You just can't use reactions if you want votes to be private, in which
case you also can't use this ProtoXEP (as everyone in the room can see
which actions are performed by whom) - except if you do the voting in
direct messages, in which case you can use reactions again.

> Quick Responses are restricted to the last received message with a MUST,

In that case, quick responses are effectively unusable in MUCs because
someone could just send a message before you and therefor make it
impossible for you to use a quick response.

Also, if there is no indication in the message that a message is a quick
reply, someone could maliciously use this XEP by having a response value
that isn't related to the label at all. This can even be used to lure
users into writing exactly the opposite (value="Yes", label="No"). So
for quick responses, we might want to disallow having a label different
from the value when in MUCs.


More information about the Standards mailing list