pep.> I find the current experimental XEP updating flow a bit weird.
Yep, it is not ideal that some big changes to experimental XEPs get merged without asking for feedback first
archas left
archas joined
jonas’
why?
jonas’
experimental XEPs shouldn’t be deployed either way :>
flow
doesn't matter, gathering feedback prior merge is still sensible as it potentially improves the XEP while avoiding frequent namespace bumps
jonas’
versions are cheap if nothing is deployed :)
flow
no they are not
Neustradamus
There is a problem to with inbox folder, there are not redirection to official XEPs...
jonas’
Neustradamus, Thanks! Now make a PR to fix it.
flow
I also question the sentiment that experimental XEPs shouldn't get deployed, at least for certain definitions of deployed. you obviously want to have them deployed in experimental setups
jubalhhas joined
Neustradamus
It is not up-to-date but I have listed here: https://github.com/xsf/xmpp.org/issues/421
xeckshas joined
stpeterhas joined
stpeterhas left
contrapunctushas joined
jonas’
Neustradamus, that’s an issue, not a PR.
archas left
Neustradamus
jonas’: I have said, I have listed ;)
jonas’
and I said we need a PR to fix it
jonas’
not an issue
jonas’
issues are worthless if there’s no one working on it.
jubalhhas left
contrapunctushas left
contrapunctushas joined
contrapunctushas left
sonnyhas left
contrapunctushas joined
stpeterhas joined
stpeterhas left
j.rhas left
nycohas left
nycohas joined
govanifyhas left
robertooohas joined
j.rhas joined
rionhas left
emushas joined
j.rhas left
j.rhas joined
eevvoorhas joined
rionhas joined
Maxhas left
Maxhas joined
goffihas joined
goffihas left
stpeterhas joined
stpeterhas left
goffihas joined
Steve Killehas left
Kevhas left
Steve Killehas joined
Kevhas joined
LNJhas left
sonnyhas joined
kevinhas joined
Danielhas left
Danielhas joined
stpeterhas joined
stpeterhas left
Maxhas left
Maxhas joined
eevvoorhas left
eevvoorhas joined
eevvoorhas left
jubalhhas joined
goffihas left
goffihas joined
kevinhas left
stpeterhas joined
stpeterhas left
jubalhhas left
eevvoorhas joined
alexishas left
alexishas joined
lovetoxhas left
stpeterhas joined
stpeterhas left
pep.
flow: I wasn't talking about namespace bumps, even though I disagree about jonas’' “nothing gets deployed”, it's really all just a waste of time for editors not to leave a short period of time here for authors to hear/incorporate feedback :(
mukt2has left
marc
MattJ: are you interested in the 401 discussion?
Zash
https://xmpp.org/extensions/xep-0191.html#example-9
This error you should get when you send a stanza to a JID you yourself have blocked, it should have an error/@by attribute of the account, right?
flow
pep., I know that you didn't talk about namespace bump, I just mentioned it as consequence of this. To be fair, even if editors would keep PRs open for longer period of time to gather feedback, your process does not make it easy to review the proposed changes
flow
Zash, I think there is no reason it couldn't have the 'by' attribute. I haven't read the spec if it is required thoguh✎
flow
Zash, I think there is no reason it couldn't have the 'by' attribute. I haven't read the spec if it is required though ✏
pep.
flow: agreed about the reviews
flow
pep., \o/ ;)
lskdjfhas joined
lskdjfhas left
krauqhas left
lovetoxhas joined
lskdjfhas joined
krauqhas joined
MattJ
marc [11:21]:
> MattJ: are you interested in the 401 discussion?
For sure!
pep.
if that's a public discussion I'll definitely read it :)
eta
can you use chat markers in MUC?
eta
I tried and the clients I'm using don't seem to care about the markers
marc
MattJ: didn't you get the invitation?
MattJ
Maybe, MUC invitation?
Zash
I tried sending you one too
MattJ
Not sure if yaxim supports them
MattJ
Or maybe my firewall rules
Zash
Ge0rG, fix it
pep.
eta: I think it's done in some conditions. I merged MattJ 's PR re 0333 in MUC. waiting for iteam to pull the updates
marc
MattJ: I tried to reinvite you :-/
eta
pep., oh right, apparently you might need to include the 'id' field in the <displayed/> element
eta
that's odd
eta
oh wait, nvm, you always do that
eta
pep., is there a link to that PR?
pep.
eta, https://xmpp.org/extensions/xep-0333.html#appendix-revs it's live now :)
pep.
https://github.com/xsf/xeps/pull/927 PR
eta
pep., oh, you need unique and stable stanza IDs
Ge0rG
Zash: fix what? MattJ's broken default firewall?
Ge0rG
I'm pretty sure I reviewed the rules and highlighted that they break MUC invitation an eternity ago
mukt2has joined
goffihas left
goffihas joined
stpeterhas joined
stpeterhas left
goffihas left
goffihas joined
sonnyhas left
sonnyhas joined
Neustradamushas left
Neustradamushas joined
xsfhas left
mukt2has left
stpeterhas joined
stpeterhas left
eevvoorhas left
jubalhhas joined
mukt2has joined
serge90has joined
serge90has left
serge90has joined
pdurbinhas left
serge90has left
serge90has joined
serge90has left
serge90has joined
serge90has left
serge90has joined
stpeterhas joined
stpeterhas left
Deephas joined
serge90has left
serge90has joined
MattJ
TIL `make preview` in xsf/xeps
Jeybehas joined
serge90has left
serge90has joined
marchas left
Jeybehas left
Jeybehas joined
mukt2has left
serge90has left
serge90has joined
jubalhhas left
marchas joined
serge90has left
serge90has joined
Jeybehas left
Jeybehas joined
werdanhas joined
stpeterhas joined
stpeterhas left
Jeybehas left
serge90has left
serge90has joined
Jeybehas joined
Jeybehas left
Jeybehas joined
serge90has left
serge90has joined
mukt2has joined
adiaholic_has left
adiaholic_has joined
serge90has left
serge90has joined
Bluehas joined
Jeybehas left
Jeybehas joined
jubalhhas joined
Jeybehas left
Jeybehas joined
Deephas left
rion
do we have unicode symbol for muc topic?
Jeybehas left
Jeybehas joined
serge90has left
Ge0rG
rion: you can sponsor one
serge90has joined
Ge0rG
👥🗩
Yagiza
Just read latest version of XEP-0333.
rion
sponsor? no idea how.
adiaholic_has left
Ge0rG
rion: https://wiki.xmpp.org/web/Adopt-a-Character
serge90has left
pep.
I don't think that's what he asked
serge90has joined
Ge0rG
there should be a way to pay the unicode consortium to add *new* characters.
adiaholic_has joined
Daniel
I'm sure there is
pep.
bribery?
pep.
lobbying?
Daniel
Little bit of both
Ge0rG
nah, they demand proof of importance or somesuch
pep.
Ge0rG, "My brand is very important!"
Ge0rG
kinda-sorta
goffihas left
Yagiza
It seems all the mentions about message type are removed. But section 8.1 says that "Only Messages that can be displayed in a chat SHOULD be markable".
serge90has left
serge90has joined
Yagiza
Does that mean that I should not set "type" attribute for a chat marker Message and if my client displays Normal message not in a chat but in a separate windows, I should no make Normal messages markable?
bearhas left
bearhas joined
Blue
That's actually a very sad thing about proof of importance. The wikipedia is into removing the article in russian about fediverse due to the lack of importance
mukt2has left
andyhas left
serge90has left
stpeterhas joined
stpeterhas left
serge90has joined
Jeybehas left
Jeybehas joined
Neustradamushas left
Neustradamushas joined
serge90has left
serge90has joined
jubalhhas left
andyhas joined
Jeybehas left
Jeybehas joined
serge90has left
serge90has joined
Jeybehas left
Jeybehas joined
serge90has left
serge90has joined
Jeybehas left
Jeybehas joined
serge90has left
vanitasvitaehas left
serge90has joined
MattJ
Yagiza, I'm not sure I understand. I made the last update to the XEP, I didn't remove anything, I only added.
Yagiza
MattJ, I know. It seems that part was removed before your last update.
jubalhhas joined
mukt2has joined
MattJ
Yagiza, I don't see any such changes
MattJ
It looks like it has all been typo fixes and state changes since 2013
serge90has left
eevvoorhas joined
serge90has joined
MattJ
Yagiza, hmm. Are you maybe confusing it with XEP-0085: Chat State Notifications?
MattJ
That one discusses types
vanitasvitaehas joined
serge90has left
Jeybehas left
serge90has joined
Jeybehas joined
Maxhas left
SamWhitedhas joined
Maxhas joined
SamWhited
Quick question to get an overview of what people here think: When writing https://xmpp.org/extensions/inbox/password-storage.html I specified that SCRAM should be used because RFC 6120 mandates it anyways. However, I tend to think it would be better to start phasing it out and just using PLAIN, so maybe it's best if I don't add requirements for SCRAM-SHA-256. What do people think?
Holger
I'm all for it but am not sure you'll easily get a consensus on that 😉
serge90has left
serge90has joined
jonas’
SamWhited, I think this should be an RFC
SamWhited
The main reasons I consider PLAIN to be a better option are that it makes the password hash more agile (it's easy to update it to use a new hash, or a higher workfactor on login), it makes it so that server policy can contain password requirements like a minimum length and have a blacklist of common passwords (eg. it can reject "passw0rd", etc.)
jonas’
not a XEP
Zash
Can an Informational XEP even make such demands?
jonas’
it’s not really specific to XMPP, is it?
SamWhited
jonas’: I disagree, those are too hard for us to update regularly.
Jeybehas left
SamWhited
Zash: it's just recommendations. I did feel that RFC 2119 language was important to distinguish the importance of various bits of the XEP, but at the end of the day it is informational
Zash
> start phasing [SCRAM] out and just using PLAIN
Strongly disagree
stpeterhas joined
stpeterhas left
Holger
One downside is that hash recalculation is expensive so more prone to DoS.
Zash
I'd rather get rid of PLAIN and use only SCRAM
andyhas left
SamWhited
Zash: why? As far as I can tell PLAIN is much better in all the ways that really matter (eg. in terms of common attacks that can be prevented). The property of not sending the actual password to the server is kind of nice, but also that isn't where passwords are normally attacked
SamWhited
Holger: that's a fair point, but then again web servers always seem to manage to do it okay
Zash
So strong is my disagreement that I can't put it into words
Zash
SamWhited, you mean we should switch to OAuth?
Yagiza
MattJ, yes, maybe
Ge0rG
Sending passwords to the server requires storing them on the client though, and this is a very common stealing vector.
SamWhited
Ge0rG: also a good point, adding that to my pros/cons list
Zash
"The web does it" is not an argument that's going to work on me.
Zash
Not unless it's "bring back XHTML-IM"
Ge0rG
OTOH, you need to store _something_ on the client, and that will be usable to login to xmpp. However, it won't be usable to login into your Gmail
jonas’
but surely everyone uses separate credentials for all the things!!k
Zash
SCRAM lets you store some magic hash on the client and login with that.
SamWhited
It's not an argument for "we should do it because we need to do what the web does", it's a counterpoint that it doesn't seem to lead to DOS' in practice
Zash
Without doing the *expensive* PBKDF2 operation again
Zash
And without the server doing that either
Ge0rG
Mmmhmmm! Magic hash!
Zash
Just like 5 hash operations and some XOR magic and you're golden
Zash
Even if you set the iteration count to a larger number than I'll bother typing out
serge90has left
serge90has joined
vanitasvitaehas left
L29Ahhas joined
vanitasvitaehas joined
SamWhited
So rehashing may be expensive, and that's sad, but it's not a security issue so I'm not sure how much I care (unless there were literally no other common security issues to worry about). Requiring plaintext on the client is one, so I guess the question is: is that more common than not being able to set a password policy on the server or passwords being broken because SCRAm provides no agility for hashes and work factors
andyhas joined
serge90has left
serge90has joined
SamWhited
My guess is that the latter are much more common. In particular, letting servers define a blacklist (no "passw0rd", "aaaa", a dump downloaded from a recent <common web service> breach, etc.) is probably the biggest single way people break into accounts
Zash
This is why we need SASL2, which was supposed to provide credential upgrades and the like.
SamWhited
Yah, if we could at least get that problem solved it would be good. Not being able to set server policy seems much more dangerous than anything else though, and I think that's just not solvable with SCRAM.
SamWhited
I suppose I could mandate that clients all have a policy for disallowing common passwords and what not ("mandate" meaning "if you're following this XEPs advice, do this please", of course)
SamWhited
But that feels wrong and less likely to be widely adopted.
Zash
It's not solvable with SCRAM doesn't mean SCRAM needs to go.
Zash
It's not like you send SCRAM hashes from the client to register or change password, all that's by sending the plain text already.
SamWhited
Ahh, that's a good point that I was stupidly forgetting.
SamWhited
Okay, so maybe it's just the agility thing and promoting SASL2 is the way to go
Zash
The pains with upgrading to SCRAM-SHA-256 is more implementation issue and that you need the plain text password again
Ge0rG
Zash: did you just say PLAIN auth? :D
Zash
no
andyhas left
andyhas joined
Zash
I mean Corporate Enterprise Mandatory Password Change Policy
SamWhited
Okay, thanks, that's what I needed to get out of this. I'm convinced for now; leaving it as is. Thanks for sanity checking me (and finding me insane)
serge90has left
j.rhas left
SamWhited
I should re-read SASL2. Did an experimental implementation of it when it came out, but I don't recall the details.
serge90has joined
jonas’
I still need convincing that this is a thing concerning XMPP specifically
SamWhited
Does it provide a way to force reset passwords? That seems like the most important thing to me
SamWhited
jonas’: it's not concerning XMPP specifically
jonas’
why is this a XEP then?
jonas’
an XMPP Extension Proposal document
Zash
You need some signal to say "hey, password change time", if you receive the password encoded in SASL PLAIN doesn't matter
Zash
Without letting clients fall victim to MITM
SamWhited
jonas’: because the XSF is in a position to make recommendations for the public jabber network and it's much better if people can get them in one place instead of all over the place and specific bits of it may be specific and common problems when implementing things for the Jabber network, eg. how to handle PLAIN alongside SCRAM-SHA-1 which are both mandated by RFC 6120)
SamWhited
that's not true, PLAIN isn't mandated by 6120 IIRC, but it's common to implement in Jabber alongside SCRAM-SHA-1 for compatibility with the widest range of clients, so having a recommendation for how to do that is good.
SamWhited
Another example is the PBKDF2 iteration count. Right now most people use 4096 which is rather outdated (NIST and OWASP recommend 10000). If you look around on the web you'll find a mix of recommendations for various numbers, but which one applies to the Jabber network? Is it a low security environment or a high security environment? Should I use 4096, 10k, or 100k?
serge90has left
pep.
Zash, any clues of how to use Coporate Enterprise Mandatory Password Change sasl policy without sending PLAIN? or was PLAIN assumed
serge90has joined
SamWhited
This document clarifies that, even though you're right, technically PBKDF2 iteration count isn't specific to jabber.
pep.
I know corporate setups can require password policies, but I'd prefer encouraging SCRAM also fwiw, even during account creation/password change (where it's not used atm)
alexishas left
pep.
Ideally I'd use client certs, but for now we all have to deal with passwords..
SamWhited
pep. you can't mandate it during password change or you lose the ability to be agile and then when your password hashing mechanism is broken all your users get their passwords stolen. This is *much* worse than the server getting your password once in a blue moon.
pep.
once and for all you mean
pep.
Not entirely sure what you mean by not being able to mandate it during password change
SamWhited
You can't mandate using SCRAM or something during password change, like you were suggesting, I mean.
pep.
Ah otherwise I can't rehash myself
alexishas joined
SamWhited
Hash and work factor agility is the most important thing, in my mind. Right now we don't have that and it's a major problem.
SamWhited
However, if SASL2 provides a way to say "you have to reset your password" or "you need to rehash with this iteration count and HMAC hash" that solves the problem nicely in my mind.
serge90has left
pep.
But via requiring another channel I can clear the hash/password altogether and for a reset via that other channel
serge90has joined
SamWhited
pep.: didn't understand that bit about another channel, sorry?
pep.
email etc.
Zash
If SASL2 lets you say "reset your password please" *after* you authed, then it's better than forcing PLAIN auth.
alexishas left
SamWhited
Zash: right, definitely after auth :)
pep.
But yeah I would prefer what Zash just said
Zash
Then you can use SCRAM mutual auth magic to be sure you're giving the new password to someone who knew your previous password
Kev
*once* knew, I think.
j.rhas joined
SamWhited
Anyways, got what I needed. Ping me via PM or email or something if you have more suggestions for the best practices doc. Thanks again!
pep.
SamWhited, questions on IBR2
SamWhited
pep. good timing, I was just about to /part. What do you need?
stpeterhas joined
stpeterhas left
pep.
You specify a way to do the register procedure via <iq>, does that mean I can register an account after bind? Or is it specifically for components?
serge90has left
serge90has joined
SamWhited
pep. yah, that all needs to be flushed out a bit more. The idea was to make it compatible with components, but sure, if you're an admin and want to register some accounts for somebody it could be used to make that possible after bind
SamWhited
We'd probably want to add a discovery mechanism for that though so that servers could decide whether to implement it or not. And it should probably be ad-hoc based instead, but I'm not sure if that should all go in this XEP or a separate one.
pep.
ok
SamWhited
Bye for real now; thanks again for the discussion on PLAIN v SCRAM!
SamWhitedhas left
serge90has left
serge90has joined
andyhas left
serge90has left
jonas’has left
serge90has joined
jonas’has joined
andyhas joined
alexishas joined
serge90has left
serge90has joined
werdanhas left
serge90has left
serge90has joined
Shellhas left
andyhas left
Maxhas left
Maxhas joined
serge90has left
serge90has joined
andyhas joined
serge90has left
serge90has joined
andrey.ghas left
serge90has left
goffihas joined
serge90has joined
bearhas left
serge90has left
serge90has joined
Jeybehas joined
serge90has left
serge90has joined
serge90has left
serge90has joined
Neustradamushas left
Neustradamushas joined
serge90has left
serge90has joined
Nekithas left
serge90has left
serge90has joined
mukt2has left
eevvoorhas left
adiaholic_has left
adiaholic_has joined
murabitohas left
pdurbinhas joined
serge90has left
serge90has joined
lovetoxhas left
mukt2has joined
adiaholic_has left
adiaholic_has joined
pep.
Is there a way to maybe break the fork relation between linkmauve/memberbot and xsf/memberbot?
pep.
So I get suggested by default to PR against xsf/memberbot
serge90has left
pep.
And github is sloooooow
serge90has joined
pep.
"We are investigating degradations to GitHub.com."
pep., you can ask github to change the primary repo
flow
i've done that in the past
flow
simply write them a mail
pep.
you can do that with a simple click in gitlab :/
serge90has left
lovetoxhas joined
serge90has joined
pep.
Also I'm no owner of that repo so maybe they will just tell me off
pep.
MattJ, ^ (?)
bearhas joined
jonas’
I don’t seem to wield power on that repo either.
serge90has left
serge90has joined
Vaulorhas left
Sevehas left
lovetoxhas left
jubalhhas left
serge90has left
serge90has joined
Sevehas joined
Vaulorhas joined
serge90has left
serge90has joined
serge90has left
serge90has joined
Shellhas joined
serge90has left
serge90has joined
serge90has left
serge90has joined
Ge0rG
!XSF_Martin [18:51]:
> Why GIF?
The patent has expired. GIF is free now!
Yagizahas left
serge90has left
serge90has joined
Mikaelahas left
Mikaelahas joined
!XSF_Martinhas left
!XSF_Martinhas joined
!XSF_Martinhas left
!XSF_Martinhas joined
serge90has left
serge90has joined
pdurbinhas joined
govanifyhas joined
serge90has left
serge90has joined
pdurbinhas left
serge90has left
serge90has joined
serge90has left
serge90has joined
serge90has left
serge90has joined
debaclehas joined
alexishas left
serge90has left
serge90has joined
lovetoxhas joined
serge90has left
serge90has joined
Shellhas left
Shellhas joined
serge90has left
serge90has joined
LNJhas joined
Marandahas left
Marandahas joined
Shellhas left
xeckshas left
jubalhhas joined
serge90has left
serge90has joined
Shellhas joined
Shellhas left
xeckshas joined
lovetoxhas left
serge90has left
serge90has joined
werdanhas left
serge90has left
serge90has joined
Danielhas left
Danielhas joined
Jeybehas left
Jeybehas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
serge90has left
Maxhas left
serge90has joined
Maxhas joined
jubalhhas left
serge90has left
serge90has joined
werdanhas joined
serge90has left
serge90has joined
serge90has left
serge90has joined
eevvoorhas joined
serge90has left
serge90has joined
Mikaelahas left
MattJ
I've sent Github a request
pep.
Thanks! :)
serge90has left
serge90has joined
stpeterhas joined
stpeterhas left
mukt2has left
pep.
These should be easy changes:
https://github.com/xsf/memberbot/pull/2
https://github.com/xsf/memberbot/pull/3
serge90has left
serge90has joined
yohas joined
mukt2has joined
yohas left
serge90has left
serge90has joined
pdurbinhas joined
serge90has left
serge90has joined
werdanhas left
serge90has left
serge90has joined
jubalhhas joined
lovetoxhas joined
adiaholic_has left
adiaholic_has joined
Danielhas left
Danielhas joined
serge90has left
serge90has joined
pdurbinhas left
Shellhas joined
serge90has left
serge90has joined
mukt2has left
mukt2has joined
Danielhas left
Danielhas joined
Nekithas joined
mukt2has left
Shellhas left
Shellhas joined
mukt2has joined
DebXWoodyhas left
serge90has left
serge90has joined
adiaholic_has left
adiaholic_has joined
Danielhas left
Danielhas joined
serge90has left
serge90has joined
jubalhhas left
Danielhas left
Danielhas joined
robertooohas left
serge90has left
Danielhas left
Danielhas joined
serge90has joined
Danielhas left
Danielhas joined
MattJ
That email came out longer than I planned
Syndace
Awesome, thanks!&
Shellhas left
Shellhas joined
serge90has left
Syndace
I'm a little surprised that you don't see a difference between responses and actions, maybe I'm still missing something important. I think the two use-cases of memberbot and and mercurial (:D) bot are already an example of why these two are separate, aren't they? One of them you only want for the last message, the other you want for all (or more) messages. One of them you want with backward compatibility using only plaintext, the other one you want with unique ids so that multiple messages are flexibly possible.
serge90has joined
Danielhas left
Danielhas joined
waqashas joined
Danielhas left
Danielhas joined
mukt2has left
mukt2has joined
lovetoxhas left
Danielhas left
Danielhas joined
Syndace
You could merge both and then define that responses that define a body may only be available on the most recent message.
lorddavidiiihas left
lorddavidiiihas joined
Syndace
I'd imagine you'd end up with a set of rules that depend on the body to be there or not, essentially splitting the merged element based on that. But that might just be wrong?
serge90has left
serge90has joined
serge90has left
serge90has joined
serge90has left
serge90has joined
Danielhas left
Danielhas joined
Jeybehas left
Jeybehas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
serge90has left
serge90has joined
serge90has left
etahas left
etahas joined
serge90has joined
serge90has left
MattJ
I don't think I necessarily agree that actions can't have a body
MattJ
"!merge 245" seems like a good example
serge90has joined
emushas left
alexishas joined
pep.
"merge !245" :p
Zash
!merge !245
Zash
!merge!!245!!!
pep.
hmm I wasn't even picturing "normal" bot commands using this tbh
pep.
In general I'd also prefer bots to use ad-hoc I think
Zash
in muc?
pep.
dunno, it just rejoins my usual rants about semantics in body :P
pep.
Even though with a bot you can generally make that more obvious and slightly restricted
serge90has left
serge90has joined
serge90has left
serge90has joined
MattJ
When one of the people proposing forms or ad-hoc commands goes and implements either in one of the mobile clients in a nice way, I'll listen
Zash
Shall I dig up my Buttons implementation?
Zash
Had a working prototype hacked up in JabberCat back when I wrote the protoxep
Syndace
> "!merge 245" seems like a good example
It is a good example, there is no reason to forbid this. But how to handle this cleanly. Have an "unique" flag on each <response>, if set allow selecting the response even if it's not the most recent message, if not set limit to the most recent message?
Syndace
Or actually, my argument was that a bot can totally still accept this, just that there is no button for it
serge90has left
serge90has joined
Syndace
The button would say "merge" and send an <action-selected> with the corresponding id, the bot could obviously still accept a manually written "!merge 45"
MattJ
Sure. But I see no reason to hide the button either
MattJ
And as noted there is UX weirdness if buttons just disappear
Syndace
No it wouldn't be hidden, just the button would not generate the "!merge 45" output
MattJ
Why not?
Syndace
No hard reason. It probably doesn't have to, because the mercurial bot will send a "45 merged by foo" notification as soon as you click "merge"
Zash
MattJ, question about room activity indicators: Is it supposed to only work while the client is online?
MattJ
Yes
MattJ
Which is why it uses presence
Zash
Mhm
serge90has left
serge90has joined
wurstsalathas left
Syndace
My idea was that the bot knows best when to print stuff and when not to. Thus the action buttons would not print anything, because the bot can just do so with much finer control.
MattJ
That's kinda my reasoning for giving it the decision about whether there should be a <body> in the user response
pep.
MattJ, I'm not really thinking about mobile right now :)
emushas joined
pep.
definitely not my main use-case
MattJ
pep.: non-mobile is not this protocol's main use case... console users are used to typing ;)
pep.
But accepting and having this buttons xep being used does bring "concerns"
pep.
As dwd said
MattJ
"concerns"
pep.
> So I can see that these are useful, but I'm worried they'll end up baking in a data-as-text-body construction which is less than ideal, and tricky to move away from.
Nekithas left
Nekithas joined
Zash
So much text
MattJ
Sorry, but that's what we have today
pep.
Yeah and I don't like that either :/
serge90has left
serge90has joined
MattJ
I know you would like to replace all text messaging with semantic XML
MattJ
But users don't care, sorry
pep.
Users don't have to know, as usual
Syndace
Take the following scenario: a bot for voting. The votes of some members count double, for whatever reason. Now the bot could decide to only print votes of these double-weighted voters, and hide all single-weighted votes to prevent spam. While a little theoretical, that would only possible if the body isn't fixed in the <response>.
Tobiashas left
MattJ
Sure, so it sets unique ids, no body, and echoes whatever it wants whenever it wants
pep.
(fwiw, dave's quote here is a borderline argument in favour of XHTML-IM. I note :p)
Syndace
The bot would decide what goes into the body. So why not just have the bot do the printing itself?
Sevehas left
MattJ
I think in most cases it will flow nicer if the response comes from the user rather than the bot. But I agree it depends on the use case
etahas left
etahas joined
MattJ
Feels borderline security-ish too
MattJ
Seeing Ralph write "+1" in a meeting is more reliable than seeing a not write "Ralph said +1"
Syndace
Having the bot specify text that appears to be from the user?
MattJ
Not == bot, my phone refuses to recognise the word
serge90has left
Syndace
Oh, I guess both directions can appear borderline security-ish :D
serge90has joined
pep.
I'm sure ralph would be able to correct that itself if it happened
Syndace
Clicking on "yes" and having "no" appear in the chat because the bot defined it that way is also weird
MattJ
True, that is definitely a consideration
Jeybehas left
Jeybehas joined
MattJ
Agreed, no UI should send a body the user isn't aware of
Syndace
okay. That's an argument for
a) removing labels from (what is now) <response>
b) not adding a body to (what is now) <action>
MattJ
But you have to trust the bot either way
MattJ
Otherwise it will just echo the "wrong" thing
serge90has left
serge90has joined
Syndace
yes, you'd have to clarify that then followed by kicking the bot from the MUC :P
Zash
Could recommend showing it in UI like "Merge (sends "merge #123")" or somesuch.
Zash
or something something descriptions
serge90has left
serge90has joined
Jeybehas left
xsfhas joined
Syndace
I'd like to avoid mandating such kinds of UI details, though if you want something like that super hard I won't veto
serge90has left
serge90has joined
Syndace
I think the cleanest thing we can do is:
- Have buttons for plaintext responses display exactly what they will send
- Have buttons that trigger actions display what the action does
Zash
Yeah, protocol specifications should stay away from UI design, tho offering suggestions is fine.
paulhas left
MattJ
There is plenty of precedent for UI requirements in security considerations ("This piece of information MUST be clearly visible to the user")
Zash
I'm going to default to "that's silly"
MattJ
Syndace, makes sense I think
MattJ
But we still need to figure out visibility I think
MattJ
e.g. now if I wanted to make an in-MUC voting bot, and I wanted to make quick responses for +1/-1, I can't detect what they are in response to
serge90has left
MattJ
Those kinds of buttons would need to be hidden if the bot sent a new voting item
Syndace
I imagined that the (action) buttons would be displayed right with the message they belong to
MattJ
and then people with clients that don't do actions can't vote?
MattJ
or they have to manually type +1 now, and we aren't able to offer them quick responses on mobile
Syndace
they could only vote via +1/-1 for the newest vote then, yes
Zash
Unless! <delay/> tag something something
MattJ
Let's keep the awkward <delay/> tag out of it :)
Syndace
oh you're talking about clients that support only the quick response subset of the xep?
Zasheyes `~/src/xeps/origin-timestamps.md`
Syndace
i.e. not the actions thing
MattJ
No, I'm working on the assumption that clients would implement the whole thing
MattJ
But probably not explaining myself well, tired
Syndace
Okay. Then if actions are used for +1/-1, people with supporting clients could also vote for older items. Which the bot would and should probably prevent. People with clients that don't support would have to manually type +1/-1 and have it count only to the most recent vote item
MattJ
Yeah, you're right
serge90has joined
serge90has left
serge90has joined
Zash
That's usually not how voting works tho
goffihas left
Syndace
There is a third option which is not covered currently: a quick response that is not limited to the most recent messrage, but maybe until it is explicitly ended.
MattJ> !vote
votebot> vote started.
*+1 and -1 quick responses appear for everybody*
someone> +1
anotherone> -1
MattJ> !done
votebot> vote done.
*quick responses disappear for everybody*
mukt2has left
MattJ
I worry about adding work for clients
MattJ
But indeed, that is a possible solution
Syndace
yeah, that would probably be complicated.
Zash
`<in-reply to="xmpp:id"/>`
MattJ
(removing the merge button after merging a PR would be great)