XEP-0439: Quick Responses - Feedback
Hi, I looked through the XEP and i find a few things not great. Im not getting the difference between <response> and <action>. And the XEP makes no attempt to describe it. A question that i answer with "Yes" or "No" should be a response, but a Question that i answer with "Merge" is an action? Seems completely random. The XEP mentions no use case that can only be done with <response>, i see no reason at all as a client developer to implement this. Now for <actions>, the id attribute is under specified, it seems essential to the whole thing working at all. Should this be a globally unique ID? Or at least unique per remote JID? In my opinion <action> should have another id attribute (of course differently named) referencing the message it belongs to. We have this pattern with message errors, iq responses, reactions, message replies, moderation, etc., we should not break this pattern here for no gain, just because its theoretically possible to still match this if the id is globally unique. I think this is a really nice idea and feature, but it should fit in with current XEP patterns, and better describe what <response> even should accomplish. Is the original Author still around? I also looking forward to other peoples opinions.
Hi Philipp, I'm not the author, but I feel I can answer most of the questions. On Sat, 2024-06-29 at 13:25 +0000, Philipp Hörist wrote:
Im not getting the difference between <response> and <action>. And the XEP makes no attempt to describe it.
Quick responses are regular messages with a <body>. They are only available as a direct response to the very last message in a conversation. If the receiving client does not support quick responses, the user can just manually type in the response and quick responses sent from other devices are displayed as usual messages in the same way as they're displayed on devices that do support it. In a user interface, I'd expect the following: - The buttons for quick responses only show as long as there was no message since the message they respond on (see rule 3 in business rules). They might be "attached" to the message or the chat input field. - Quick response availability does not prevent regular chat input. - Selecting a quick response button will behave largely the same as if the user typed the message of the quick response value in the chat input and sends it. - The quick response will be displayed as a regular message in the chat history. Actions, in contrast, are not using a <body>. They can be sent at any later point as they are merely announced via the message, but not necessarily related to it. Receiving clients that don't support actions can't send them and don't see if other clients sent them. In a user interface I'd expect the following: - The buttons for actions show infinitely (or, client-specific, after a timeout - this sounds like something that could also be announced with the <action>). They should be attached to the message itself and remain visible even after being selected. - Action availability does not prevent regular chat input. - Selecting an action will likely display somehow that the action was performed, but doesn't prevent any attempt to perform it again or any other action announced on the same message. (the ability to modify this behavior might be worth adding to the spec) - The action will not be displayed as a regular message in the chat. The bot on the other end will likely send a follow up message to indicate that the action was performed.
Now for <actions>, the id attribute is under specified, it seems essential to the whole thing working at all. Should this be a globally unique ID? Or at least unique per remote JID?
The business rules have some section on this that IMO explain that very well:
Sending clients MUST keep in mind that they have to choose/generate ids for each <action> accordingly, if they need to differentiate between messages.
In other terms, if an action depends on the message it was selected from, the id of the action should just include the id of such message. But as the example with merge shows, the id of the message might just be entirely irrelevant: The action with id merge-32643 might instruct the bot to merge the merge request 32642 and it doesn't matter if this action was sent as an action from the message that announced that the merge request with opened or from the message that announced it was reviewed. The id of the action is self-descriptive for the action, if it depends on the message, then to be self-descriptive, the id must reference the message. What is confusing to me IMO is that this is one XEP, where it clearly has two distinguished functionalities that could easily be completely independent XEPs. Marvin
Hi, thanks for the clarifications Marvin, you explained my intentions very well :) The use-case I had in mind for <response> is "memberbot asks me 20 yes/no questions in a row, would be cool if I could just click on yes or no buttons". This is purely assistive and requires no feature detection; the usual input is not blocked and you could still type out "yes" or "no" manually. Selecting one of the quick responses would just send the message as if you'd typed it out. A use-case for <action> is for example a Git bot that sends notifications about newly opened issues/pull requests and attaches actions to close/merge/etc. Those actions would stay attached to the message, so you could scroll up to older messages and trigger an attached action to e.g. close some issue.
Is the original Author still around?
Yes, I'm sorry for not showing this XEP more love after it was accepted as experimental, but I'm ready to pick up work on it again.
What is confusing to me IMO is that this is one XEP, where it clearly has two distinguished functionalities that could easily be completely independent XEPs.
I agree, it developed into two separate, barely related functionalities that could be split. Tim On 01.07.24 09:54, Marvin W wrote:
Hi Philipp,
I'm not the author, but I feel I can answer most of the questions.
On Sat, 2024-06-29 at 13:25 +0000, Philipp Hörist wrote:
Im not getting the difference between <response> and <action>. And the XEP makes no attempt to describe it. Quick responses are regular messages with a <body>. They are only available as a direct response to the very last message in a conversation. If the receiving client does not support quick responses, the user can just manually type in the response and quick responses sent from other devices are displayed as usual messages in the same way as they're displayed on devices that do support it.
In a user interface, I'd expect the following: - The buttons for quick responses only show as long as there was no message since the message they respond on (see rule 3 in business rules). They might be "attached" to the message or the chat input field. - Quick response availability does not prevent regular chat input. - Selecting a quick response button will behave largely the same as if the user typed the message of the quick response value in the chat input and sends it. - The quick response will be displayed as a regular message in the chat history.
Actions, in contrast, are not using a <body>. They can be sent at any later point as they are merely announced via the message, but not necessarily related to it. Receiving clients that don't support actions can't send them and don't see if other clients sent them.
In a user interface I'd expect the following: - The buttons for actions show infinitely (or, client-specific, after a timeout - this sounds like something that could also be announced with the <action>). They should be attached to the message itself and remain visible even after being selected. - Action availability does not prevent regular chat input. - Selecting an action will likely display somehow that the action was performed, but doesn't prevent any attempt to perform it again or any other action announced on the same message. (the ability to modify this behavior might be worth adding to the spec) - The action will not be displayed as a regular message in the chat. The bot on the other end will likely send a follow up message to indicate that the action was performed.
Now for <actions>, the id attribute is under specified, it seems essential to the whole thing working at all. Should this be a globally unique ID? Or at least unique per remote JID? The business rules have some section on this that IMO explain that very well:
Sending clients MUST keep in mind that they have to choose/generate ids for each <action> accordingly, if they need to differentiate between messages.
In other terms, if an action depends on the message it was selected from, the id of the action should just include the id of such message.
But as the example with merge shows, the id of the message might just be entirely irrelevant: The action with id merge-32643 might instruct the bot to merge the merge request 32642 and it doesn't matter if this action was sent as an action from the message that announced that the merge request with opened or from the message that announced it was reviewed. The id of the action is self-descriptive for the action, if it depends on the message, then to be self-descriptive, the id must reference the message.
What is confusing to me IMO is that this is one XEP, where it clearly has two distinguished functionalities that could easily be completely independent XEPs.
Marvin _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi, # Responses Thanks for the replies, i think i understand the <response> use case a bit bettter. I think this could make use of fallback text, which we can remove if the XEP is supported. Because its not needed that the body mentions the options again if we have buttons for it. But other than that i think its fine, altough it will be a bit akward to implement, sounds easy, but with rules like "only if its the last message" im sure its not that straight foward when implementing. # Actions On Mon, Jul 1, 2024, at 09:54, Marvin W wrote:
Sending clients MUST keep in mind that they have to choose/generate ids for each <action> accordingly, if they need to differentiate between messages.
Feels vague, basically says, whoever sends a message can do what he wants. I know already what my client users want to see - They want to know what message they already answered - They will answer messages from other devices, but want to see it on all devices I see no reason not to include the message id i answered to, this can only be beneficial. Its maybe not needed for the sender, but for clients to easily implement and provide nice GUI. I see already users complain on the client side, and we can tell every single developer of the sending code to set proper ids. So please lets just skip that, and add proper reference to the message. Every sender is free to ignore that information if they do not need it. But it is incredibly helpful on the client side to provide nice GUI. # Other things - Do we want to mix actions with responses? I hope not, but this should maybe mentioned in the XEP - Are there usecases for MUCs? I think only actions would theoretically work. I fear people will do voting with this. Im not sure if this spec is right for this use case. Regards
On 02.07.24 18:57, Philipp Hörist wrote:
Hi,
# Responses
Thanks for the replies, i think i understand the <response> use case a bit bettter.
I think this could make use of fallback text, which we can remove if the XEP is supported. Because its not needed that the body mentions the options again if we have buttons for it. An optional element that contains a version of the body without the options? Sounds good!
But other than that i think its fine, altough it will be a bit akward to implement, sounds easy, but with rules like "only if its the last message" im sure its not that straight foward when implementing.
# Actions
On Mon, Jul 1, 2024, at 09:54, Marvin W wrote:
Sending clients MUST keep in mind that they have to choose/generate ids for each <action> accordingly, if they need to differentiate between messages.
Feels vague, basically says, whoever sends a message can do what he wants.
I know already what my client users want to see
- They want to know what message they already answered - They will answer messages from other devices, but want to see it on all devices
I see no reason not to include the message id i answered to, this can only be beneficial. Its maybe not needed for the sender, but for clients to easily implement and provide nice GUI.
I see already users complain on the client side, and we can tell every single developer of the sending code to set proper ids.
So please lets just skip that, and add proper reference to the message. Every sender is free to ignore that information if they do not need it. But it is incredibly helpful on the client side to provide nice GUI. Agreed, I think it's fair to just always add a reference even if it's not needed directly by the action.
# Other things
- Do we want to mix actions with responses? I hope not, but this should maybe mentioned in the XEP Do you care as a client developer? I don't see a use-case for both things in one message, but if the developer of the chat bot wants to suffer, why not :D - Are there usecases for MUCs? I think only actions would theoretically work. I fear people will do voting with this. Im not sure if this spec is right for this use case.
I think responses in MUC would only cause chaos, maybe the XEP should just forbid that. Actions in MUC should be good though, I want actions to work in MUCs. Voting should be fine too as long as everybody is aware that the votes are not anonymous. Why do you think this XEP might not be right for voting?
Regards
_______________________________________________ Standards mailing list --standards@xmpp.org To unsubscribe send an email tostandards-leave@xmpp.org
Hi, On Mon, Jul 15, 2024, at 22:42, Tim Henkes wrote:
I think responses in MUC would only cause chaos, maybe the XEP should just forbid that.
Actions in MUC should be good though, I want actions to work in MUCs. Voting should be fine too as long as everybody is aware that the votes are not anonymous. Why do you think this XEP might not be right for voting?
I didnt think it through what would actually be necessary for a good voting functionality. I just wanted to know if it was considered by the XEP. I think voting is a think that deservs its own XEP and should not be an afterthought. For voting i think much more rules would be needed, like for example not accepting 2 votes from the same person, or interpet a different vote from the same person as correction, etc. Regards Philipp
I didnt think it through what would actually be necessary for a good voting functionality. I just wanted to know if it was considered by the XEP.
I think voting is a think that deservs its own XEP and should not be an afterthought.
For voting i think much more rules would be needed, like for example not accepting 2 votes from the same person, or interpet a different vote from the same person as correction, etc.
Voting (and polls) are actually something I thought about beforehand and wanted to have them covered by this XEP. My idea is that rules like the ones you mentioned are enforced by the voting bot and not the XEP. The XEP simply gives you a way to trigger an action - the voting bot would be the one to "execute" the action, including check whether the same person is trying to vote again and block that/make it a correction instead etc. Does that sound okay?
hi On Mon, Jul 15, 2024, at 23:17, Tim Henkes wrote:
Voting (and polls) are actually something I thought about beforehand and wanted to have them covered by this XEP. My idea is that rules like the ones you mentioned are enforced by the voting bot and not the XEP. The XEP simply gives you a way to trigger an action - the voting bot would be the one to "execute" the action, including check whether the same person is trying to vote again and block that/make it a correction instead etc.
Does that sound okay?
Actually no, sounds like it does not cover the most basic things i would expect from a voting functionality. 1. It should be possible for every user to create a vote, without the help of bots 2. The results should be able to be displayed live, not only at the end of a vote 3. Vote Correction, Voting for multiple options, etc should be a thing 4. Probably many other simple features other messengers provide with votes When you propose that this XEP should be used for voting, and that rules are enforced by a bot, what i see is 1. In a MUC with 500 users, people spamming the message archive with responses which everyone else will then download, although they cannot display them because they have no idea about the rules of the vote, because only the bot knows what counts 2. No client even has an idea that this is a vote, can only be guessed from the text by the user, not programmatically by the client, so no custom UI possible. 3. Answer from the bot is undefined, will it be simply the result as text message? Again not possible to do any kind of UI. If this really should be used for voting, the XEP does not add anything over what we have today. We currently can send whole XEP-0004 dataforms with every message and its well defined and implemented how dataforms are to be filled out and submitted. The actions part of the XEP is in essence a dataform with a single list field option. Regards Philipp
Hi,
Actually no, sounds like it does not cover the most basic things i would expect from a voting functionality. Thanks, you're right, this isn't the right XEP for voting. I'll still answer some of your points though that I don't agree with:
1. It should be possible for every user to create a vote, without the help of bots
At the time I created the XEP, this is how voting worked in Telegram, I don't think it's a major issue to depend on a bot to manage votes.
1. Vote Correction, Voting for multiple options, etc should be a thing
That's possible. There's nothing in the XEP that disallows running multiple actions, the bot could very well allow multiple votes or perform corrections.
1. Answer from the bot is undefined, will it be simply the result as text message?
Why should the bot answer anything? You select an action. That's it, protocol over. The bot sees that you've selected an action and does whatever it wants to do. Again, this is not to argue that actions are good for voting, you've convinced me that they aren't ^^ The idea of actions is to give quick and convenient access to things that could also be done outside of XMPP. The relevant business rule states: Actions SHOULD only be a quicker way to access a feature that could also be accessed using information in the message body. For example, a bot that notifies about a new merge request includes in its notification message body a link to the web interface where manual merging is possible. An action could offer a more convenient way to merge, without taking the route via the web interface. In summary, users of clients that don't support Quick Response SHOULD still have a way to manually trigger the action. That business rule makes sense I think and practically excludes voting as a use-case for this XEP. Thanks again, Tim
Regards Philipp
Hello, I responded yesterday to this message, but it seems that my mails are not accepted by this list, so i try again using the web interface. (i don't get any bounce message, i just see that my reply is not in the archive). So, here is a copy of my previous mail:
I think voting is a think that deservs its own XEP and should not be an afterthought.
For voting i think much more rules would be needed, like for example not accepting 2 votes from the same person, or interpet a different vote from the same person as correction, etc.
I did not read all mails from this thread, so maybe i am off topic. For the record, i just implemented a polling system in one of my project. It allows any MUC occupant to vote, with any client, just by sending "!1" (to vote for option 1). Votes can be "anonymous": if this option is set, the message will be bounced so that other occupants can't see the vote. An occupant can vote multiple times, but it will replace they previous votes. The poll is created using a form (XEP-0004). I did not write a XEP for now, i had no time. But i documented how it works, and i have a Prosody module that implements it, and a ConverseJS plugin that shows the poll. The technical documentation: https://livingston.frama.io/peertube-plugin-livechat/technical/polls/ The user documentation: https://livingston.frama.io/peertube-plugin-livechat/documentation/user/stre... You can test the feature here: https://videos.john-livingston.fr/p/livechat/room?room=c5d20adf-1088-4d40-bb... The prosody module: https://github.com/JohnXLivingston/peertube-plugin-livechat/tree/main/prosod... The ConverseJS plugin: https://github.com/JohnXLivingston/peertube-plugin-livechat/tree/main/conver... I plan to write the XEP some day. But, as i haven't the time these days, if someone else wants to write it, be my guess.
participants (4)
-
jbbr＠john-livingston.fr -
Marvin W -
Philipp Hörist -
Tim Henkes