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