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