29 Jun
2024
29 Jun
'24
3:25 p.m.
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.
1 Jul
1 Jul
9:54 a.m.
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
1:32 p.m.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
2 Jul
2 Jul
6:57 p.m.
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:
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
Sending clients MUST keep in mind that they have
to choose/generate
ids for each <action> accordingly, if they need to
differentiate
between messages.
15 Jul
15 Jul
10:42 p.m.
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:
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.
Sending clients MUST keep in mind that they have
to choose/generate
ids for each <action> accordingly, if they need to
differentiate
between messages.
# 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(a)xmpp.org
To unsubscribe send an email tostandards-leave(a)xmpp.org
11:01 p.m.
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
11:17 p.m.
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?
16 Jul
16 Jul
7:51 p.m.
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
18 Jul
18 Jul
11:06 a.m.
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
11:49 a.m.
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/str…
You can test the feature here:
https://videos.john-livingston.fr/p/livechat/room?room=c5d20adf-1088-4d40-b…
The prosody module:
https://github.com/JohnXLivingston/peertube-plugin-livechat/tree/main/proso…
The ConverseJS plugin:
https://github.com/JohnXLivingston/peertube-plugin-livechat/tree/main/conve…
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.
126
days inactive
145
days old
9 comments
4 participants
participants (4)
-
jbbr＠john-livingston.fr -
Marvin W -
Philipp Hörist -
Tim Henkes