[Standards] Proposed XMPP Extension: Quick Response

Dave Cridland dave at cridland.net
Tue Apr 21 13:40:48 UTC 2020

Not blocking comments, but I'd like to explore the forms thing a bit more:

On Tue, 21 Apr 2020 at 13:40, <syndace at web.de> wrote:

> I agree that forms are a better fit for more complicated use-cases with
> multiple fields and options. And I can see that the benifit of a
> single-click "yes" vs. a manually typed "yes" isn't super high.

There's a disadvantage in responses which is that there's no indication
that a response is a response. But maybe that's OK - for bots that are
essentially text-driven, this would allow for pre-canned responses. On the
other hand, a bot could handle something more structured just as well, in

So I can see that these are useful, but I'm worried they'll end up baking
in a data-as-text-body construction which is less than ideal, and tricky to
move away from.

> But I think you are missing the second half of the protoXEP, which is
> actions. Actions have a lot more potential under the hood, examples are:
> - a "merge now" action for a Git bot that notifies a about a new merge
> request
> - a bot that does polls/votes in MUCs
> I think that this can't easily be mapped to forms and that Actions are a
> super simple extension that allow for a variety of different interesting
> bots.

I think any single action can be mapped to a form (I mean, it's an XSLT
transform, let alone a semantic equivalence).

For multiple actions, we cannot exactly duplicate the UX because we want
multiple submit buttons, and forms provide only one (essentially).

We could, instead, create a new field type in forms that would act as a
submission button. Or we could just use multiple forms - ugly, but still.

So what does <action/> offer that a form cannot/does not, that we want to
go this route?

> *Gesendet:* Dienstag, 21. April 2020 um 14:26 Uhr
> *Von:* "Andrew Nenakhov" <andrew.nenakhov at redsolution.com>
> *An:* "XMPP Standards" <standards at xmpp.org>
> *Betreff:* Re: [Standards] Proposed XMPP Extension: Quick Response
> вт, 21 апр. 2020 г. в 16:51, <syndace at web.de>:
>> One example use-case for Quick Response is the memberbot, which asks
>> yes/no multiple times during membership voting. Memberbot does not use a
>> form to ask for yes/no, but a plaintext message. The idea of Quick Response
>> is to enable memberbot to tell clients that "yes" and "no" are possible
>> answers, so that clients can offer convenient UI to quickly select one of
>> these possibilities. I think forms would be helplessly overkill here.
> Well, forms are a good standard way of presenting a user with different
> buttons and options. It can be used for any kind of bots in a fairly
> straightforward way.
> I think that bloating a number of XEPs that are to be supported by various
> application developers is wrong way to go.
> In short, we are unlikely to support this.
> --
> Andrew Nenakhov
> CEO, redsolution, OÜ
> https://redsolution.com <http://www.redsolution.com>
> _______________________________________________ Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:
> Standards-unsubscribe at xmpp.org
> _______________________________________________
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200421/b3a3f0db/attachment.html>

More information about the Standards mailing list