[Standards] Proposed XMPP Extension: Quick Response

Tim Henkes syndace at web.de
Tue Apr 21 16:33:55 UTC 2020


On 4/21/20 5:58 PM, Marvin W wrote:
> (inline)
>
> 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...

Ah I could've guessed that you also want supporting clients to do/print something. I dislike that for the reasons I gave already, e.g. that for votes in MUCs this could create a huge amount of useless spam on legacy clients. Also "change the design of the button that represented the action" etc. is controlled by the supporting client, while the fallback body is controlled by the bot. This is an inconsistency to this solution that I also dislike. Without a fallback body or any other types of reactions to actions, the output is consistently controlled by the bot itself. And the bot is the unit that knows best which information to print at which point.

>> 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.
I'd rather add "a client MUST NOT treat a quick response differently
than a normally typed response" to the protoXEP than send that
information out. It misses the point of Quick Responses being just quick
responses.
>>> 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.
Agreed. As it is so extremely relevant, every Git bot will also mention
in the merge notification who merged it. The nickname of the merging
person in the MUC is rather irrelevant, especially in anonymous MUCs,
while the Git name/email is much more relevant. Which actually
strengthens my opinion that automatically spamming the chat when an
action was performed is not helping. To repeat what I wrote in my last
mail, the bot has full control of the content of a hypothetical fallback
body. So whether the bot puts "I clicked merge" into the fallback body
or prints "marvin clicked merge" itself is zero difference, except that
the second also confirms that the bot has correctly registered your click.
>> 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.
When starting a long-running operation the bot could print something to
indicate that, though I don't think that's necessary for something like
a 10 second merge.
>> 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.
I'm sorry I don't know what point you are trying to make with this, are
you saying that anything possible with actions can be done by mapping
emojis of reactions? I don't know if that's something I want to argue
about further.
> 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.
Yeah private actions are on my list to think about should this get
accepted as an experimental XEP.
>> 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.
Yes, use of quick responses in MUCs are probably rather limited. Which
comes from the fact that quick responses are just simple plaintext
messages that you could have typed manually. Even humans sometimes have
problems relating a response to the original message. A bot without help
of any ids is completely lost here. That's why the quick responses are
limited to the very last message.
>
> 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.
You are pleading for a fallback body, which would also be controlled by
the bot. When clicking "merge" the bot could make you print "merge
request rejected and closed" instead. Though I agree that the labels are
something to think about and should probably be removed. But if labels
are removed, that's another strong contra against fallback bodies.
>
> Marvin
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________


More information about the Standards mailing list