[Standards] Proposed XMPP Extension: Quick Response

Tim Henkes syndace at web.de
Tue Apr 21 14:51:10 UTC 2020

On 4/21/20 3:39 PM, Marvin W wrote:
> (inline)
> On 4/21/20 2:32 PM, syndace at web.de wrote:
>> Verbosity is something that may sometimes be desired, but sometimes
>> duplicate or annoying. Take the example of the merge again: as soon as
>> you select the "merge" action, the bot performs the merge and then
>> probably sends a new notification, stating that the mr was merged. In
>> that case, having a plaintext "Merge MR!3" would be duplicate and noisy.
> The message would only be visible to legacy clients. Clients supporting
> Quick Responses can detect that the message is indeed a Response/Action.

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?

> It probably is a good idea to add some sort tag to messages that are a
> Response so that it is visible the body was created through button press
> and not through text input.
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.
> 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?

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


*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.

>> Another example are polls: if you start a poll in a MUC with hundrets of
>> users, you don't want hundrets of "+1"s or "-1"s to be spammed
>> everywhere. Instead, when the poll ends, the bot would print a summary
>> of the votes. Here the missing plaintext is a "feature".
> Interesting example, because it sounds more like something typically
> done using reactions and there was a lot of discussion if reactions
> should have fallback or not already. IMO reactions shouldn't have a
> fallback body, so if actions are used similarly to reactions, they also
> shouldn't have a fallback body. However in that case you should probably
> just use reactions ;)
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.
> You also mentioned MUCs, however the current ProtoXEP does not specify
> any MUC behavior. I also don't think the proposed protocol can be used
> in MUCs out of the box and requires actual changes
> - How do you use quick responses when there is multiple people writing
> messages that allow for quick responses?
Quick Responses are restricted to the last received message with a MUST,
because there is no way to relate a response to the original message. I
think this question is rather general actually: how to handle if
multiple bots ask questions that require plaintext responses? Keep in
mind that quick responses are just plaintext messages you could've
written manually, no magic. So this problem isn't actually a problem of
quick responses, but the general problem of how to do questions/answers
in MUCs.
> - How do I know that a certain action is actually intended for a
> specific bot in a MUC?
That's missing, right. Could be as easy as referencing the MUC-jid of
the bot in the <action-selected> element. I'll think about it.
> As there has been some discussion regarding the use of Forms instead:
> Forms cannot be used to do what is proposed as Responses in the
> ProtoXEP, but they can already do what is proposed as Actions. Maybe
> just focus on the one thing in this XEP and not put two mostly
> independent things in one XEP?

Splitting this into two protoXEPs has been proposed by Dave and I also
feel like it should be split. The two features are pretty much
independent, even though they solve "similar" issues that probably both
come up when implementing bots.

Regarding forms there also was some input by Dave. If actions can be
done with forms without much struggle I'll change actions to use forms
instead. Though I think that actions as they are now are so extremely
simple that it might not be worth to pull in forms. We'll see though,
I'm open to the possibility.

> 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