flow: 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
Ge0rG
Wow, 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"
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
dwdhas left
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
dwdhas joined
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
Marandahas left
Marandahas joined
lovetoxhas joined
lovetox
Ge0rG why do you think 0066 is a horrible mess?
frainzhas left
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
frainzhas joined
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
rionhas left
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"?
alacerhas joined
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
larmahas joined
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
rtq3has joined
ThibGhas left
ThibGhas joined
alacerhas left
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.
andyhas left
andyhas joined
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
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
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!)
larmahas joined
dwdhas left
dwdhas joined
dwdhas left
Holger
https://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 Nenakhov
We're actually planning to make file gallery for Xabber on top of nextcloud
dwdhas left
blablahas joined
rtq3has left
rtq3has joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
dwdhas joined
Zashhas left
Zashhas joined
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
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
Andrew Nenakhovhas left
Alexhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
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?
dwdhas left
dwdhas joined
contrapunctus
(Or _remind_ them.)
dwdhas left
Andrew Nenakhovhas left
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.
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Seve
I was going towrite something like 'XMPP!11' but I would be glad if you do it, Holger :D
Andrew Nenakhovhas joined
andyhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhov
Seve, I'll take a look, yes
lumihas left
lnjhas joined
dwdhas joined
kokonoehas left
kokonoehas joined
ralphmhas joined
nyco
hello
Guus
Hi!
Seve
Hi
ralphmwaves
ralphmbangs gavel
ralphm
0. Welcome + Agenda
ralphm
Who do we have and comments on the agenda.
nyco
_o/
agenda good to me
MattJ
Hey
Seveis here
Guus
nothign to add from me
ralphm
Full house!
ralphm
1. Minute taker
ralphm
Who?
kokonoehas left
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.
kokonoehas joined
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
Seveagrees
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.
Andrew Nenakhovhas left
ralphm
Well, I think having a fresh start when it goes active makes sense.
Andrew Nenakhovhas joined
Alexhas joined
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'.
blablahas left
Marandahas left
blablahas joined
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
frainzhas left
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
andyhas left
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
dwdhas left
dwdhas joined
Guus
pep. raised some concerns in LC
pep.
(!)
dwdhas left
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.
waqashas joined
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
waqashas left
waqashas joined
Guus
(still interested in hearing from that one person you knew)
waqashas left
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.
waqashas joined
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.
karoshihas left
karoshihas joined
Kev
Guus: 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
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.
waqashas left
ralphm
That the bylaws allow for it, just makes it easier to change our mind later, without paying lawyers and such.
waqashas joined
dwdhas joined
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
waqashas left
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!
ralphmbangs 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?
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
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)
lnjhas left
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)
Sevelaughs
Seve
pep., Imagine that when applying for membership to the XSF, you have a button that says 'Log in with Facebook' :D
that's UDP -> XMPP listener -> XMPP resolver -> TCP, and back
Yagizahas left
j.rhas left
j.rhas joined
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
dwdhas joined
debaclehas left
zinid
Ge0rG: +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
Zash
Did 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.
Zash
I was convinced it was to make sure that there wasn't any trace of credentials in the parser that could leak
j.rhas joined
Zash
Also security layers, but that's gotten replaced by TLS these days
j.rhas left
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)
j.rhas joined
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
igoosehas joined
dwdhas left
dwdhas joined
jonas’
lovetox, ah, yes
jonas’
but we’re still not quite at device passwords
dwdhas left
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"
alacerhas joined
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
dwdhas joined
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
vaulorhas left
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
vaulorhas joined
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?
alacerhas left
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?
efrithas joined
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!
kokonoehas left
lovetox
So there is no perfect solution?
404.cityhas left
lovetox
DoS vector with plain, SCRAM does not work with external services and not upgradeable easily
zinid
SASL EXTERNAL, bitches!!111
kokonoehas joined
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
dwdhas left
dwdhas joined
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
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) :)
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