(inline) On 4/21/20 4:51 PM, Tim Henkes wrote: > The question here is, why make a difference between "legacy" clients and > clients with support? Why hide that an action was performed from users > with supporting clients and show that an action was performed to users > of "legacy" clients?
Well, supporting clients can display the "action was performed" information different from a normal message, just legacy clients can't. For example the supporting client could change the design of the button that represented the action to show that this button was pressed. Or the message could be formatted differently. Or... > This mixes things up I think. Messages that are triggered by an action > are always visible as such, because they contain an <action-selected> > element. Messages that are triggered by a quick response are not meant > to be anyhow differentiable from manually types messages. I as a client developer might want to display the fact that a message was triggered through Quick Response or not. Right now I can only do that as the sending client because the information is not preserved in carbons/MAM. IMO every information that exists locally should also be stored in MAM so that other devices can pick this information up. >> 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? > > Why do you want to know? In the example of a merge request it does not > matter at all, the action is just a quicker/more convenient way to > trigger the merge request in exactly the same way that would be possible > via the web interface. The bot could also just add "triggered by ..." to > its merge notification. Can you construct a scenario where this is > actually relevant? For a merge request it is highly relevant who merged it. I don't know any code management software that will not display that to you, except if you put effort into hiding it. > Thing is, if the bot defines the body to print when an action is > selected, the bot can just as well just print that message itself when > the action is performed. Take the following two options: > > *marvin selects action* > > marvin> /Merge MR!3 > > gitbot> MR!3 merged > > vs. > > *marvin selects action* > > gitbot> marvin triggered the merge of MR!3 > > > I don't see how the first variant would be superior to the second, keep > in mind that in both cases the bot fully controls what is printed, in > the first variant by setting the "fallback" body and in the second > variant by printing it directly. The second variant is superior if the reply from gitbot is not instantaneous. Let's say, the reply takes 10 seconds, I'd like to know that my message was send properly. And in a MUC I'd like others to see that I already did perform the action, so they don't need to do it as well. > Hehe true, simple polls could be handled with thumbs up or thumbs down > reactions, but polls with more options would require mapping emojis to > options etc. :D A poll bot could obviously offer more functionality, > like limiting the time for votes, printing cool summaries or even doing > stuff based on the result of the vote. Couldn't a bot do time limit, summaries and anything else also when the vote is based on reactions? And mapping to emojis is really straight forward given that there are the keycap emojis (1️⃣). I know a vote bot based on reactions exists for Slack. You just can't use reactions if you want votes to be private, in which case you also can't use this ProtoXEP (as everyone in the room can see which actions are performed by whom) - except if you do the voting in direct messages, in which case you can use reactions again. > Quick Responses are restricted to the last received message with a MUST, In that case, quick responses are effectively unusable in MUCs because someone could just send a message before you and therefor make it impossible for you to use a quick response. Also, if there is no indication in the message that a message is a quick reply, someone could maliciously use this XEP by having a response value that isn't related to the label at all. This can even be used to lure users into writing exactly the opposite (value="Yes", label="No"). So for quick responses, we might want to disallow having a label different from the value when in MUCs. Marvin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
