XSF Discussion - 2019-03-07

alameyo has joined 00:05:53
larma has left 00:09:39
larma has joined 00:09:40
efrit has left 00:15:17
Zash has left 00:15:45
dwd has joined 00:16:50
moparisthebest has left 00:17:47
moparisthebest has joined 00:18:17
Zash has joined 00:25:14
dwd has left 00:25:31
dwd has joined 00:25:32
UsL has left 00:30:30
UsL has joined 00:30:30
dwd has left 00:33:32
dwd has joined 00:44:49
dwd has left 00:56:48
!xsf_Martin has left 00:56:48
dwd has joined 00:56:48
alameyo has left 00:56:58
dwd has left 00:57:32
ThibG has left 00:59:17
alameyo has joined 01:02:22
dwd has joined 01:03:30
dwd has left 01:09:40
dwd has joined 01:09:40
dwd has left 01:21:32
tux has left 01:35:26
tux has joined 01:35:28
dwd has joined 01:45:18
dwd has left 01:48:56
dwd has joined 01:48:56
lorddavidiii has left 01:51:38
lorddavidiii has joined 01:51:40
lorddavidiii has left 01:52:06
lorddavidiii has joined 01:52:21
dwd has left 02:00:32
Zash has left 02:02:01
larma has left 02:02:10
j.r has left 02:03:00
j.r has joined 02:03:13
debacle has left 02:21:53
dwd has joined 02:21:54
waqas has joined 02:29:36
lskdjf has left 02:38:09
neshtaxmpp has left 03:00:59
neshtaxmpp has joined 03:01:00
dwd has left 03:13:29
dwd has joined 03:13:29
dwd has left 03:15:32
dwd has joined 03:24:06
ThibG has joined 03:26:22
contrapunctus 03:32:00
flow: I agree, XEP names are easier to remember than numbers
alacer has left 03:37:02
oli has left 03:39:00
contrapunctus 03:40:31
~~(Funny that this has to be argued with with people who advocate JIDs over phone numbers 😉)~~ ✎
contrapunctus 03:40:44
(Funny that this has to be argued with with people who advocate JIDs over phone numbers, for the same reasons 😉) ✏
dwd has left 03:44:23
dwd has joined 03:44:24
dwd has left 03:45:32
dwd has joined 03:50:56
Maranda has left 03:52:30
Maranda has joined 03:52:32
lorddavidiii has left 04:07:50
lorddavidiii has joined 04:08:06
dwd has left 04:08:36
dwd has joined 04:08:36
dwd has left 04:09:32
dwd has joined 04:29:28
alacer has joined 04:30:38
Nekit has joined 04:37:04
pep. 04:48:46
wurstsalat: it is already?
alacer has left 04:53:48
dwd has left 04:55:32
dwd has joined 04:55:33
dwd has left 04:57:32
waqas has left 05:07:46
Maranda has left 05:07:56
Maranda has joined 05:07:57
dwd has joined 05:08:47
rion has joined 05:16:31
dwd has left 05:30:45
dwd has joined 05:30:46
dwd has left 05:33:32
dwd has joined 05:41:20
dwd has left 05:47:52
dwd has joined 05:47:52
404.city has joined 05:50:41
404.city has left 05:55:34
oli has joined 05:55:48
dwd has left 05:57:32
vaulor has joined 06:01:19
arc has left 06:04:29
arc has joined 06:04:30
mark has joined 06:05:04
dwd has joined 06:08:47
blabla has left 06:13:18
blabla has joined 06:13:34
j.r has left 06:14:43
j.r has joined 06:16:25
dwd has left 06:20:35
dwd has joined 06:20:36
dwd has left 06:21:32
wurstsalat has left 06:26:24
Nekit has left 06:34:39
Nekit has joined 06:34:41
oli has left 06:34:43
oli has joined 06:34:45
lnj has joined 06:40:35
arc has left 06:45:04
arc has joined 06:45:10
dwd has joined 06:54:12
goffi has joined 06:58:07
Maranda has left 06:58:34
Maranda has joined 06:58:34
Zash has joined 07:00:09
andy has joined 07:11:14
karoshi has joined 07:12:51
dwd has left 07:32:21
dwd has joined 07:32:22
dwd has left 07:33:32
oli has left 07:35:04
oli has joined 07:35:06
Steve Kille has left 07:36:06
dwd has joined 07:39:45
ThibG has left 07:47:47
ThibG has joined 07:47:53
lnj has left 07:47:56
Steve Kille has joined 07:49:02
Maranda has left 07:50:18
Maranda has joined 07:50:50
Kev has joined 07:55:41
ThibG has left 07:56:29
ThibG has joined 07:56:34
Ge0rG 08:03:40
Wow, the bikeshedding has started! :D
pep. 08:04:35
I hope so
dwd has left 08:06:49
dwd has joined 08:06:51
pep. 08:12:27
I'm getting fed up with the "let's use <body/> for non-supporting clients". Also the non-spec'd bits of 0066 that say body = oob is the kind of crap that makes it impossible to comment on a picture when sending it.
oli has left 08:12:31
pep. 08:13:16
Re non-supporting clients, Conversations doesn't display part/joins, which removes context and makes the conversation hard to understand for some. Should I advertize the fact that I joined a room in <body/>?
pep. 08:13:27
As well as when I part
pep. 08:13:50
(I mean, my client, automatically)
jonas’ 08:14:27
I think there’s a difference between a client deliberately not supporting something and a client which hasn’t gotten around to implement something yet
pep. 08:14:42
"screw pidgin"? That's my thoughts
jonas’ 08:15:09
screw pidgin sounds like a plan
pep. 08:15:40
jonas’, I think the line is pretty thin nonetheless
jonas’ 08:15:45
it is
jonas’ 08:16:05
I’d say though, anything which makes users lose actual content is non-negotiable
pep. 08:16:53
What is "actual content"
Ge0rG 08:16:55
reminds me of the previous bifröst version that only put the filename into the body, not the full URL, so I had to grep my raw XML logs for it.
jonas’ 08:17:17
pep., message bodies. for example, it would be non-acceptable if XHTML-IM did not specify a plain-text <body/> fallback.
jonas’ 08:17:41
or what Ge0rG says
pep. 08:17:59
I say actual content goes further than that tbh. Context is as much important to me than the message
Ge0rG 08:18:13
yeah, there should always be graceful fallback to <body> for legacy clients. The other side of the medal being a wording in a XEP that allows complying clients to remove the body without losing info
jonas’ 08:18:21
pep., it’s a minimum, not an absolute definition
dwd has left 08:18:32
pep. 08:18:34
That's why I still put up with part/join noise from Android
pep. 08:18:41
Or iOS
Ge0rG 08:18:58
pep.: what's your point re 0066?
pep. 08:19:02
(and I can tell you it's ugly)
pep. 08:19:53
Ge0rG, body = oob is less than optimal. I can already do that better in xhtml-im tbh.
pep. 08:20:05
Better
pep. 08:21:11
<p>Foo <img src="https://bar/baz.png"/> look at my picture!</p>
Ge0rG 08:21:52
pep.: there was a section in my mail starting with "While XEP-0066 is less than ideal" :P
pep. 08:22:04
But you're still pushing for it
Ge0rG 08:22:30
pep.: and your counter-proposal is "Use XHTML-IM for inline media"?
pep. 08:22:45
That's one of the counter-proposals I guess yes
pep. 08:23:04
SIMS is another obvious solution
dwd has joined 08:23:15
Andrew Nenakhov 08:23:52
Sims?! That uglyness based on yet another markup principle?
Ge0rG 08:24:44
pep.: there are two ways how CS can be used. Either we use it to tell developers which XEPs we want them to adopt to make XMPP great, or we use it to tell developers which XEPs they should implement to make their clients interoperable with the current status quo. Last time I checked it was the latter.
pep. 08:24:44
?
pep. 08:24:53
(that was for Andrew Nenakhov)
pep. 08:25:30
In any case I agree with daniel's point. It's not the time anymore
pep. 08:26:07
And hmm, I'm not entirely sure that's what's actually perceived re CS
Ge0rG 08:28:47
Andrew Nenakhov: while I appreciate your brevity, you might want to elaborate why you disapprove of it in a longer form, on the ML, in a separate message.
Andrew Nenakhov 08:29:29
Because it is based on yet another markup principle, which is silly and unnecessary for IM
Andrew Nenakhov 08:30:38
We do need a method to pass additional data and multiple files/images/documents/etc in one stanza but trying to pretend that we need to do it in html like way with marking up body is not a good idea
Guus 08:31:35
pep. I don't quite agree it's not the time anymore. I welcome everyone to discuss this further, in the understanding that any outcome will go in the 2020 suite.
Andrew Nenakhov 08:31:44
We came up with a simple use of xep-0221 media element, however probably should just unwrap that media element from form tag - some old clients react not ideally on forms
Ge0rG 08:31:49
Andrew Nenakhov: I don't see any body markup in the XEP, besides of the XHTML-IM example, where it's obviously appropriate
Guus 08:31:53
(let's not wait discussing things, which will only delay 2020)
pep. 08:32:11
Guus, yes that's what daniel said, this can go in 2020, it doesn't have to keep 2019 waiting
Guus 08:32:39
pep. exactly. I agree with that (but let's not stop discussing things because they won't go in '19!)
pep. 08:32:59
Also in the meantime we can implement a proper solution and stop talking about oob for this use-case altogether :)
Andrew Nenakhov 08:33:39
Ge0rG, isn't that reference a markup? <reference xmlns='urn:xmpp:reference:0' begin='17' end='20' type='data'> ... Etc
Ge0rG 08:33:46
pep.: are you reading my thoughts? :D
pep. 08:34:19
Ge0rG, then please stop proposing it :(
Guus 08:34:21
stop using PEP for your thoughts, Ge0rG
pep. kicks Guus 08:34:34
Guus 08:34:51
I ment Personal Eventing, not you! 😃
Ge0rG 08:35:43
Andrew Nenakhov: ah, that one. I never liked XEP-0372 and hope we can get SIMS independently of that as well
Ge0rG 08:36:03
Interestingly, SIMS doesn't even mention the existence of XEP-0372
Maranda has left 08:38:27
Maranda has joined 08:38:29
lovetox has joined 08:38:46
lovetox 08:41:49
Ge0rG why do you think 0066 is a horrible mess?
frainz has left 08:45:56
Ge0rG 08:45:57
lovetox: multiple reasons: 1) you need to do an additional HTTP HEAD before you know whether you should download the file (size, content type) 2) the body=url requirement makes integration of text and image impossible 3) in 0066 there is no wording about using that as an indicator of "inline media" 4) security-paranoid people can't know whether they want to load the media without first leaking their IP address
frainz has joined 08:46:07
Ge0rG 08:46:12
4 is heavily related to 1, but still a bit different
Ge0rG 08:46:33
5) the body=url requirement isn't documented
lovetox 08:48:45
Did you read my reply on the list?
lovetox 08:49:04
body=url is not a requirement nor a indication for other clients to do UI actions
lovetox 08:49:22
its a simple fallback body like in other XEPs
lovetox 08:49:52
I dont see how you use any other alternative (SIMS) without providing a fallback body
lovetox 08:50:03
if you choose so you could do the same with 0066
rion has left 08:50:37
lovetox 08:54:18
1) yes more metadata is always nice, but i wouldnt call it a horrible mess
Ge0rG 08:56:11
Now I wonder when / whether I used the words "horrible mess" re 0066.
Ge0rG 08:57:50
lovetox: I think that body=url is enforced by Conversations for inline media, which is a bit unfortunate. I'd have gone with body.replace(url, "") instead to allow the file + comment legacy situation
pep. 08:57:57
"lovetox> body=url is not a requirement nor a indication for other clients to do UI actions", Conversations would like to disagree with you
Ge0rG 08:58:45
technically speaking, displaying an URL in the client is a perfectly fine way of handling it. But the UX of that is a bit sub-optimal, *especially* on mobile devices.
lovetox 08:58:58
And what Conversations does is how the world implements something or ..?!
pep. 08:59:33
lovetox, yes? it's been a while we've renamed to The Conversations Protocol, you missed the note? :)
Ge0rG 08:59:43
didn't you know that the C in CS-2019 is for "Conversations"?
alacer has joined 08:59:44
Ge0rG 09:00:24
Conversations at least has spiked mobile XMPP adoption in the last years, _despite_ its UX
jonas’ 09:00:45
I think "because of", actually
pep. 09:00:55
yeah, I'd say so as well
Ge0rG 09:01:52
🤣
flow 09:01:54
ditto
larma has joined 09:02:05
Ge0rG 09:03:18
okay, okay. Let's be honest. It's a great client and super smooth for beginners. It just has some minor quirks that I'm very obsessed about
rtq3 has joined 09:03:32
ThibG has left 09:07:14
ThibG has joined 09:07:21
alacer has left 09:08:45
Ge0rG 09:09:32
flow: is there any kind of disco#info cache in Smack? I'd like to re-use the disco#info results between MUCManager.providesMucService() and other places.
andy has left 09:10:33
andy has joined 09:10:33
Seve 09:11:55
unpopularopinion: Very hard for me to use Conversations at the beginning, the interface was not really easy for me at first. Now I look back and I don't get why it was difficult for me to use
jonas’ 09:12:50
Seve, maybe you are like me and you’re not familiar with how stuff works on android
jonas’ 09:12:53
that was it for me, at least
Seve 09:13:37
Probably, jonas’, got an 'smartphone' pretty late
Maranda has left 09:21:47
Maranda has joined 09:21:49
pep. 09:23:57
lovetox: pardon my French, I actually meant the "memo", not the "note". The O-memo.
pep. leaves now 09:24:01
!xsf_Martin has joined 09:24:14
dwd has left 09:29:15
dwd has joined 09:29:15
dwd has left 09:30:32
dwd has joined 09:41:33
andy has left 09:45:18
andy has joined 09:45:19
ThibG has left 09:53:44
ThibG has joined 09:53:48
dwd has left 09:53:48
dwd has joined 09:53:49
lumi has joined 09:59:32
dwd has left 10:00:32
alacer has joined 10:02:18
alacer has left 10:11:18
ThibG has left 10:14:55
ThibG has joined 10:15:02
dwd has joined 10:22:49
andy has left 10:31:37
andy has joined 10:31:38
andy has left 10:36:50
lskdjf has joined 10:39:47
alacer has joined 10:39:52
dwd has left 10:41:13
dwd has joined 10:41:14
dwd has left 10:42:32
alacer has left 10:43:21
alacer has joined 10:43:24
valo has left 10:45:12
valo has joined 10:45:23
yvo has joined 10:49:03
rtq3 has left 10:50:47
rtq3 has joined 10:55:10
blabla has left 11:01:04
!xsf_Martin has left 11:01:48
blabla has joined 11:03:45
dwd has joined 11:09:19
dwd has left 11:25:42
dwd has joined 11:25:43
dwd has left 11:27:32
alacer has left 11:29:05
dwd has joined 11:38:38
jmpman has joined 11:48:58
dwd has left 11:50:31
dwd has joined 11:50:31
dwd has left 11:51:32
larma has left 11:58:52
dwd has joined 12:02:44
nyco has left 12:13:07
nyco has joined 12:14:09
Holger 12:14:37
Those Nextcloud people ... implementing chat from scratch and now wondering how to reinvent federation and the rest of XMPP: https://github.com/nextcloud/spreed/issues/21
Holger 12:14:44
They arrived at unique IDs a few minutes ago.
MattJ 12:15:23
:)
Ge0rG 12:16:57
Somebody should tell them about matrixmpp
Seve 12:19:50
Another failure :( we really need to make sure other communities and projects like Nextcloud are aware of XMPP and understand that it can be used (surprise!)
larma has joined 12:20:20
dwd has left 12:20:37
dwd has joined 12:20:38
dwd has left 12:21:32
Holger 12:21:49
https://apps.nextcloud.com/apps/ojsxc was already there, but implementing from scratch is just so much more fun.
rtq3 has left 12:25:57
alacer has joined 12:26:04
rtq3 has joined 12:26:21
dwd has joined 12:27:40
yvo has left 12:28:39
blabla has left 12:36:33
Yagiza has joined 12:42:11
dwd has left 12:44:48
dwd has joined 12:44:48
Andrew Nenakhov 12:44:56
We're actually planning to make file gallery for Xabber on top of nextcloud
dwd has left 12:45:32
blabla has joined 12:48:38
rtq3 has left 13:00:01
rtq3 has joined 13:00:23
Andrew Nenakhov has left 13:00:31
Andrew Nenakhov has joined 13:00:32
Andrew Nenakhov has left 13:00:33
dwd has joined 13:02:12
Zash has left 13:06:27
Zash has joined 13:12:10
Andrew Nenakhov has joined 13:16:55
Andrew Nenakhov has left 13:18:07
Andrew Nenakhov has joined 13:18:11
Andrew Nenakhov has left 13:20:52
Andrew Nenakhov has joined 13:20:56
Andrew Nenakhov has left 13:24:59
Andrew Nenakhov has joined 13:25:06
Andrew Nenakhov has left 13:25:55
Andrew Nenakhov has joined 13:26:03
Andrew Nenakhov has left 13:26:45
Andrew Nenakhov has joined 13:27:38
Seve 13:30:15
Andrew Nenakhov, https://www.goffi.org/b/hGKs6B4wd8dsgNZd5MzQjN/file-sharing-landing-next-release-salut
Seve 13:30:36
Maybe you want to explore what goffi has been working on for this kind of feature
Andrew Nenakhov has left 13:33:45
Alex has left 13:35:15
Andrew Nenakhov has joined 13:35:44
Andrew Nenakhov has left 13:36:36
Andrew Nenakhov has joined 13:36:46
moparisthebest 13:40:16
Does a xep specifying a new iq element need to define it's own namespace for it? Also what are the rules/conventions for doing so?
moparisthebest 13:40:55
New iq child element*
contrapunctus 13:42:08
Holger: why not inform them?
dwd has left 13:42:14
dwd has joined 13:42:15
contrapunctus 13:42:31
(Or _remind_ them.)
dwd has left 13:42:32
Andrew Nenakhov has left 13:42:34
Holger 13:43:32
contrapunctus: I doubt they haven't heard of JSXC, but yes I think I'll gonna troll that issue of nobody else does.
Holger 13:43:40
But now ... meeting.
Andrew Nenakhov has joined 13:44:52
Andrew Nenakhov has left 13:45:53
Andrew Nenakhov has joined 13:46:47
Andrew Nenakhov has left 13:47:00
Seve 13:47:26
I was going towrite something like 'XMPP!11' but I would be glad if you do it, Holger :D
Andrew Nenakhov has joined 13:49:08
andy has joined 13:52:48
Andrew Nenakhov has left 13:56:02
Andrew Nenakhov has joined 13:56:21
Andrew Nenakhov 13:58:40
Seve, I'll take a look, yes
lumi has left 14:09:12
lnj has joined 14:15:31
dwd has joined 14:20:25
kokonoe has left 14:20:28
kokonoe has joined 14:23:09
ralphm has joined 14:24:01
nyco 14:29:18
hello
Guus 14:30:27
Hi!
Seve 14:30:27
Hi
ralphm waves 14:30:27
ralphm bangs gavel 14:30:58
ralphm 14:31:11
0. Welcome + Agenda
ralphm 14:31:21
Who do we have and comments on the agenda.
nyco 14:31:37
_o/ agenda good to me
MattJ 14:31:43
Hey
Seve is here 14:31:45
Guus 14:31:56
nothign to add from me
ralphm 14:32:20
Full house!
ralphm 14:32:28
1. Minute taker
ralphm 14:32:30
Who?
kokonoe has left 14:34:16
ralphm 14:35:30
Well, that's disappointing.
ralphm 14:35:57
2. E2E Auth, CA req
nyco 14:36:09
we should all edit the same doc in real time while having conversations here
ralphm 14:36:16
https://xmpp.org/extensions/inbox/eax-car.html
ralphm 14:36:35
nyco: no, we need a minute taker that isn't involved in the discussion. But that's not the topic now.
nyco 14:36:44
so, can we be a CA? do we have the resources, capacity, knowledge, process?
Guus 14:37:04
Ralph, regarding 2 - correct me if I'm wrong, but this is about accepting the XEP into 'experimental' state, right?
ralphm 14:37:05
nyco: as I read the document, it doesn't call for the XSF being a CA
nyco 14:37:10
ah
nyco 14:37:17
misunderstood?
MattJ 14:37:27
Yes, it's not about being a CA
nyco 14:37:41
ok, then what?
Seve 14:37:49
Are we deciding on the whole XEP or just what it involves the XSF, the 2.2 section?
MattJ 14:38:05
As described in the document, we would provide a URL that redirects to one or more CAs
ralphm 14:38:19
Seve: I think this is just about accepting it as a XEP, not the full thing, because it is unfinished.
ralphm 14:38:52
I have a bunch of questions on the latter, but specifically, if Experimental stage requires us to set something up already.
kokonoe has joined 14:39:07
MattJ 14:39:58
I imagine so
MattJ 14:40:09
zinid, around?
ralphm 14:40:37
Because I am indeed curious what would be in section 4
ralphm 14:41:27
and particularly if including a CA in that redirect service will infer some kind of validity/trust/etc. in the reliability of a said CA
Seve agrees 14:41:51
ralphm 14:41:55
and whether we, like browsers, need to have procedures for evaluating and possibly evicting CAs
pep. 14:42:00
Most likely?
Guus 14:42:16
ralphm but that can be a question to be answered before moving from Experimental to Proposed, I think.
ralphm 14:42:27
if so, I'm a bit hesitent to accept Experimental as the stage where we start up a service
ralphm 14:42:33
hesitant even
Guus 14:43:29
What if we accept this as Experimental, in the understanding that we use that state to discuss within the XSF if we are capable/qualified/willing to host and manage the service?
Guus 14:43:51
so, without immediately starting to provide the service
ralphm 14:43:56
I.e. how do we relay the (apparent) Board's belief that until this thing goes to Active, whatever we put in that service is to not (yet) to be trusted for production use.
Kev 14:44:01
You might choose to put a new revision in first.
Kev 14:44:10
Saying ... upon advancing to Draft/equiv...
ralphm 14:44:36
Kev: unfortunately, since this is procedural, there's only Active
Kev 14:44:50
Right, I couldn't be bothered to check.
Kev 14:44:54
But the point stands.
Guus 14:44:54
Experimental -> Proposed -> Active ?
ralphm 14:44:58
Yeah
Kev 14:45:03
Text that says "Upon advancing to Active, the XSF will ..."
Guus 14:45:05
end-users don't see such revisions, though.
ralphm 14:45:15
So Kev, you mean we encode in the document that we put that caveat
Kev 14:45:17
That way the XSF isn't obliged to do anything until they advance it.
ralphm 14:45:31
I.e. before accepting as XEP
Kev 14:45:33
Like various other things say "Upon advancing to Draft, the Registrar..."
Kev 14:45:45
ralphm: Yes. That would address the concern, wouldn't it?
ralphm 14:45:49
It would
Guus 14:46:16
alternatively, different URLs for services based on state of the XEP?
ralphm 14:46:41
Or both
Guus 14:46:58
unsure if non-static URLs would defeat the purpose of the XEP though.
Andrew Nenakhov has left 14:46:59
ralphm 14:47:52
Well, I think having a fresh start when it goes active makes sense.
Andrew Nenakhov has joined 14:48:02
Alex has joined 14:48:18
Guus 14:48:53
it would remove the concern that you just raised (that I share)
MattJ 14:49:23
Makes sense to me
Guus 14:49:48
zinid are you around?
ralphm 14:50:19
That said, I haven't read RFC 6940 yet, which describes this particular well-known URI
Guus 14:51:01
Assuming the worst-case scenario, where it disallows this.
Guus 14:51:40
is a disclaimer in the XEP that things shouldn't be trusted until the XEP is moved to Active state, sufficient?
ralphm 14:51:58
Well, we could have, say, test.xmpp.org instead of just xmpp.org during the experimental stage, for the well-known to live at
Kev 14:52:10
Until and unless :) I think some sort of notice that it's not 'real' until Active is worthwhile.
Guus 14:52:20
oh, that I like that pragmatic solution, Ralph
ralphm 14:52:38
Kev: does that sound good to you with your iteam hat on?
Guus 14:52:49
Kev I agree that it's worhtwhile, but I was asking if it in itself was enough.
Kev 14:53:11
ralphm: TBPH, I've not been following in enough detail to answer that, let me scroll back.
Kev 14:53:31
If the question is 'can we host something at test.xmpp.org?' the answer is 'sure'.
blabla has left 14:53:38
Maranda has left 14:53:38
blabla has joined 14:53:44
Kev 14:53:55
Although I'm not sure whether it's worth it compared to just saying in the XEP it's not 'active' yet.
Kev 14:53:59
But we can do it.
ralphm 14:54:48
Ok, so I think this discussion highlights our concerns, which counts as the feedback for the Author to process per Section 5 of XEP-0001.
Guus 14:54:55
Kev - I think it would be worth-while, if only to prevent code from having to parse the XEP state to determine if some kind of trust setting should be enabled.
Kev 14:55:18
Guus: I don't think it really does that, does it?
ralphm 14:55:23
I move we urge the Author to process this, and resubmit.
Seve 14:55:25
Is the Author then going to add the information regarding the process until it gets to Active?
Seve 14:55:30
Ok
frainz has left 14:55:42
Seve 14:55:45
I agree
Guus 14:55:48
+1 on ralphm motion
ralphm 14:56:11
I don't think we are asking for a fully specced out Business Rules section, yet. That can be done while Experimental.
ralphm 14:56:13
+1
Seve 14:56:24
+1
Guus 14:56:25
Kev I can imagine that some software does not want to use the service until the XEP is Active.
ralphm 14:56:39
Guus: seems to me to be a feature
Seve 14:56:57
What's your take on this, MattJ and nyco?
Kev 14:56:58
Guus: Right. I'm assuming any such software will simply not trust it until their next release after it's active, rather than polling a URL and seeing when it starts to exist.
nyco 14:57:16
+1 for resubmit for Business Rules, I'd like to see a non-empty section, at least mentioning some identified problematics
Guus 14:57:16
not having a service on the 'active' URL prevents confusion there, I think.
Kev 14:57:19
This is a low-F issue for me.
Guus 14:57:27
kk
MattJ 14:57:43
Sounds fine to me
andy has left 14:57:58
ralphm 14:58:01
Ok, motion carry. Thanks for submission zinid, we look forward for the new version.
ralphm 14:58:11
"to"
ralphm 14:58:26
and "carries". Typing. Sigh
ralphm 14:58:45
3. XEP-0345
ralphm 14:58:59
Form of Membership Applications
dwd has left 14:59:49
dwd has joined 14:59:50
Guus 15:00:05
pep. raised some concerns in LC
pep. 15:00:26
(!)
dwd has left 15:00:32
Guus 15:00:47
one of which is that the XEP specifies a restriction to natural persons, while our bylaws explicitly define other entities.
Guus 15:01:00
I feel that that should be addressed.
waqas has joined 15:01:02
Guus 15:01:23
that's the only concern I have/share (unless others now bring up good points that I didn't think of 😛 )
Guus 15:01:42
also, I checked with the XSF Secretary, as this involves a process he's familiar with: he had no concerns.
MattJ 15:02:16
I'm curious what the membership feels, specifically about the requirement to list employment
ralphm 15:02:26
It is pretty normal for corporations to narrow down what's allowed in bylaws
MattJ 15:02:36
We've already had discussions based on just listing names
Guus 15:02:42
MattJ membership has had two LC's to express what they feel.
Seve 15:03:14
I think Relevant Affiliations is important, as a member.
MattJ 15:03:17
Guus, true
ralphm 15:03:25
The reason for listing employment is specifically to curb influence by a one or more larger companie
ralphm 15:03:26
s
Seve 15:03:36
Exactly
pep. 15:03:36
There was also comments about "if real names really need to be provided, would it be possible to just provide them to the secretary or somesuch"
MattJ 15:03:46
ralphm, right, but (as with name) this could potentially be privately maintained by the Secretary
pep. 15:03:54
this ^
ralphm 15:04:04
It could
Guus 15:04:22
MattJ I agree that it could, but as it never has been, I don't feel that's needed now - unless someone has a good argument.
Seve 15:04:23
I must say members may need to know that
waqas has left 15:04:32
waqas has joined 15:04:36
Guus 15:04:42
(still interested in hearing from that one person you knew)
waqas has left 15:04:44
ralphm 15:05:01
I think that transparency on who's member of the the XSF is a good thing.
Seve 15:05:09
I feel this XEP is only stating in writing the current and past procedure of being a member.
ralphm 15:05:31
Seve: this is indeed its purpose
Seve 15:05:43
Which we should be quite comfortable with it, in my opinion.
pep. 15:05:46
Seve, you mean you see no reason for changing it then?
pep. 15:05:49
k
ralphm 15:05:52
As such, I'm not sure we should at this point discuss changes to it.
Guus 15:06:54
agreed - but the concern regarding the more specific definition than the one in the bylaws remains.
Guus 15:07:07
why are we making things more specific in this XEP?
ralphm 15:07:23
For what it is worth, I think the 2014 thread of remarks, by Matthew Miller, were more about wording than content-wise. Dave mentioned that it inspired him to changes, but I haven't seen those.
waqas has joined 15:07:28
pep. 15:07:35
I assume there has never been any case of a non-natural entity applying?
ralphm 15:07:46
Guus: because that just codifies what we've been doing from the beginning.
Guus 15:07:55
pep. that might be true, but is that a reason to now forbid it?
pep. 15:08:06
Guus, not what I'm saying no
ralphm 15:08:09
There's been no need or request for a non-natural entity to be a member of the XSF.
Kev 15:08:09
Guus: I think so, yes.
pep. 15:08:09
Just curious
Seve 15:08:11
pep., I must admit I have been always really careful about privacy, and until I didn't became a member of the XSF or submited a XEP, I never published my real name online. I think this is important to be able to trust the XSF and understand it as a serious foundation. Even though you and me can think about the option of not making the name of your company public, in reality, I think it is not the best think when talking about a public foundation like the XSF
ralphm 15:08:16
AFAIK
Guus 15:08:42
Kev curious about reasoning there.
karoshi has left 15:08:46
karoshi has joined 15:08:55
Kev 15:08:57
Guus: If it actually happened it'd be a horrendous can of worms for us.
grumpy has left 15:09:13
waqas has left 15:09:28
pep. 15:09:33
The issue to me really is that I don't know if there's a need for a real name.
waqas has joined 15:09:36
ralphm 15:09:42
E.g. our voting process currently uses a bot with a jid that is expected to belong to a natural person.
pep. 15:09:57
ralphm, does it?
Guus 15:10:03
The bylaws state that there's one person that represents the entity
Guus 15:10:06
that'd still work.
ralphm 15:10:28
pep.: see Alex' e-mails around member elections or other votes
Seve 15:10:31
Would an entity be able to be a member, and also members of that entity?
ralphm 15:10:46
Seve: good question
ralphm 15:10:56
I don't see a good reason for having this right now.
waqas has left 15:11:12
ralphm 15:11:23
That the bylaws allow for it, just makes it easier to change our mind later, without paying lawyers and such.
waqas has joined 15:11:24
dwd has joined 15:11:46
Guus 15:12:00
it's not a hill I'm going to die on.
ralphm 15:12:09
Yes, please don't die.
MattJ 15:12:17
Same here, I'm fine with it
ralphm 15:12:55
Do we feel that we've processed feedback suffiently to vote on its advancement?
Guus 15:13:03
I have noticed the real name remarks, but I don't share those concerns
Guus 15:13:23
the omission of not having a process that verifies that a real-sounding-name is indeed, real, is one that I can live with
Guus 15:13:30
I'm happy to vote.
ralphm 15:14:04
I motion that XEP-0345 progresses to Active.
Guus 15:14:13
+1
pep. 15:14:27
Not going to die on that hill either, but :/
nyco 15:14:39
+1
waqas has left 15:14:41
Seve 15:14:48
~~I would like to explore if confirmation on that person should be needed (If real name is correct and so on), but I think it we can move along for now. I'm +1~~ ✎
Guus 15:14:49
(let the records reflect that pep. is looking sad on a hill)
ralphm 15:14:52
pep.: to be sure, it being Active doesn't mean it can't change later
ralphm 15:15:12
+1
Seve 15:15:13
I would like to explore if confirmation on that person should be needed (If real name is correct and so on), but I think we can move forward for now. I'm +1 ✏
ralphm 15:15:20
(Guus: I welcome you to write the minutes)
ralphm 15:15:40
MattJ?
MattJ 15:15:51
+1 from me
pep. 15:15:52
ralphm, ok, good to know. But judging by this discussion, this is probably not going to change, because we're not welcoming the kind of people that would like this to
pep. 15:16:13
(bootstraping issues?)
MattJ 15:16:41
My opinion here is that, as was mentioned, we're documenting what we're currently doing in practice
ralphm 15:16:47
motion carries. Let the Editors go through to the mechanics to move XEP-0345 to Active.
Guus 15:16:56
jonas’ ^
Seve 15:17:02
pep., what is a bootstrap issue?
ralphm 15:17:11
pep.: you having an opinion on this and being a member seems to be counter your point.
pep. 15:17:23
Seve, you need enough of something already to have something carry on, or even be a thing
Guus 15:17:37
My remaining available time is limited.
nyco 15:17:39
aka chicken and egg
ralphm 15:18:04
Guus: mine too
ralphm 15:18:18
Since we're 48 minutes in, I'd like to move the remaining items to next week.
MattJ 15:18:32
wfm
ralphm 15:18:35
4. Date of Next
ralphm 15:18:37
+1W
Guus 15:18:40
wfm
ralphm 15:18:41
5. Close
ralphm 15:18:45
Thanks all!
ralphm bangs gavel 15:18:49
Guus 15:18:50
Thank you
MattJ 15:18:50
Thanks!
nyco 15:18:53
thx all
Seve 15:19:01
Thank you, everybody :)
Seve 15:19:37
pep., you mean that, because we don't have enough people that don't want to say their real names, we don't want to let that option be available?
pep. 15:20:10
replace the last "we don't want" by "it is unlikely"
ralphm 15:20:47
pep.: what I mean is that your question on the need of Real Names™ right now is still a valid one, and I'd welcome a discussion on that topic.
pep. 15:21:17
Ok
pep. 15:23:05
As I said I'm not going to fight tooth and nail for it, but I also want to be welcoming to people who'd feel concerned about it
ralphm 15:23:14
I might even be convinced to change my mind, but for now I feel like the transparency outweighs the concerns (which might need to be more clearly defined).
Zash 15:23:47
I didn't read all the backlog, but I'd like to point out that knowledge of real names could be limited to the secretary if needed for legal reasons.
ralphm 15:23:48
I also want to note that having this discussion doesn't require pre-existing membership.
ralphm 15:24:05
Zash: that was mentioned
Zash 15:24:11
Check
Seve 15:24:43
If that was the case, would you need a reason to hide your name to the members?
lovetox has left 15:24:53
pep. 15:25:10
what is visible to members is usually visible to everyone
alacer has left 15:25:31
pep. 15:25:40
Seve, Secretary-only might still not be a valid solution to some fwiw
ralphm 15:25:45
I think the only non-public thing in the XSF is the Board mailing list.
Seve 15:29:43
I think you have a point though, pep. Since we don't do a check on the name, you could just say you are called Peter Nielsen and let the members trust the application (something that is stated in the XEP, section 7. Security Considerations)
lnj has left 15:30:14
Seve 15:30:29
For now though, even I always cared of having a digital life and a 'real' life completely decoupled, I agree with ralphm about transparency
Kev 15:31:28
If one cares about decoupling digital life and real life, one still can - pretty much all contribution can be performed with just your digital persona, it's only becoming a member of the real-world organisation that requires a real-world person.
pep. 15:31:29
I think transparency should be in acts
pep. 15:33:55
And I'm fine with judging people with whatever identity they want to share. I'm already not digging up Facebook accounts of applying members anyway..
pep. 15:34:14
(Maybe I should)
Seve laughs 15:34:21
Seve 15:34:56
pep., Imagine that when applying for membership to the XSF, you have a button that says 'Log in with Facebook' :D
pep. 15:35:06
I wouldn't apply.
Seve 15:35:30
pep., I would not even be able to!
Seve 15:35:40
(I don't have an account there)
pep. 15:35:45
~~Same, fwiw, but that wasn't why I answered that~~ ✎
Seve 15:36:02
I know :)
pep. 15:36:11
Same, fwiw, but that's not why I answered that ✏
rtq3 has left 15:36:59
rtq3 has joined 15:37:19
zinid 15:38:33
oh, I slept away the meeting
frainz has joined 15:43:22
jmpman has left 15:44:52
Maranda has joined 15:45:19
lnj has joined 15:58:21
mrDoctorWho has left 15:59:12
mrDoctorWho has joined 15:59:14
Maranda has left 15:59:15
Maranda has joined 15:59:17
vaulor has left 16:03:24
vaulor has joined 16:03:26
alacer has joined 16:04:07
dwd has left 16:04:44
dwd has joined 16:04:45
dwd has left 16:06:32
dwd has joined 16:12:41
lnj has left 16:13:32
Maranda has left 16:22:02
Maranda has joined 16:22:05
dwd has left 16:24:27
dwd has joined 16:24:28
dwd has left 16:30:32
kokonoe has left 16:31:09
melvo has left 16:35:05
kokonoe has joined 16:35:06
melvo has joined 16:37:59
blabla has left 16:40:59
debacle has joined 16:45:34
waqas has joined 16:47:55
blabla has joined 16:50:31
Steve Kille has left 16:54:48
ralphm 16:55:27
zinid: hope you can work with the comments made during the meeting
waqas has left 16:58:51
waqas has joined 16:58:55
neshtaxmpp has left 17:00:29
Nekit has left 17:02:36
dwd has joined 17:02:44
Maranda has left 17:04:22
Maranda has joined 17:04:24
alacer has left 17:11:25
rtq3 has left 17:11:56
rtq3 has joined 17:12:18
marc_ has joined 17:19:34
dwd has left 17:20:19
dwd has joined 17:20:20
moparisthebest 17:21:09
$ dig -p5354 @127.0.0.1 +short debian.org 5.153.231.4
moparisthebest 17:21:19
got DoX working
dwd has left 17:21:32
moparisthebest 17:21:54
that's UDP -> XMPP listener -> XMPP resolver -> TCP, and back
Yagiza has left 17:23:07
j.r has left 17:27:17
j.r has joined 17:27:22
moparisthebest 17:28:47
wire format is: <iq to='dns@example.org/listener' id='27tZp-7' type='get'><dns xmlns='https://moparisthebest.com/dns'>vOIBIAABAAAAAAABB2V4YW1wbGUDb3JnAAABAAEAACkQAAAAAAAADAAKAAj5HO5JuEe+mA</dns></iq> <iq to='dns@example.org/resolver' id='27tZp-7' type='result'><dns xmlns='https://moparisthebest.com/dns'>vOKBoAABAAEAAAABB2V4YW1wbGUDb3JnAAABAAHADAABAAEAAAhjAARduNgiAAApEAAAAAAAAAA</dns></iq>
moparisthebest 17:29:21
which is a real request+response for $ dig -p5354 @127.0.0.1 +short +tcp example.org -> 93.184.216.34 cc Wiktor :)
moparisthebest 17:30:09
I'll have the code pushed up tonight
Wiktor 17:31:50
moparisthebest: 👏 looking forward to seeing your code
jonas’ 17:32:11
and I thought I was weird
Seve 17:32:23
Haha jonas’
moparisthebest 17:34:03
Zash, Ge0rG, re: discussion yesterday, bootstrap-wise, if you hard-code a IP + port + username + (maybe anonymous auth, maybe password), it could be used to get proper SRV records for whatever is next etc right? :D
moparisthebest 17:34:48
it'd be easy to set up a public "bootstrap account" like that which is firewalled off from talking to anything else but the resolver
Ge0rG 17:35:30
moparisthebest: you should have some obfuscated AFD reference in the namespace tag.
Ge0rG 17:35:59
moparisthebest: +1 for anonymous auth
moparisthebest 17:36:19
what's AFD ?
Ge0rG 17:36:57
April Fool's Day
moparisthebest 17:37:48
ah right, I think it's better to leave everyone wondering forever if it's serious or april fools joke :P
Ge0rG 17:37:52
moparisthebest: can we have some interesting / sensible disco#items offering as well?
moparisthebest 17:38:05
I mean, it works, *could* be useful, meh
Ge0rG 17:38:17
moparisthebest: oh. There is a category of XEP to spoil that.
moparisthebest 17:38:46
right I think it should be Standards Track instead of Humorous for the same reason :D
Ge0rG 17:39:27
🤔
moparisthebest 17:39:59
yes, ideally everyone that looks at it has that expression on their face forever
Ge0rG 17:40:10
moparisthebest: also can one subscribe to NOTIFY events over XMPP? That would be a real benefit
Ge0rG 17:40:47
moparisthebest: I'm not sure council will be able and willing to follow that argumentation
moparisthebest 17:41:15
yea it's up to them of course, but I can try :)
moparisthebest 17:41:33
it's no more silly than DoH which is a *real thing (tm)*
Ge0rG 17:43:42
I'm not sure. XMPP has some significant amount of round trips at session setup, which is amortized over it's typical multi hour life time
moparisthebest 17:44:32
that makes it *more* efficient than DoH if you only connect once and send multiple queries over hours/days/years
Ge0rG 17:49:01
Touche
dwd has joined 17:53:41
debacle has left 17:54:10
zinid 17:55:25
Ge0rG: +1 and the reason I don't want new SASL or how it's called
lovetox has joined 17:59:11
marc_ has left 17:59:14
ThibG has left 17:59:35
ThibG has joined 17:59:45
dwd has left 18:00:17
dwd has joined 18:00:17
dwd has left 18:06:32
Maranda has left 18:07:57
Maranda has joined 18:07:59
dwd has joined 18:12:42
j.r has left 18:29:51
neshtaxmpp has joined 18:31:12
ralphm has left 18:33:34
marc_ has joined 18:34:46
j.r has joined 18:34:58
rtq3 has left 18:35:32
rtq3 has joined 18:35:55
ThibG has left 18:42:12
ThibG has joined 18:42:16
dwd has left 18:43:23
dwd has joined 18:43:25
dwd has left 18:45:32
lumi has joined 18:47:40
lnj has joined 18:52:29
lorddavidiii has left 18:53:51
lorddavidiii has joined 18:53:53
vanitasvitae has left 18:56:07
vanitasvitae has joined 18:56:09
waqas has left 18:58:48
j.r has left 19:02:41
j.r has joined 19:02:58
lnj has left 19:08:38
dwd has joined 19:11:18
j.r has left 19:11:52
j.r has joined 19:12:13
igoose has left 19:13:43
j.r has left 19:17:13
j.r has joined 19:17:30
dwd has left 19:17:59
dwd has joined 19:18:00
kokonoe has left 19:21:40
kokonoe has joined 19:22:16
valo has left 19:22:24
melvo has left 19:24:26
dwd has left 19:24:32
melvo has joined 19:28:35
melvo has left 19:28:39
jonas’ 19:30:05
zinid, wat? SASL2 is supposed to reduce number of roundtrips
jonas’ 19:30:26
it saves a stream reset
dwd has joined 19:30:30
j.r has left 19:30:52
j.r has joined 19:31:03
404.city has joined 19:34:56
j.r has left 19:36:08
Zash 19:36:34
Did anyone remember why that stream reset exists?
lnj has joined 19:37:54
jonas’ 19:40:34
the wording in RFC 6120 which I remember talks about something security I think
jonas’ 19:40:55
which makes sense for TLS, I think, because you can add new info in the stream header which you wouldn’t want to add when you haven’t authenticated your peer yet.
Zash 19:40:56
I was convinced it was to make sure that there wasn't any trace of credentials in the parser that could leak
j.r has joined 19:41:12
Zash 19:41:30
Also security layers, but that's gotten replaced by TLS these days
j.r has left 19:43:10
moparisthebest 19:43:13
what's the reason for SASL etc anyway, why not <auth username="bob@example.org" password="thaoeutnh"/> as the first message after the TLS connection is established?
Zash 19:43:15
(DIGEST-MD5 could include negotiation of encryption)
j.r has joined 19:43:24
Zash 19:43:38
moparisthebest: You mean how it was before?
jonas’ 19:43:39
moparisthebest, SASL gives you flexibility and good stuff like SCRAM
moparisthebest 19:43:45
worded another way, if TLS is mandatory, what's the point
Zash 19:43:57
SCRAM
jonas’ 19:43:58
SCRAM allows both parties to not store the plain text password
moparisthebest 19:44:00
jonas’, is that "hiding password from server" ?
moparisthebest 19:44:10
eh
Zash 19:44:14
Hides password from everyone
jonas’ 19:44:17
avoiding to ever have to store the plaintext password
jonas’ 19:44:19
which is a good thing
moparisthebest 19:44:26
is that really worth all the complexity?
Zash 19:44:34
Client can store magic hashes, magic hashes sent on the wire, magic hashes stored on the server.
jonas’ 19:44:36
SCRAM isn’t that complex
Zash 19:44:46
It's fairly simple in fact
Zash 19:45:02
But maybe that's just bias from exposure to DIGEST-MD5
moparisthebest 19:45:07
and un-upgradeable etc etc if I follow along correctly?
Holger 19:45:15
And expensive if you allow PLAIN.
Zash 19:45:40
Why would you upgrade again?
moparisthebest 19:45:44
sounds pretty expensive/complex overall, for almost no benefit, to me
jonas’ 19:45:55
e2ee is more complex
jonas’ 19:45:56
;P
zinid 19:46:31
Holger, in that SCRAM mail thread I'm told to adjust the server capacity (read: hardware is cheap). This is pathetic.
lovetox 19:46:31
Did it not only have value if we assume people use the same password often on many services?
zinid 19:47:11
it's like suggesting using O(N) instead of O(log(N)) and "adjust the capacity"
jonas’ 19:47:23
lovetox, not having to store plaintext passwords anywhere is always a good thing, although I’ll miss my Poor Man’s pass (`xpath -e 'string(/account/account[string(name)="$MYJID"]/password)' ~/.purple/accounts.xml 2>/dev/null`)
lovetox 19:48:10
jonas’, i think this is only true if you assume the password is not a unique password for only that service
igoose has joined 19:48:11
dwd has left 19:48:13
dwd has joined 19:48:14
jonas’ 19:48:19
lovetox, ah, yes
jonas’ 19:48:25
but we’re still not quite at device passwords
dwd has left 19:48:32
lovetox 19:48:35
which is probably a correct assumption for most people in this world
moparisthebest 19:48:49
but we've long been at "seperate password for each service" so I don't get the point
jonas’ 19:48:57
moparisthebest, that’s the ideal world, but not the real world
lovetox 19:48:59
moparisthebest, you maybe :)
moparisthebest 19:49:04
simple auth would also support per device passwords, TOTP etc etc
lovetox 19:49:31
i know my parents are definitly not at one password per service :D
moparisthebest 19:49:33
isn't "use a password manager" basically been the industry standard advice for years now?
jonas’ 19:49:44
you confuse the industry with what normal people do in the real world
moparisthebest 19:50:05
well, those people also don't use XMPP :'(
jonas’ 19:50:10
not quite true
lovetox 19:50:20
moparisthebest, if this would be true there would be no value in services like "is my password pwned"
alacer has joined 19:50:22
lovetox 19:50:31
dont know what the name of the site was
jonas’ 19:50:36
haveibeenpwned
jonas’ 19:50:40
or something like that
lovetox 19:50:56
yeah
moparisthebest 19:51:35
another argument would be, XMPP is basically the only thing that goes through these lengths not to store password, so what's the point
moparisthebest 19:52:00
if you don't re-use it, it doesn't matter, if you do it's everywhere elso on your computer in plaintext?
jonas’ 19:52:09
moparisthebest, that seems to boil down to "others are at least as bad, so we don’t have to care" which is not a standard I want to work with
dwd has joined 19:52:25
lovetox 19:52:50
from a client pov, this is not much work to implement
lovetox 19:53:11
from a server pov it probably has downsides
lovetox 19:53:18
but also some upsides
Holger 19:53:22
lovetox: Yes, only if we assume users reuse passwords and attackers can identify their other accounts. And of course attackers can still try to grab passwords from registration or password changes, or from SASL PLAIN logins.
Holger 19:53:56
And obviously they must be successful in taking over your server in the first place 🙂
lovetox 19:54:03
Holger i think the most likely scenario is, your server gets pwned
lovetox 19:54:10
they steal the emails and passwords
lovetox 19:54:13
and try other services
lovetox 19:54:17
not other xmpp accounts
jonas’ 19:54:22
good thing XMPP services don’t store emails :)
moparisthebest 19:54:37
which bcrypt/scrypt/pbkf2 etc all have had solved for years
vaulor has left 19:54:40
lovetox 19:54:46
as a server hoster i would see it as a positive if i know i dont store real passwords from users
moparisthebest 19:54:49
servers don't store plaintext passwords anyway
vaulor has joined 19:54:49
moparisthebest 19:55:11
I think it's worthless for the client not to store it basically :/
Zash 19:55:13
SCRAM uses PBKDF2 already
Zash 19:55:34
Along with one weird trick that means you don't have to do the expensive computation
lovetox 19:55:46
moparisthebest, what do you mean they dont store it in plaintext? how do they authenticate a PLAIN connection than?
alacer has left 19:55:56
moparisthebest 19:56:04
they store them hashed
jonas’ 19:56:07
lovetox, ... by pbkdf2-ing things and comparing hashes?
zinid 19:56:48
SASL EXTERNAL!!!1111
Holger 19:56:54
lovetox: Yes, there's obviously value in hashing passwords, but I don't quite get this OMG-IT'S-2019-PLAINTEXT-PASSWORDS-NOOO-GO drama. SCRAM has downsides, so it's a trade-off and admins must decide.
lovetox 19:57:30
jonas’, so why use SCRAM then?
efrit has joined 19:57:33
jonas’ 19:57:46
lovetox, less expensive when both sides support it
jonas’ 19:58:08
Holger, except for the upgradability, *does* it have downsides?
zinid 19:58:27
jonas’, external services?
Zash 19:58:28
And the upgrade problem of SCRAM mostly boils down to that you need the plain text to upgrade, which is quite normal for this kind of thing
jonas’ 19:58:35
assuming that you store hashed passwords anyways, it actually has the upside that you save the computation when you have a client which supports it. when the client only supports PLAIN, you have to hash, but you also have to do that when you store hashed anyways.
jonas’ 19:58:43
zinid, ah, yes, the pain with the external services. I know it myself.
Holger 19:59:09
jonas’: As I said it's expensive if you allow PLAIN, so DoS vector. Plus external services like e.g. STUN/TURN/SIP as zinid said.
moparisthebest 19:59:09
Zash, so it prevents you from needing to store plaintext on client, that's the only benefit, and it requires plaintext on client to upgrade?
moparisthebest 19:59:16
what's the benefit again?
jonas’ 19:59:20
Holger, see what I wrote about the PLAIN issue.
jonas’ 19:59:34
it is only more expensive if you consider storing plaintext passwords a real alternative
Holger 19:59:38
Yes, I wasn't making your assumption.
Holger 19:59:46
Of course it's an alternative.
Zash 19:59:49
moparisthebest: Ugh. I don't even.
zinid 20:00:20
is storing plaintext an alternative? I don't think that's what users expect you to do
zinid 20:00:32
but you can lie of course!
kokonoe has left 20:00:46
lovetox 20:01:53
So there is no perfect solution?
404.city has left 20:02:02
lovetox 20:02:20
DoS vector with plain, SCRAM does not work with external services and not upgradeable easily
zinid 20:02:21
SASL EXTERNAL, bitches!!111
kokonoe has joined 20:02:33
lovetox 20:02:43
how does that work, you authenticate over another channel?
Zash 20:02:49
zinid: Also problematic
moparisthebest 20:03:00
if... all HTTP services ever can handle the "DoS vector of plain" then I'm pretty sure XMPP servers can
Zash 20:03:04
zinid: Or rather, which kind of SASL EXTERNAL?
zinid 20:03:15
Zash, X.509 certs
zinid 20:03:26
Zash, also, you can say about everything "also problematic"
moparisthebest 20:03:38
HTTP has far more auths in comparison, sometimes on every request
zinid 20:04:42
read this http://upload.zinid.ru/xep-eax-csr.html (it's not finished, I'm still working on it)
Holger 20:05:15
zinid: I don't think day-to-day users ever question the password storage format. If they do I'd expect most to assume the server has the password as they never heard of hashes.
Zash 20:05:38
zinid: Mostly I'm concerned about certificates being sent in the clear, tho maybe TLS 1.3 fixed that. Not sure.
zinid 20:05:43
Holger, yeah, but the ones who question are very loud
Holger 20:05:49
Indeed.
jonas’ 20:05:51
Holger, it’s not about what day-to-day users question or expect, it’s about sensible practices in the IT industry and not looking very dumb when you get owned.
zinid 20:06:04
Zash, it's fixed in TLS1.3, we checked that with Wiktor recently
zinid 20:06:28
Zash, both client and server certs are now encrypted
Holger 20:06:33
jonas’: Yes, and my point above was that this is more of a hype thing than a sensible practice.
Zash 20:06:48
zinid: Then yes, client certs are pretty nice
zinid 20:06:57
Zash, so read my scribble!!!111
jonas’ 20:07:10
Holger, to be clear, you think that not storing plaintext passwords is more of a hype thing than a sensible practice?
zinid 20:07:18
feedback is welcome even at this stage of the scribble
dwd has left 20:07:28
dwd has joined 20:07:29
lovetox 20:07:33
but how does the client obtain the client cert? what if he changes device?
Holger 20:07:36
jonas’: If you look at it without the OMG drama, as I'd expect from IT people who know their job, you'll see it's a trade-off.
jonas’ 20:07:47
sure it’s a trade-off
zinid 20:08:08
lovetox, sigh, look at my proposal please 🙁
jonas’ 20:08:12
(I’m storing passwords with SSHA, which is pretty much plaintext for a determined attacker)
zinid 20:08:15
at least at intro
lovetox 20:08:16
yeah im reading now
lovetox 20:08:21
sorry :)
Holger 20:08:28
jonas’: So "plaintext is NO-GO" is not the obviously correct decision.
jonas’ 20:08:29
but I’d also say that the default is more like "don’t store plaintext unless you have a very good reason to do so"
Holger 20:11:19
All else being equal, sure. That's stating the obvious. The hype is about stopping at this point.
jonas’ 20:11:34
I see
rtq3 has left 20:12:12
dwd has left 20:12:32
efrit has left 20:12:45
pep. 20:15:21
>jonas’> Holger, it’s not about what day-to-day users question or expect, it’s about sensible practices in the IT industry and not looking very dumb when you get owned. I'd argue it's neither of these, it's about privacy terms and morale (of keeping your promises) :)
moparisthebest 20:17:35
it's invisible to users anyway
moparisthebest 20:17:54
I don't know what conversations, gajim, dino do when I type my password in
pep. 20:18:09
It is indeed
moparisthebest 20:18:47
if anything, users expect the website they type their user+pass in to have their user+pass
dwd has joined 20:18:49
moparisthebest 20:19:07
because that's how every website ever works
pep. 20:19:18
tbh, I don't think users expect :/
pep. 20:19:25
(at all)
waqas has joined 20:28:16
Nekit has joined 20:38:32
waqas has left 20:38:39
waqas has joined 20:38:44
dwd has left 20:42:32
UsL has left 20:44:15
j.r has left 20:46:02
j.r has joined 20:46:05
vaulor has left 20:47:09
Steve Kille has joined 20:47:13
dwd has joined 20:47:59
debacle has joined 20:48:42
j.r has left 20:49:55
j.r has joined 20:50:00
ralphm has joined 20:50:15
j.r has left 20:52:21
j.r has joined 20:52:24
j.r has left 20:57:25
j.r has joined 20:57:31
rion has joined 20:57:39
ralphm has left 20:58:02
ralphm has joined 20:58:04
valo has joined 21:02:21
j.r has left 21:02:37
j.r has joined 21:02:48
ralphm has left 21:04:17
ralphm has joined 21:04:18
rtq3 has joined 21:06:25
lovetox has left 21:07:00
ralphm has left 21:07:03
ralphm has joined 21:07:04
lovetox has joined 21:07:06
rtq3 has left 21:07:25
lnj has left 21:07:38
rtq3 has joined 21:07:47
ralphm has left 21:13:10
ralphm has joined 21:13:11
grumpy has joined 21:13:18
lnj has joined 21:14:10
kokonoe has left 21:26:23
kokonoe has joined 21:28:43
UsL has joined 21:29:00
valo has left 21:33:13
j.r has left 21:36:06
Nekit has left 21:36:07
j.r has joined 21:36:10
j.r has left 21:40:35
ThibG has left 21:41:16
ThibG has joined 21:41:23
j.r has joined 21:41:58
!xsf_Martin has joined 21:42:57
ralphm has left 21:48:42
ralphm has joined 21:48:44
Steve Kille has left 21:52:49
j.r has left 21:53:29
j.r has joined 21:53:38
j.r has left 21:56:40
ralphm has left 21:56:41
ralphm has joined 21:56:42
j.r has joined 21:56:44
andrey.g has left 21:57:03
valo has joined 21:57:25
j.r has left 21:58:59
j.r has joined 21:59:06
rion has left 22:08:43
rion has joined 22:08:44
andrey.g has joined 22:09:36
lumi has left 22:15:32
goffi has left 22:18:48
rion has left 22:32:42
ThibG has left 23:06:05
ThibG has joined 23:06:08
blabla has left 23:08:05
blabla has joined 23:08:19
lovetox has left 23:09:05
debacle has left 23:16:03
blabla has left 23:16:54
melvo has joined 23:19:47
rtq3 has left 23:19:50
rtq3 has joined 23:20:10
rtq3 has left 23:29:02
rtq3 has joined 23:29:20
ralphm has left 23:30:11
ralphm has joined 23:30:12
ThibG has left 23:32:13
ThibG has joined 23:32:18
karoshi has left 23:35:24
rtq3 has left 23:38:54
rtq3 has joined 23:39:12
frainz has left 23:49:56
frainz has joined 23:50:03
waqas has left 23:53:52
waqas has joined 23:53:58
waqas has left 23:56:08
waqas has joined 23:56:41
waqas has left 23:56:49
rtq3 has left 23:59:59