[Standards] Proposed XMPP Extension: Quick Response

Marvin W xmpp at larma.de
Tue Apr 21 13:39:46 UTC 2020


On 4/21/20 2:32 PM, syndace at web.de wrote:
> Verbosity is something that may sometimes be desired, but sometimes
> duplicate or annoying. Take the example of the merge again: as soon as
> you select the "merge" action, the bot performs the merge and then
> probably sends a new notification, stating that the mr was merged. In
> that case, having a plaintext "Merge MR!3" would be duplicate and noisy.

The message would only be visible to legacy clients. Clients supporting
Quick Responses can detect that the message is indeed a Response/Action.

It probably is a good idea to add some sort tag to messages that are a
Response so that it is visible the body was created through button press
and not through text input.

In your example: If there would be no way to see the "Merge MR!3", how
would I know if the merge request was merged because of my message or
that it just happened through the web UI?

> Another example are polls: if you start a poll in a MUC with hundrets of
> users, you don't want hundrets of "+1"s or "-1"s to be spammed
> everywhere. Instead, when the poll ends, the bot would print a summary
> of the votes. Here the missing plaintext is a "feature".
Interesting example, because it sounds more like something typically
done using reactions and there was a lot of discussion if reactions
should have fallback or not already. IMO reactions shouldn't have a
fallback body, so if actions are used similarly to reactions, they also
shouldn't have a fallback body. However in that case you should probably
just use reactions ;)

You also mentioned MUCs, however the current ProtoXEP does not specify
any MUC behavior. I also don't think the proposed protocol can be used
in MUCs out of the box and requires actual changes
- How do you use quick responses when there is multiple people writing
messages that allow for quick responses?
- How do I know that a certain action is actually intended for a
specific bot in a MUC?

As there has been some discussion regarding the use of Forms instead:
Forms cannot be used to do what is proposed as Responses in the
ProtoXEP, but they can already do what is proposed as Actions. Maybe
just focus on the one thing in this XEP and not put two mostly
independent things in one XEP?


More information about the Standards mailing list