subject:"\[Standards\] Proposed XMPP Extension\: Quick Response"

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

> This mixes things up I think. Messages that are triggered by an action
> are always visible as such, because they contain an 
> 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.

Marvin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

2020-04-21 Thread Tim Henkes




On 4/21/20 3:39 PM, Marvin W wrote:

(inline)

On 4/21/20 2:32 PM, synd...@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 
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

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.


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  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 mu

Re: [Standards] Proposed XMPP Extension: Quick Response

2020-04-21 Thread Tim Henkes



On 4/21/20 3:40 PM, Dave Cridland wrote:

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

On Tue, 21 Apr 2020 at 13:40, mailto:synd...@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 parallel.


"Something more structured" would probably mean something that requires
additional client support to work, right? To reiterate, the idea for
quick responses is that they are 100% equivalent to manually typing the
message. So that e.g. memberbot can just add indicators that "yes" and
"no" are possible responses, without having to do/change anything else.
I think the simplicity and non-structuredness is the key here.


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.


Maybe the protoXEP should hint at forms for anything more complex than
just a plain text response.


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  offer that a form cannot/does not, that we want
to go this route?


You could define multiple actions as a single form that may only contain
instances of the new submission button and that has to be rendered
inline together with the message by clients. But that would mean that

a) only the subset of forms is used which doesn't even exist yet

b) possibly (not sure about that one) a set of rather complicated rules
that try hard to make forms fit in, where the proposed solution is a
single super compact XML element with clear semantics.

And clients obviously couldn't support Quick Response without supporting
forms, though from what I've heard support for forms is rather
wide-spread in clients so that's probably not a big issue.


*Gesendet:* Dienstag, 21. April 2020 um 14:26 Uhr
*Von:* "Andrew Nenakhov" mailto:andrew.nenak...@redsolution.com>>
*An:* "XMPP Standards" mailto:standards@xmpp.org>>
*Betreff:* Re: [Standards] Proposed XMPP Extension: Quick Response
вт, 21 апр. 2020 г. в 16:51, mailto:synd...@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-unsubscr...@xmpp.org
<mailto:standards-unsubscr...@xmpp.org>
___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
<mailto:standards-unsubscr...@xmpp.org>
__

Re: [Standards] Proposed XMPP Extension: Quick Response

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

On Tue, 21 Apr 2020 at 13:40,  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
parallel.

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  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" 
> *An:* "XMPP Standards" 
> *Betreff:* Re: [Standards] Proposed XMPP Extension: Quick Response
>
>
> вт, 21 апр. 2020 г. в 16:51, :
>
>> 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-unsubscr...@xmpp.org
> ___
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

(inline)

On 4/21/20 2:32 PM, synd...@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.

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.

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?

> 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 ;)

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?
- How do I know that a certain action is actually intended for a
specific bot in a MUC?

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?

Marvin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

вт, 21 апр. 2020 г. в 17:35, Dave Cridland :

> I read this as you wouldn't support this going to Draft.
>
> I assume you might reconsider if it became widely deployed?
>

Well, I'm not in the XMPP council to support this going to Draft, but I'm
not going to ask our developers to implement this. At least, unless people
will start pointing fingers at Xabber saying, "ha-ha-ha, this obsolete
client doesn't support this very essential and universally supported Quick
Responces XEP, shame-shame-shame".

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

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.

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.

Gesendet: Dienstag, 21. April 2020 um 14:26 Uhr
Von: "Andrew Nenakhov"
An: "XMPP Standards"
Betreff: Re: [Standards] Proposed XMPP Extension: Quick Response

вт, 21 апр. 2020 г. в 16:51, <synd...@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

___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

On Tue, 21 Apr 2020 at 13:26, Andrew Nenakhov <
andrew.nenak...@redsolution.com> wrote:

>
>
> вт, 21 апр. 2020 г. в 16:51, :
>
>> 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.
>

I read this as you wouldn't support this going to Draft.

I assume you might reconsider if it became widely deployed?

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

On Tue, 21 Apr 2020 at 13:25,  wrote:

> The more I think about it, the more I agree that the two things are
> separate and should be separate. Same UX is unrealistic. Thinking of a
> mobile client, Quick Responses would probably be displayed near the
> on-screen keyboard, maybe above it. Actions would be displayed near the
> message that defined the action instead.
>
> I still kind of expect that clients would implement both or neither, but
> I'm ready to be persuaded into splitting it.
>

Absolutely not a blocking point for me, to be clear.


>
> *Gesendet:* Dienstag, 21. April 2020 um 13:32 Uhr
> *Von:* "Dave Cridland" 
> *An:* "XMPP Standards" 
> *Betreff:* Re: [Standards] Proposed XMPP Extension: Quick Response
> This seems to be a two-in-one.
>
> Do I assume the intent is that both responses and actions would be
> presented as the same UX in the receiving client?
>
> Otherwise, I'm sort of leaning toward these being in different XEPs.
>
> On Tue, 21 Apr 2020 at 11:50,  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.
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>
> ___ Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:
> standards-unsubscr...@xmpp.org
> ___
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

