contrapunctusflow: I agree, XEP names are easier to remember than numbers
alacerhas left
olihas left
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 😉)
dwdhas left
dwdhas joined
dwdhas left
dwdhas joined
Marandahas left
Marandahas joined
lorddavidiiihas left
lorddavidiiihas joined
dwdhas left
dwdhas joined
dwdhas left
dwdhas joined
alacerhas joined
Nekithas joined
pep.wurstsalat: it is already?
alacerhas left
dwdhas left
dwdhas joined
dwdhas left
waqashas left
Marandahas left
Marandahas joined
dwdhas joined
rionhas joined
dwdhas left
dwdhas joined
dwdhas left
dwdhas joined
dwdhas left
dwdhas joined
404.cityhas joined
404.cityhas left
olihas joined
dwdhas left
vaulorhas joined
archas left
archas joined
markhas joined
dwdhas joined
blablahas left
blablahas joined
j.rhas left
j.rhas joined
dwdhas left
dwdhas joined
dwdhas left
wurstsalathas left
Nekithas left
Nekithas joined
olihas left
olihas joined
lnjhas joined
archas left
archas joined
dwdhas joined
goffihas joined
Marandahas left
Marandahas joined
Zashhas joined
andyhas joined
karoshihas joined
dwdhas left
dwdhas joined
dwdhas left
olihas left
olihas joined
Steve Killehas left
dwdhas joined
ThibGhas left
ThibGhas joined
lnjhas left
Steve Killehas joined
Marandahas left
Marandahas joined
Kevhas joined
ThibGhas left
ThibGhas joined
Ge0rGWow, the bikeshedding has started! :D
pep.I hope so
dwdhas left
dwdhas joined
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.
olihas left
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"
Ge0rGreminds 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
Ge0rGyeah, 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
dwdhas left
pep.That's why I still put up with part/join noise from Android
pep.Or iOS
Ge0rGpep.: 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>
Ge0rGpep.: 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
Ge0rGpep.: 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
dwdhas joined
Andrew NenakhovSims?! That uglyness based on yet another markup principle?
Ge0rGpep.: 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
Ge0rGAndrew 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 NenakhovBecause it is based on yet another markup principle, which is silly and unnecessary for IM
Andrew NenakhovWe 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
Guuspep. 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 NenakhovWe 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
Ge0rGAndrew 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
Guuspep. 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 NenakhovGe0rG, isn't that reference a markup? <reference xmlns='urn:xmpp:reference:0' begin='17' end='20' type='data'>
... Etc
Ge0rGpep.: are you reading my thoughts? :D
pep.Ge0rG, then please stop proposing it :(
Guusstop using PEP for your thoughts, Ge0rG
pep.kicks Guus
GuusI ment Personal Eventing, not you! 😃
Ge0rGAndrew Nenakhov: ah, that one. I never liked XEP-0372 and hope we can get SIMS independently of that as well
Ge0rGInterestingly, SIMS doesn't even mention the existence of XEP-0372
Marandahas left
Marandahas joined
lovetoxhas joined
lovetoxGe0rG why do you think 0066 is a horrible mess?
frainzhas left
Ge0rGlovetox: 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
frainzhas joined
Ge0rG4 is heavily related to 1, but still a bit different
Ge0rG5) the body=url requirement isn't documented
lovetoxDid you read my reply on the list?
lovetoxbody=url is not a requirement nor a indication for other clients to do UI actions
lovetoxits a simple fallback body like in other XEPs
lovetoxI dont see how you use any other alternative (SIMS) without providing a fallback body
lovetoxif you choose so you could do the same with 0066
rionhas left
lovetox1) yes more metadata is always nice, but i wouldnt call it a horrible mess
Ge0rGNow I wonder when / whether I used the words "horrible mess" re 0066.
Ge0rGlovetox: 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
Ge0rGtechnically 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.
lovetoxAnd 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? :)
Ge0rGdidn't you know that the C in CS-2019 is for "Conversations"?
alacerhas joined
Ge0rGConversations 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🤣
flowditto
larmahas joined
Ge0rGokay, 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
rtq3has joined
ThibGhas left
ThibGhas joined
alacerhas left
Ge0rGflow: 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.
andyhas left
andyhas joined
Seveunpopularopinion: 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
SeveProbably, jonas’, got an 'smartphone' pretty late
Marandahas left
Marandahas joined
pep.lovetox: pardon my French, I actually meant the "memo", not the "note". The O-memo.
pep.leaves now
!xsf_Martinhas joined
dwdhas left
dwdhas joined
dwdhas left
dwdhas joined
andyhas left
andyhas joined
ThibGhas left
ThibGhas joined
dwdhas left
dwdhas joined
lumihas joined
dwdhas left
alacerhas joined
alacerhas left
ThibGhas left
ThibGhas joined
dwdhas joined
andyhas left
andyhas joined
andyhas left
lskdjfhas joined
alacerhas joined
dwdhas left
dwdhas joined
dwdhas left
alacerhas left
alacerhas joined
valohas left
valohas joined
yvohas joined
rtq3has left
rtq3has joined
blablahas left
!xsf_Martinhas left
blablahas joined
dwdhas joined
dwdhas left
dwdhas joined
dwdhas left
alacerhas left
dwdhas joined
jmpmanhas joined
dwdhas left
dwdhas joined
dwdhas left
larmahas left
dwdhas joined
nycohas left
nycohas joined
HolgerThose 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
HolgerThey arrived at unique IDs a few minutes ago.
MattJ:)
Ge0rGSomebody should tell them about matrixmpp
SeveAnother 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!)
larmahas joined
dwdhas left
dwdhas joined
dwdhas left
Holgerhttps://apps.nextcloud.com/apps/ojsxc was already there, but implementing from scratch is just so much more fun.
rtq3has left
alacerhas joined
rtq3has joined
dwdhas joined
yvohas left
blablahas left
Yagizahas joined
dwdhas left
dwdhas joined
Andrew NenakhovWe're actually planning to make file gallery for Xabber on top of nextcloud
ralphmnyco: no, we need a minute taker that isn't involved in the discussion. But that's not the topic now.
nycoso, can we be a CA? do we have the resources, capacity, knowledge, process?
GuusRalph, regarding 2 - correct me if I'm wrong, but this is about accepting the XEP into 'experimental' state, right?
ralphmnyco: as I read the document, it doesn't call for the XSF being a CA
nycoah
nycomisunderstood?
MattJYes, it's not about being a CA
nycook, then what?
SeveAre we deciding on the whole XEP or just what it involves the XSF, the 2.2 section?
MattJAs described in the document, we would provide a URL that redirects to one or more CAs
ralphmSeve: I think this is just about accepting it as a XEP, not the full thing, because it is unfinished.
ralphmI have a bunch of questions on the latter, but specifically, if Experimental stage requires us to set something up already.
kokonoehas joined
MattJI imagine so
MattJzinid, around?
ralphmBecause I am indeed curious what would be in section 4
ralphmand particularly if including a CA in that redirect service will infer some kind of validity/trust/etc. in the reliability of a said CA
Seveagrees
ralphmand whether we, like browsers, need to have procedures for evaluating and possibly evicting CAs
pep.Most likely?
Guusralphm but that can be a question to be answered before moving from Experimental to Proposed, I think.
ralphmif so, I'm a bit hesitent to accept Experimental as the stage where we start up a service
ralphmhesitant even
GuusWhat 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?
Guusso, without immediately starting to provide the service
ralphmI.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.
KevYou might choose to put a new revision in first.
KevSaying ... upon advancing to Draft/equiv...
ralphmKev: unfortunately, since this is procedural, there's only Active
KevRight, I couldn't be bothered to check.
KevBut the point stands.
GuusExperimental -> Proposed -> Active ?
ralphmYeah
KevText that says "Upon advancing to Active, the XSF will ..."
Guusend-users don't see such revisions, though.
ralphmSo Kev, you mean we encode in the document that we put that caveat
KevThat way the XSF isn't obliged to do anything until they advance it.
ralphmI.e. before accepting as XEP
KevLike various other things say "Upon advancing to Draft, the Registrar..."
Kevralphm: Yes. That would address the concern, wouldn't it?
ralphmIt would
Guusalternatively, different URLs for services based on state of the XEP?
ralphmOr both
Guusunsure if non-static URLs would defeat the purpose of the XEP though.
Andrew Nenakhovhas left
ralphmWell, I think having a fresh start when it goes active makes sense.
Andrew Nenakhovhas joined
Alexhas joined
Guusit would remove the concern that you just raised (that I share)
MattJMakes sense to me
Guuszinid are you around?
ralphmThat said, I haven't read RFC 6940 yet, which describes this particular well-known URI
GuusAssuming the worst-case scenario, where it disallows this.
Guusis a disclaimer in the XEP that things shouldn't be trusted until the XEP is moved to Active state, sufficient?
ralphmWell, we could have, say, test.xmpp.org instead of just xmpp.org during the experimental stage, for the well-known to live at
KevUntil and unless :)
I think some sort of notice that it's not 'real' until Active is worthwhile.
Guusoh, that I like that pragmatic solution, Ralph
ralphmKev: does that sound good to you with your iteam hat on?
GuusKev I agree that it's worhtwhile, but I was asking if it in itself was enough.
Kevralphm: TBPH, I've not been following in enough detail to answer that, let me scroll back.
KevIf the question is 'can we host something at test.xmpp.org?' the answer is 'sure'.
blablahas left
Marandahas left
blablahas joined
KevAlthough I'm not sure whether it's worth it compared to just saying in the XEP it's not 'active' yet.
KevBut we can do it.
ralphmOk, so I think this discussion highlights our concerns, which counts as the feedback for the Author to process per Section 5 of XEP-0001.
GuusKev - 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.
KevGuus: I don't think it really does that, does it?
ralphmI move we urge the Author to process this, and resubmit.
SeveIs the Author then going to add the information regarding the process until it gets to Active?
SeveOk
frainzhas left
SeveI agree
Guus+1 on ralphm motion
ralphmI 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
GuusKev I can imagine that some software does not want to use the service until the XEP is Active.
ralphmGuus: seems to me to be a feature
SeveWhat's your take on this, MattJ and nyco?
KevGuus: 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
Guusnot having a service on the 'active' URL prevents confusion there, I think.
KevThis is a low-F issue for me.
Guuskk
MattJSounds fine to me
andyhas left
ralphmOk, motion carry. Thanks for submission zinid, we look forward for the new version.
ralphm"to"
ralphmand "carries". Typing. Sigh
ralphm3. XEP-0345
ralphmForm of Membership Applications
dwdhas left
dwdhas joined
Guuspep. raised some concerns in LC
pep.(!)
dwdhas left
Guusone of which is that the XEP specifies a restriction to natural persons, while our bylaws explicitly define other entities.
GuusI feel that that should be addressed.
waqashas joined
Guusthat's the only concern I have/share (unless others now bring up good points that I didn't think of 😛 )
Guusalso, I checked with the XSF Secretary, as this involves a process he's familiar with: he had no concerns.
MattJI'm curious what the membership feels, specifically about the requirement to list employment
ralphmIt is pretty normal for corporations to narrow down what's allowed in bylaws
MattJWe've already had discussions based on just listing names
GuusMattJ membership has had two LC's to express what they feel.
SeveI think Relevant Affiliations is important, as a member.
MattJGuus, true
ralphmThe reason for listing employment is specifically to curb influence by a one or more larger companie
ralphms
SeveExactly
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"
MattJralphm, right, but (as with name) this could potentially be privately maintained by the Secretary
pep.this ^
ralphmIt could
GuusMattJ 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.
SeveI must say members may need to know that
waqashas left
waqashas joined
Guus(still interested in hearing from that one person you knew)
waqashas left
ralphmI think that transparency on who's member of the the XSF is a good thing.
SeveI feel this XEP is only stating in writing the current and past procedure of being a member.
ralphmSeve: this is indeed its purpose
SeveWhich we should be quite comfortable with it, in my opinion.
pep.Seve, you mean you see no reason for changing it then?
pep.k
ralphmAs such, I'm not sure we should at this point discuss changes to it.
Guusagreed - but the concern regarding the more specific definition than the one in the bylaws remains.
Guuswhy are we making things more specific in this XEP?
ralphmFor 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.
waqashas joined
pep.I assume there has never been any case of a non-natural entity applying?
ralphmGuus: because that just codifies what we've been doing from the beginning.
Guuspep. that might be true, but is that a reason to now forbid it?
pep.Guus, not what I'm saying no
ralphmThere's been no need or request for a non-natural entity to be a member of the XSF.
KevGuus: I think so, yes.
pep.Just curious
Sevepep., 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
ralphmAFAIK
GuusKev curious about reasoning there.
karoshihas left
karoshihas joined
KevGuus: If it actually happened it'd be a horrendous can of worms for us.
grumpyhas left
waqashas left
pep.The issue to me really is that I don't know if there's a need for a real name.
waqashas joined
ralphmE.g. our voting process currently uses a bot with a jid that is expected to belong to a natural person.
pep.ralphm, does it?
GuusThe bylaws state that there's one person that represents the entity
Guusthat'd still work.
ralphmpep.: see Alex' e-mails around member elections or other votes
SeveWould an entity be able to be a member, and also members of that entity?
ralphmSeve: good question
ralphmI don't see a good reason for having this right now.
waqashas left
ralphmThat the bylaws allow for it, just makes it easier to change our mind later, without paying lawyers and such.
waqashas joined
dwdhas joined
Guusit's not a hill I'm going to die on.
ralphmYes, please don't die.
MattJSame here, I'm fine with it
ralphmDo we feel that we've processed feedback suffiently to vote on its advancement?
GuusI have noticed the real name remarks, but I don't share those concerns
Guusthe omission of not having a process that verifies that a real-sounding-name is indeed, real, is one that I can live with
GuusI'm happy to vote.
ralphmI motion that XEP-0345 progresses to Active.
Guus+1
pep.Not going to die on that hill either, but :/
nyco+1
waqashas left
SeveI 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)
ralphmpep.: to be sure, it being Active doesn't mean it can't change later
ralphm+1
SeveI 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)
ralphmMattJ?
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?)
MattJMy opinion here is that, as was mentioned, we're documenting what we're currently doing in practice
ralphmmotion carries. Let the Editors go through to the mechanics to move XEP-0345 to Active.
Guusjonas’ ^
Sevepep., what is a bootstrap issue?
ralphmpep.: 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
GuusMy remaining available time is limited.
nycoaka chicken and egg
ralphmGuus: mine too
ralphmSince we're 48 minutes in, I'd like to move the remaining items to next week.
MattJwfm
ralphm4. Date of Next
ralphm+1W
Guuswfm
ralphm5. Close
ralphmThanks all!
ralphmbangs gavel
GuusThank you
MattJThanks!
nycothx all
SeveThank you, everybody :)
Sevepep., 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"
ralphmpep.: 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
ralphmI 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).
ZashI 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.
ralphmI also want to note that having this discussion doesn't require pre-existing membership.
ralphmZash: that was mentioned
ZashCheck
SeveIf that was the case, would you need a reason to hide your name to the members?
lovetoxhas left
pep.what is visible to members is usually visible to everyone
alacerhas left
pep.Seve, Secretary-only might still not be a valid solution to some fwiw
ralphmI think the only non-public thing in the XSF is the Board mailing list.
SeveI 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)
lnjhas left
SeveFor now though, even I always cared of having a digital life and a 'real' life completely decoupled, I agree with ralphm about transparency
KevIf 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)
Sevelaughs
Sevepep., 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.
Sevepep., 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
SeveI know :)
pep.Same, fwiw, but that's not why I answered that
rtq3has left
rtq3has joined
zinidoh, I slept away the meeting
frainzhas joined
jmpmanhas left
Marandahas joined
lnjhas joined
mrDoctorWhohas left
mrDoctorWhohas joined
Marandahas left
Marandahas joined
vaulorhas left
vaulorhas joined
alacerhas joined
dwdhas left
dwdhas joined
dwdhas left
dwdhas joined
lnjhas left
Marandahas left
Marandahas joined
dwdhas left
dwdhas joined
dwdhas left
kokonoehas left
melvohas left
kokonoehas joined
melvohas joined
blablahas left
debaclehas joined
waqashas joined
blablahas joined
Steve Killehas left
ralphmzinid: hope you can work with the comments made during the meeting
moparisthebestthat's UDP -> XMPP listener -> XMPP resolver -> TCP, and back
Yagizahas left
j.rhas left
j.rhas joined
moparisthebestwire 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>
moparisthebestwhich is a real request+response for $ dig -p5354 @127.0.0.1 +short +tcp example.org -> 93.184.216.34 cc Wiktor :)
moparisthebestI'll have the code pushed up tonight
Wiktormoparisthebest: 👏 looking forward to seeing your code
jonas’and I thought I was weird
SeveHaha jonas’
moparisthebestZash, 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
moparisthebestit'd be easy to set up a public "bootstrap account" like that which is firewalled off from talking to anything else but the resolver
Ge0rGmoparisthebest: you should have some obfuscated AFD reference in the namespace tag.
Ge0rGmoparisthebest: +1 for anonymous auth
moparisthebestwhat's AFD ?
Ge0rGApril Fool's Day
moparisthebestah right, I think it's better to leave everyone wondering forever if it's serious or april fools joke :P
Ge0rGmoparisthebest: can we have some interesting / sensible disco#items offering as well?
moparisthebestI mean, it works, *could* be useful, meh
Ge0rGmoparisthebest: oh. There is a category of XEP to spoil that.
moparisthebestright I think it should be Standards Track instead of Humorous for the same reason :D
Ge0rG🤔
moparisthebestyes, ideally everyone that looks at it has that expression on their face forever
Ge0rGmoparisthebest: also can one subscribe to NOTIFY events over XMPP? That would be a real benefit
Ge0rGmoparisthebest: I'm not sure council will be able and willing to follow that argumentation
moparisthebestyea it's up to them of course, but I can try :)
moparisthebestit's no more silly than DoH which is a *real thing (tm)*
Ge0rGI'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
moparisthebestthat makes it *more* efficient than DoH if you only connect once and send multiple queries over hours/days/years
Ge0rGTouche
dwdhas joined
debaclehas left
zinidGe0rG: +1 and the reason I don't want new SASL or how it's called
lovetoxhas joined
marc_has left
ThibGhas left
ThibGhas joined
dwdhas left
dwdhas joined
dwdhas left
Marandahas left
Marandahas joined
dwdhas joined
j.rhas left
neshtaxmpphas joined
ralphmhas left
marc_has joined
j.rhas joined
rtq3has left
rtq3has joined
ThibGhas left
ThibGhas joined
dwdhas left
dwdhas joined
dwdhas left
lumihas joined
lnjhas joined
lorddavidiiihas left
lorddavidiiihas joined
vanitasvitaehas left
vanitasvitaehas joined
waqashas left
j.rhas left
j.rhas joined
lnjhas left
dwdhas joined
j.rhas left
j.rhas joined
igoosehas left
j.rhas left
j.rhas joined
dwdhas left
dwdhas joined
kokonoehas left
kokonoehas joined
valohas left
melvohas left
dwdhas left
melvohas joined
melvohas left
jonas’zinid, wat? SASL2 is supposed to reduce number of roundtrips
jonas’it saves a stream reset
dwdhas joined
j.rhas left
j.rhas joined
404.cityhas joined
j.rhas left
ZashDid anyone remember why that stream reset exists?
lnjhas joined
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.
ZashI was convinced it was to make sure that there wasn't any trace of credentials in the parser that could leak
j.rhas joined
ZashAlso security layers, but that's gotten replaced by TLS these days
j.rhas left
moparisthebestwhat'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)
j.rhas joined
Zashmoparisthebest: You mean how it was before?
jonas’moparisthebest, SASL gives you flexibility and good stuff like SCRAM
moparisthebestworded another way, if TLS is mandatory, what's the point
ZashSCRAM
jonas’SCRAM allows both parties to not store the plain text password
moparisthebestjonas’, is that "hiding password from server" ?
moparisthebesteh
ZashHides password from everyone
jonas’avoiding to ever have to store the plaintext password
jonas’which is a good thing
moparisthebestis that really worth all the complexity?
ZashClient can store magic hashes, magic hashes sent on the wire, magic hashes stored on the server.
jonas’SCRAM isn’t that complex
ZashIt's fairly simple in fact
ZashBut maybe that's just bias from exposure to DIGEST-MD5
moparisthebestand un-upgradeable etc etc if I follow along correctly?
HolgerAnd expensive if you allow PLAIN.
ZashWhy would you upgrade again?
moparisthebestsounds pretty expensive/complex overall, for almost no benefit, to me
jonas’e2ee is more complex
jonas’;P
zinidHolger, in that SCRAM mail thread I'm told to adjust the server capacity (read: hardware is cheap). This is pathetic.
lovetoxDid it not only have value if we assume people use the same password often on many services?
zinidit'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`)
lovetoxjonas’, i think this is only true if you assume the password is not a unique password for only that service
igoosehas joined
dwdhas left
dwdhas joined
jonas’lovetox, ah, yes
jonas’but we’re still not quite at device passwords
dwdhas left
lovetoxwhich is probably a correct assumption for most people in this world
moparisthebestbut 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
lovetoxmoparisthebest, you maybe :)
moparisthebestsimple auth would also support per device passwords, TOTP etc etc
lovetoxi know my parents are definitly not at one password per service :D
moparisthebestisn'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
moparisthebestwell, those people also don't use XMPP :'(
jonas’not quite true
lovetoxmoparisthebest, if this would be true there would be no value in services like "is my password pwned"
alacerhas joined
lovetoxdont know what the name of the site was
jonas’haveibeenpwned
jonas’or something like that
lovetoxyeah
moparisthebestanother argument would be, XMPP is basically the only thing that goes through these lengths not to store password, so what's the point
moparisthebestif 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
dwdhas joined
lovetoxfrom a client pov, this is not much work to implement
lovetoxfrom a server pov it probably has downsides
lovetoxbut also some upsides
Holgerlovetox: 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.
HolgerAnd obviously they must be successful in taking over your server in the first place 🙂
lovetoxHolger i think the most likely scenario is, your server gets pwned
lovetoxthey steal the emails and passwords
lovetoxand try other services
lovetoxnot other xmpp accounts
jonas’good thing XMPP services don’t store emails :)
moparisthebestwhich bcrypt/scrypt/pbkf2 etc all have had solved for years
vaulorhas left
lovetoxas a server hoster i would see it as a positive if i know i dont store real passwords from users
moparisthebestservers don't store plaintext passwords anyway
vaulorhas joined
moparisthebestI think it's worthless for the client not to store it basically :/
ZashSCRAM uses PBKDF2 already
ZashAlong with one weird trick that means you don't have to do the expensive computation
lovetoxmoparisthebest, what do you mean they dont store it in plaintext? how do they authenticate a PLAIN connection than?
alacerhas left
moparisthebestthey store them hashed
jonas’lovetox, ... by pbkdf2-ing things and comparing hashes?
zinidSASL EXTERNAL!!!1111
Holgerlovetox: 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.
lovetoxjonas’, so why use SCRAM then?
efrithas joined
jonas’lovetox, less expensive when both sides support it
jonas’Holger, except for the upgradability, *does* it have downsides?
zinidjonas’, external services?
ZashAnd 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.
Holgerjonas’: 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.
moparisthebestZash, so it prevents you from needing to store plaintext on client, that's the only benefit, and it requires plaintext on client to upgrade?
moparisthebestwhat'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
HolgerYes, I wasn't making your assumption.
HolgerOf course it's an alternative.
Zashmoparisthebest: Ugh. I don't even.
zinidis storing plaintext an alternative? I don't think that's what users expect you to do
zinidbut you can lie of course!
kokonoehas left
lovetoxSo there is no perfect solution?
404.cityhas left
lovetoxDoS vector with plain, SCRAM does not work with external services and not upgradeable easily
zinidSASL EXTERNAL, bitches!!111
kokonoehas joined
lovetoxhow does that work, you authenticate over another channel?
Zashzinid: Also problematic
moparisthebestif... all HTTP services ever can handle the "DoS vector of plain" then I'm pretty sure XMPP servers can
Zashzinid: Or rather, which kind of SASL EXTERNAL?
zinidZash, X.509 certs
zinidZash, also, you can say about everything "also problematic"
moparisthebestHTTP has far more auths in comparison, sometimes on every request
zinidread this http://upload.zinid.ru/xep-eax-csr.html (it's not finished, I'm still working on it)
Holgerzinid: 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.
Zashzinid: Mostly I'm concerned about certificates being sent in the clear, tho maybe TLS 1.3 fixed that. Not sure.
zinidHolger, yeah, but the ones who question are very loud
HolgerIndeed.
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.
zinidZash, it's fixed in TLS1.3, we checked that with Wiktor recently
zinidZash, both client and server certs are now encrypted
Holgerjonas’: Yes, and my point above was that this is more of a hype thing than a sensible practice.
Zashzinid: Then yes, client certs are pretty nice
zinidZash, 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?
zinidfeedback is welcome even at this stage of the scribble
dwdhas left
dwdhas joined
lovetoxbut how does the client obtain the client cert? what if he changes device?
Holgerjonas’: 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
zinidlovetox, sigh, look at my proposal please 🙁
jonas’(I’m storing passwords with SSHA, which is pretty much plaintext for a determined attacker)
zinidat least at intro
lovetoxyeah im reading now
lovetoxsorry :)
Holgerjonas’: 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"
HolgerAll else being equal, sure. That's stating the obvious. The hype is about stopping at this point.
jonas’I see
rtq3has left
dwdhas left
efrithas left
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) :)
moparisthebestit's invisible to users anyway
moparisthebestI don't know what conversations, gajim, dino do when I type my password in
pep.It is indeed
moparisthebestif anything, users expect the website they type their user+pass in to have their user+pass
dwdhas joined
moparisthebestbecause that's how every website ever works