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