Hi,

yes, in case of a merge request it would be rather easy to define a text format. Everything can be represented in human readable terms, even random ids :) And bots are obviously free to also accept a text-based command to perform an action. Actions are just a single-click solution for convenience.

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

Gesendet: Dienstag, 21. April 2020 um 14:23 Uhr
Von: "Marvin W" 
An: standards@xmpp.org
Betreff: Re: [Standards] Proposed XMPP Extension: Quick Response

Hi,

To me that still sounds like the only major difference is that actions
are not backwards compatible.

I understand that action IDs can be just random, however I wonder what
the usecase of such is that couldn't be realized using a human-readable
text.

Looking at the example in the XEP, the action id = response value of a
an action/response labeled "Merge now" for a merge request with id 3
could just be "Merge MR!3" which is both human and bot readable. I think
something is wrong with an action if it cannot be described in
human-readable terms.

With regards to fallback, I was thinking that I'd like the fact that I
performed an action be visible on other clients (through MAM/carbons)
even if they don't support this new XEP. For Responses this works but
for Actions it doesn't.

Marvin

On 4/21/20 1:18 PM, synd...@web.de wrote:
> Hi Marvin,
>  
> I'll try to summarize the difference between Responses and Actions:
>  
> A Response is supposed to be exactly equivalent to a "manual" text
> response, without any magic implied. That is, manually typing "yes" in a
> client that doesn't support Quick Response is 100% equivalent to
> selecting the "yes" Quick Response in a client that supports the XEP. An
> implication of the absence of "magic" here is, that Responses only apply
> to the most recently received message, because without magic there is no
> "reference" from the response to the original message.
>  
> Actions are not compatible with clients that don't support Quick
> Response, as they require "understanding" the  element and
> responding with an . Because clients are free to
> generate unique ids here, the selection of an action is not limited to
> the last message, there is no problem relating the response to the
> original message. A "fallback" body is something that bots can choose to
> do anyway, by allowing to trigger the action via a plaintext response
> too (or comparable).
>  
> Hope that clears it up,
> Syndace
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

вт, 21 апр. 2020 г. в 16:51, :

> 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 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

The more I think about it, the more I agree that the two things are separate and should be separate. Same UX is unrealistic. Thinking of a mobile client, Quick Responses would probably be displayed near the on-screen keyboard, maybe above it. Actions would be displayed near the message that defined the action instead.

I still kind of expect that clients would implement both or neither, but I'm ready to be persuaded into splitting it.

Gesendet: Dienstag, 21. April 2020 um 13:32 Uhr
Von: "Dave Cridland"
An: "XMPP Standards"
Betreff: Re: [Standards] Proposed XMPP Extension: Quick Response

This seems to be a two-in-one.

Do I assume the intent is that both responses and actions would be presented as the same UX in the receiving client?

Otherwise, I'm sort of leaning toward these being in different XEPs.

On Tue, 21 Apr 2020 at 11:50, <p...@bouah.net> 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.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

Hi,

To me that still sounds like the only major difference is that actions
are not backwards compatible.

I understand that action IDs can be just random, however I wonder what
the usecase of such is that couldn't be realized using a human-readable
text.

Looking at the example in the XEP, the action id = response value of a
an action/response labeled "Merge now" for a merge request with id 3
could just be "Merge MR!3" which is both human and bot readable. I think
something is wrong with an action if it cannot be described in
human-readable terms.

With regards to fallback, I was thinking that I'd like the fact that I
performed an action be visible on other clients (through MAM/carbons)
even if they don't support this new XEP. For Responses this works but
for Actions it doesn't.

Marvin

On 4/21/20 1:18 PM, synd...@web.de wrote:
> Hi Marvin,
>  
> I'll try to summarize the difference between Responses and Actions:
>  
> A Response is supposed to be exactly equivalent to a "manual" text
> response, without any magic implied. That is, manually typing "yes" in a
> client that doesn't support Quick Response is 100% equivalent to
> selecting the "yes" Quick Response in a client that supports the XEP. An
> implication of the absence of "magic" here is, that Responses only apply
> to the most recently received message, because without magic there is no
> "reference" from the response to the original message.
>  
> Actions are not compatible with clients that don't support Quick
> Response, as they require "understanding" the  element and
> responding with an . Because clients are free to
> generate unique ids here, the selection of an action is not limited to
> the last message, there is no problem relating the response to the
> original message. A "fallback" body is something that bots can choose to
> do anyway, by allowing to trigger the action via a plaintext response
> too (or comparable).
>  
> Hope that clears it up,
> Syndace
> 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

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.
 

Gesendet: Dienstag, 21. April 2020 um 13:46 Uhr
Von: "Andrew Nenakhov" 
An: "XMPP Standards" 
Betreff: Re: [Standards] Proposed XMPP Extension: Quick Response



 
 


