[Standards] Proposed XMPP Extension: Quick Response

Kevin Smith kevin.smith at isode.com
Wed Apr 22 07:58:00 UTC 2020

On 22 Apr 2020, at 08:10, Daniel Gultsch <daniel at gultsch.de> wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>> Title: Quick Response
>> Abstract:
>> Quickly respond to automated messages.
>> URL: https://xmpp.org/extensions/inbox/quick-response.html
>> The Council will decide in the next two weeks whether to accept this
>> proposal as an official XEP.
> To make it quick I’ll vote yes in our Council meeting this afternoon.
> I think it's good enough and interesting enough for an experimental
> XEP.

I have very mixed feelings on the protoXEP. It seems like a non-extensible solution to a fraction of a larger problem, which is not great. Equally, sometimes just solving the problem at hand is better than not solving a bigger/more general problem.

The appeal of the feature is obvious.

> Personally I’m finding myself broadly agreeing with what Matthew wrote.
> * UX of data forms is horrible for 'simple' things like this
> * We should consider joining response and action; (That will probably
> mean getting rid of response)
> * We should consider sending the action-accepts as IQs. Having just
> implemented Jingle Message Initiation the uncertainty that comes with
> messages (I’m finding myself trying to track them via receipts) is not
> ideal for 'triggering actions' - Certainly I would like to know
> whether my merge action has actually been merged.
> Getting rid of response and making action responses (just the
> responses) IQ, will probably also give a hint at the direction people
> want to take the UI in. (Meaning no; you won't see your response as a
> message; but instead button turns into spinning wheel while IQ is in
> flight; and gets a checkmark or becomes gray one success)

I think it needs to be messages because you expect this to be part of the normal chat flow, and therefore to end up in your archive.


More information about the Standards mailing list