An optional element that contains a version of the body without the options? Sounds good!
# 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.
Agreed, I think it's fair to just always add a reference even if it's not needed directly by the action.
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.
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
# 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.
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 to standards-leave@xmpp.org