вт, 21 апр. 2020 г. в 16:29, <synd...@web.de>:




Why would you use a form to send a plaintext message?

 






 

Because they already exist and are capable of doint what this XEP intends to do. It might be convenient for a recepient to select one of several options, but it is not convenient for the asking entity to send such requests and review answers for them, so such feature will likely used only by bots. And for bot it is eaiser to process a form than a text message.


--

















Andrew Nenakhov

CEO, redsolution, OÜ
https://redsolution.com


















___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

вт, 21 апр. 2020 г. в 16:29, :

> Why would you use a form to send a plaintext message?
>
>

Because they already exist and are capable of doint what this XEP intends
to do. It might be convenient for a recepient to select one of several
options, but it is not convenient for the asking entity to send such
requests and review answers for them, so such feature will likely used only
by bots. And for bot it is eaiser to process a form than a text message.

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

That's true, Responses and Actions are essentially separate things, though they go hand in hand and they were the result of a single discussion.

Yes, similar UX is expected and makes sense, though the specification obviously doesn't mandate any details regarding UX.

I don't know if splitting this already small specification with two similar features into two is necessary. Chances are that a bot which wants to simplify communication for users has use for both things. I could reduce the SHOULD for providing UX for actions to a MAY, so that clients that only want to support one of the features can do so without violating a SHOULD.

Gesendet: Dienstag, 21. April 2020 um 13:32 Uhr
Von: "Dave Cridland"
An: "XMPP Standards"
Betreff: Re: [Standards] Proposed XMPP Extension: Quick Response

This seems to be a two-in-one.

Do I assume the intent is that both responses and actions would be presented as the same UX in the receiving client?

Otherwise, I'm sort of leaning toward these being in different XEPs.

On Tue, 21 Apr 2020 at 11:50, <p...@bouah.net> 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

___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

This seems to be a two-in-one.

Do I assume the intent is that both responses and actions would be
presented as the same UX in the receiving client?

Otherwise, I'm sort of leaning toward these being in different XEPs.

On Tue, 21 Apr 2020 at 11:50,  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.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

Why would you use a form to send a plaintext message?

 


Gesendet: Dienstag, 21. April 2020 um 13:26 Uhr
Von: "Andrew Nenakhov" 
An: "XMPP Standards" 
Betreff: Re: [Standards] Proposed XMPP Extension: Quick Response



вт, 21 апр. 2020 г. в 16:18, <synd...@web.de>:





Hi Marvin,

 

I'll try to summarize the difference between Responses and Actions:

 

A Response is supposed to be exactly equivalent to a "manual" text response, without any magic implied. That is, manually typing "yes" in a client that doesn't support Quick Response is 100% equivalent to selecting the "yes" Quick Response in a client that supports the XEP. An implication of the absence of "magic" here is, that Responses only apply to the most recently received message, because without magic there is no "reference" from the response to the original message.




 

Can't we just use forms for this? 


--

















Andrew Nenakhov

CEO, redsolution, OÜ
https://redsolution.com



















___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___




___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

вт, 21 апр. 2020 г. в 16:18, :

> Hi Marvin,
>
> I'll try to summarize the difference between Responses and Actions:
>
> A Response is supposed to be exactly equivalent to a "manual" text
> response, without any magic implied. That is, manually typing "yes" in a
> client that doesn't support Quick Response is 100% equivalent to selecting
> the "yes" Quick Response in a client that supports the XEP. An implication
> of the absence of "magic" here is, that Responses only apply to the most
> recently received message, because without magic there is no "reference"
> from the response to the original message.
>

Can't we just use forms for this?

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response

Hi Marvin,

I'll try to summarize the difference between Responses and Actions:

A Response is supposed to be exactly equivalent to a "manual" text response, without any magic implied. That is, manually typing "yes" in a client that doesn't support Quick Response is 100% equivalent to selecting the "yes" Quick Response in a client that supports the XEP. An implication of the absence of "magic" here is, that Responses only apply to the most recently received message, because without magic there is no "reference" from the response to the original message.

Actions are not compatible with clients that don't support Quick Response, as they require "understanding" the  element and responding with an . Because clients are free to generate unique ids here, the selection of an action is not limited to the last message, there is no problem relating the response to the original message. A "fallback" body is something that bots can choose to do anyway, by allowing to trigger the action via a plaintext response too (or comparable).

Hope that clears it up,

Syndace

Gesendet: Dienstag, 21. April 2020 um 13:08 Uhr
Von: "Marvin W" 
An: standards@xmpp.org
Betreff: Re: [Standards] Proposed XMPP Extension: Quick Response

Hi,

Do I see it right, that the only relevant difference between a
"Response" and an "Action" is that legacy clients will display a
selected Response as message but won't display a selected Action at all?

Was it a deliberate decision to not have a fallback body for Actions?

Marvin

On 4/21/20 12:44 PM, p...@bouah.net 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.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Quick Response