XSF Discussion - 2019-03-07

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