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 -- [email protected] To unsubscribe send an email to [email protected]
