XSF Discussion - 2019-03-07

  1. contrapunctus

    flow: I agree, XEP names are easier to remember than numbers

  2. contrapunctus

    (Funny that this has to be argued with with people who advocate JIDs over phone numbers šŸ˜‰) ✎

  3. contrapunctus

    (Funny that this has to be argued with with people who advocate JIDs over phone numbers, for the same reasons šŸ˜‰) ✏

  4. pep.

    wurstsalat: it is already?

  5. Ge0rG

    Wow, the bikeshedding has started! :D

  6. pep.

    I hope so

  7. 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.

  8. 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/>?

  9. pep.

    As well as when I part

  10. pep.

    (I mean, my client, automatically)

  11. 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

  12. pep.

    "screw pidgin"? That's my thoughts

  13. jonasā€™

    screw pidgin sounds like a plan

  14. pep.

    jonasā€™, I think the line is pretty thin nonetheless

  15. jonasā€™

    it is

  16. jonasā€™

    Iā€™d say though, anything which makes users lose actual content is non-negotiable

  17. pep.

    What is "actual content"

  18. 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.

  19. jonasā€™

    pep., message bodies. for example, it would be non-acceptable if XHTML-IM did not specify a plain-text <body/> fallback.

  20. jonasā€™

    or what Ge0rG says

  21. pep.

    I say actual content goes further than that tbh. Context is as much important to me than the message

  22. 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

  23. jonasā€™

    pep., itā€™s a minimum, not an absolute definition

  24. pep.

    That's why I still put up with part/join noise from Android

  25. pep.

    Or iOS

  26. Ge0rG

    pep.: what's your point re 0066?

  27. pep.

    (and I can tell you it's ugly)

  28. pep.

    Ge0rG, body = oob is less than optimal. I can already do that better in xhtml-im tbh.

  29. pep.

    Better

  30. pep.

    <p>Foo <img src="https://bar/baz.png"/> look at my picture!</p>

  31. Ge0rG

    pep.: there was a section in my mail starting with "While XEP-0066 is less than ideal" :P

  32. pep.

    But you're still pushing for it

  33. Ge0rG

    pep.: and your counter-proposal is "Use XHTML-IM for inline media"?

  34. pep.

    That's one of the counter-proposals I guess yes

  35. pep.

    SIMS is another obvious solution

  36. Andrew Nenakhov

    Sims?! That uglyness based on yet another markup principle?

  37. 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.

  38. pep.

    ?

  39. pep.

    (that was for Andrew Nenakhov)

  40. pep.

    In any case I agree with daniel's point. It's not the time anymore

  41. pep.

    And hmm, I'm not entirely sure that's what's actually perceived re CS

  42. 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.

  43. Andrew Nenakhov

    Because it is based on yet another markup principle, which is silly and unnecessary for IM

  44. 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

  45. 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.

  46. 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

  47. Ge0rG

    Andrew Nenakhov: I don't see any body markup in the XEP, besides of the XHTML-IM example, where it's obviously appropriate

  48. Guus

    (let's not wait discussing things, which will only delay 2020)

  49. pep.

    Guus, yes that's what daniel said, this can go in 2020, it doesn't have to keep 2019 waiting

  50. Guus

    pep. exactly. I agree with that (but let's not stop discussing things because they won't go in '19!)

  51. pep.

    Also in the meantime we can implement a proper solution and stop talking about oob for this use-case altogether :)

  52. Andrew Nenakhov

    Ge0rG, isn't that reference a markup? <reference xmlns='urn:xmpp:reference:0' begin='17' end='20' type='data'> ... Etc

  53. Ge0rG

    pep.: are you reading my thoughts? :D

  54. pep.

    Ge0rG, then please stop proposing it :(

  55. Guus

    stop using PEP for your thoughts, Ge0rG

  56. pep. kicks Guus

  57. Guus

    I ment Personal Eventing, not you! šŸ˜ƒ

  58. Ge0rG

    Andrew Nenakhov: ah, that one. I never liked XEP-0372 and hope we can get SIMS independently of that as well

  59. Ge0rG

    Interestingly, SIMS doesn't even mention the existence of XEP-0372

  60. lovetox

    Ge0rG why do you think 0066 is a horrible mess?

  61. 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

  62. Ge0rG

    4 is heavily related to 1, but still a bit different

  63. Ge0rG

    5) the body=url requirement isn't documented

  64. lovetox

    Did you read my reply on the list?

  65. lovetox

    body=url is not a requirement nor a indication for other clients to do UI actions

  66. lovetox

    its a simple fallback body like in other XEPs

  67. lovetox

    I dont see how you use any other alternative (SIMS) without providing a fallback body

  68. lovetox

    if you choose so you could do the same with 0066

  69. lovetox

    1) yes more metadata is always nice, but i wouldnt call it a horrible mess

  70. Ge0rG

    Now I wonder when / whether I used the words "horrible mess" re 0066.

  71. 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

  72. 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

  73. 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.

  74. lovetox

    And what Conversations does is how the world implements something or ..?!

  75. pep.

    lovetox, yes? it's been a while we've renamed to The Conversations Protocol, you missed the note? :)

  76. Ge0rG

    didn't you know that the C in CS-2019 is for "Conversations"?

  77. Ge0rG

    Conversations at least has spiked mobile XMPP adoption in the last years, _despite_ its UX

  78. jonasā€™

    I think "because of", actually

  79. pep.

    yeah, I'd say so as well

  80. Ge0rG

    šŸ¤£

  81. flow

    ditto

  82. 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

  83. 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.

  84. 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

  85. jonasā€™

    Seve, maybe you are like me and youā€™re not familiar with how stuff works on android

  86. jonasā€™

    that was it for me, at least

  87. Seve

    Probably, jonasā€™, got an 'smartphone' pretty late

  88. pep.

    lovetox: pardon my French, I actually meant the "memo", not the "note". The O-memo.

  89. pep. leaves now

  90. 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

  91. Holger

    They arrived at unique IDs a few minutes ago.

  92. MattJ

    :)

  93. Ge0rG

    Somebody should tell them about matrixmpp

  94. 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!)

  95. Holger

    https://apps.nextcloud.com/apps/ojsxc was already there, but implementing from scratch is just so much more fun.

  96. Andrew Nenakhov

    We're actually planning to make file gallery for Xabber on top of nextcloud

  97. Seve

    Andrew Nenakhov, https://www.goffi.org/b/hGKs6B4wd8dsgNZd5MzQjN/file-sharing-landing-next-release-salut

  98. Seve

    Maybe you want to explore what goffi has been working on for this kind of feature

  99. 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?

  100. moparisthebest

    New iq child element*

  101. contrapunctus

    Holger: why not inform them?

  102. contrapunctus

    (Or _remind_ them.)

  103. Holger

    contrapunctus: I doubt they haven't heard of JSXC, but yes I think I'll gonna troll that issue of nobody else does.

  104. Holger

    But now ... meeting.

  105. Seve

    I was going towrite something like 'XMPP!11' but I would be glad if you do it, Holger :D

  106. Andrew Nenakhov

    Seve, I'll take a look, yes

  107. nyco

    hello

  108. Guus

    Hi!

  109. Seve

    Hi

  110. ralphm waves

  111. ralphm bangs gavel

  112. ralphm

    0. Welcome + Agenda

  113. ralphm

    Who do we have and comments on the agenda.

  114. nyco

    _o/ agenda good to me

  115. MattJ

    Hey

  116. Seve is here

  117. Guus

    nothign to add from me

  118. ralphm

    Full house!

  119. ralphm

    1. Minute taker

  120. ralphm

    Who?

  121. ralphm

    Well, that's disappointing.

  122. ralphm

    2. E2E Auth, CA req

  123. nyco

    we should all edit the same doc in real time while having conversations here

  124. ralphm

    https://xmpp.org/extensions/inbox/eax-car.html

  125. ralphm

    nyco: no, we need a minute taker that isn't involved in the discussion. But that's not the topic now.

  126. nyco

    so, can we be a CA? do we have the resources, capacity, knowledge, process?

  127. Guus

    Ralph, regarding 2 - correct me if I'm wrong, but this is about accepting the XEP into 'experimental' state, right?

  128. ralphm

    nyco: as I read the document, it doesn't call for the XSF being a CA

  129. nyco

    ah

  130. nyco

    misunderstood?

  131. MattJ

    Yes, it's not about being a CA

  132. nyco

    ok, then what?

  133. Seve

    Are we deciding on the whole XEP or just what it involves the XSF, the 2.2 section?

  134. MattJ

    As described in the document, we would provide a URL that redirects to one or more CAs

  135. ralphm

    Seve: I think this is just about accepting it as a XEP, not the full thing, because it is unfinished.

  136. ralphm

    I have a bunch of questions on the latter, but specifically, if Experimental stage requires us to set something up already.

  137. MattJ

    I imagine so

  138. MattJ

    zinid, around?

  139. ralphm

    Because I am indeed curious what would be in section 4

  140. 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

  141. Seve agrees

  142. ralphm

    and whether we, like browsers, need to have procedures for evaluating and possibly evicting CAs

  143. pep.

    Most likely?

  144. Guus

    ralphm but that can be a question to be answered before moving from Experimental to Proposed, I think.

  145. ralphm

    if so, I'm a bit hesitent to accept Experimental as the stage where we start up a service

  146. ralphm

    hesitant even

  147. 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?

  148. Guus

    so, without immediately starting to provide the service

  149. 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.

  150. Kev

    You might choose to put a new revision in first.

  151. Kev

    Saying ... upon advancing to Draft/equiv...

  152. ralphm

    Kev: unfortunately, since this is procedural, there's only Active

  153. Kev

    Right, I couldn't be bothered to check.

  154. Kev

    But the point stands.

  155. Guus

    Experimental -> Proposed -> Active ?

  156. ralphm

    Yeah

  157. Kev

    Text that says "Upon advancing to Active, the XSF will ..."

  158. Guus

    end-users don't see such revisions, though.

  159. ralphm

    So Kev, you mean we encode in the document that we put that caveat

  160. Kev

    That way the XSF isn't obliged to do anything until they advance it.

  161. ralphm

    I.e. before accepting as XEP

  162. Kev

    Like various other things say "Upon advancing to Draft, the Registrar..."

  163. Kev

    ralphm: Yes. That would address the concern, wouldn't it?

  164. ralphm

    It would

  165. Guus

    alternatively, different URLs for services based on state of the XEP?

  166. ralphm

    Or both

  167. Guus

    unsure if non-static URLs would defeat the purpose of the XEP though.

  168. ralphm

    Well, I think having a fresh start when it goes active makes sense.

  169. Guus

    it would remove the concern that you just raised (that I share)

  170. MattJ

    Makes sense to me

  171. Guus

    zinid are you around?

  172. ralphm

    That said, I haven't read RFC 6940 yet, which describes this particular well-known URI

  173. Guus

    Assuming the worst-case scenario, where it disallows this.

  174. Guus

    is a disclaimer in the XEP that things shouldn't be trusted until the XEP is moved to Active state, sufficient?

  175. 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

  176. Kev

    Until and unless :) I think some sort of notice that it's not 'real' until Active is worthwhile.

  177. Guus

    oh, that I like that pragmatic solution, Ralph

  178. ralphm

    Kev: does that sound good to you with your iteam hat on?

  179. Guus

    Kev I agree that it's worhtwhile, but I was asking if it in itself was enough.

  180. Kev

    ralphm: TBPH, I've not been following in enough detail to answer that, let me scroll back.

  181. Kev

    If the question is 'can we host something at test.xmpp.org?' the answer is 'sure'.

  182. Kev

    Although I'm not sure whether it's worth it compared to just saying in the XEP it's not 'active' yet.

  183. Kev

    But we can do it.

  184. 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.

  185. 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.

  186. Kev

    Guus: I don't think it really does that, does it?

  187. ralphm

    I move we urge the Author to process this, and resubmit.

  188. Seve

    Is the Author then going to add the information regarding the process until it gets to Active?

  189. Seve

    Ok

  190. Seve

    I agree

  191. Guus

    +1 on ralphm motion

  192. ralphm

    I don't think we are asking for a fully specced out Business Rules section, yet. That can be done while Experimental.

  193. ralphm

    +1

  194. Seve

    +1

  195. Guus

    Kev I can imagine that some software does not want to use the service until the XEP is Active.

  196. ralphm

    Guus: seems to me to be a feature

  197. Seve

    What's your take on this, MattJ and nyco?

  198. 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.

  199. nyco

    +1 for resubmit for Business Rules, I'd like to see a non-empty section, at least mentioning some identified problematics

  200. Guus

    not having a service on the 'active' URL prevents confusion there, I think.

  201. Kev

    This is a low-F issue for me.

  202. Guus

    kk

  203. MattJ

    Sounds fine to me

  204. ralphm

    Ok, motion carry. Thanks for submission zinid, we look forward for the new version.

  205. ralphm

    "to"

  206. ralphm

    and "carries". Typing. Sigh

  207. ralphm

    3. XEP-0345

  208. ralphm

    Form of Membership Applications

  209. Guus

    pep. raised some concerns in LC

  210. pep.

    (!)

  211. Guus

    one of which is that the XEP specifies a restriction to natural persons, while our bylaws explicitly define other entities.

  212. Guus

    I feel that that should be addressed.

  213. Guus

    that's the only concern I have/share (unless others now bring up good points that I didn't think of šŸ˜› )

  214. Guus

    also, I checked with the XSF Secretary, as this involves a process he's familiar with: he had no concerns.

  215. MattJ

    I'm curious what the membership feels, specifically about the requirement to list employment

  216. ralphm

    It is pretty normal for corporations to narrow down what's allowed in bylaws

  217. MattJ

    We've already had discussions based on just listing names

  218. Guus

    MattJ membership has had two LC's to express what they feel.

  219. Seve

    I think Relevant Affiliations is important, as a member.

  220. MattJ

    Guus, true

  221. ralphm

    The reason for listing employment is specifically to curb influence by a one or more larger companie

  222. ralphm

    s

  223. Seve

    Exactly

  224. 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"

  225. MattJ

    ralphm, right, but (as with name) this could potentially be privately maintained by the Secretary

  226. pep.

    this ^

  227. ralphm

    It could

  228. 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.

  229. Seve

    I must say members may need to know that

  230. Guus

    (still interested in hearing from that one person you knew)

  231. ralphm

    I think that transparency on who's member of the the XSF is a good thing.

  232. Seve

    I feel this XEP is only stating in writing the current and past procedure of being a member.

  233. ralphm

    Seve: this is indeed its purpose

  234. Seve

    Which we should be quite comfortable with it, in my opinion.

  235. pep.

    Seve, you mean you see no reason for changing it then?

  236. pep.

    k

  237. ralphm

    As such, I'm not sure we should at this point discuss changes to it.

  238. Guus

    agreed - but the concern regarding the more specific definition than the one in the bylaws remains.

  239. Guus

    why are we making things more specific in this XEP?

  240. 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.

  241. pep.

    I assume there has never been any case of a non-natural entity applying?

  242. ralphm

    Guus: because that just codifies what we've been doing from the beginning.

  243. Guus

    pep. that might be true, but is that a reason to now forbid it?

  244. pep.

    Guus, not what I'm saying no

  245. ralphm

    There's been no need or request for a non-natural entity to be a member of the XSF.

  246. Kev

    Guus: I think so, yes.

  247. pep.

    Just curious

  248. 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

  249. ralphm

    AFAIK

  250. Guus

    Kev curious about reasoning there.

  251. Kev

    Guus: If it actually happened it'd be a horrendous can of worms for us.

  252. pep.

    The issue to me really is that I don't know if there's a need for a real name.

  253. ralphm

    E.g. our voting process currently uses a bot with a jid that is expected to belong to a natural person.

  254. pep.

    ralphm, does it?

  255. Guus

    The bylaws state that there's one person that represents the entity

  256. Guus

    that'd still work.

  257. ralphm

    pep.: see Alex' e-mails around member elections or other votes

  258. Seve

    Would an entity be able to be a member, and also members of that entity?

  259. ralphm

    Seve: good question

  260. ralphm

    I don't see a good reason for having this right now.

  261. ralphm

    That the bylaws allow for it, just makes it easier to change our mind later, without paying lawyers and such.

  262. Guus

    it's not a hill I'm going to die on.

  263. ralphm

    Yes, please don't die.

  264. MattJ

    Same here, I'm fine with it

  265. ralphm

    Do we feel that we've processed feedback suffiently to vote on its advancement?

  266. Guus

    I have noticed the real name remarks, but I don't share those concerns

  267. 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

  268. Guus

    I'm happy to vote.

  269. ralphm

    I motion that XEP-0345 progresses to Active.

  270. Guus

    +1

  271. pep.

    Not going to die on that hill either, but :/

  272. nyco

    +1

  273. 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 ✎

  274. Guus

    (let the records reflect that pep. is looking sad on a hill)

  275. ralphm

    pep.: to be sure, it being Active doesn't mean it can't change later

  276. ralphm

    +1

  277. 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 ✏

  278. ralphm

    (Guus: I welcome you to write the minutes)

  279. ralphm

    MattJ?

  280. MattJ

    +1 from me

  281. 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

  282. pep.

    (bootstraping issues?)

  283. MattJ

    My opinion here is that, as was mentioned, we're documenting what we're currently doing in practice

  284. ralphm

    motion carries. Let the Editors go through to the mechanics to move XEP-0345 to Active.

  285. Guus

    jonasā€™ ^

  286. Seve

    pep., what is a bootstrap issue?

  287. ralphm

    pep.: you having an opinion on this and being a member seems to be counter your point.

  288. pep.

    Seve, you need enough of something already to have something carry on, or even be a thing

  289. Guus

    My remaining available time is limited.

  290. nyco

    aka chicken and egg

  291. ralphm

    Guus: mine too

  292. ralphm

    Since we're 48 minutes in, I'd like to move the remaining items to next week.

  293. MattJ

    wfm

  294. ralphm

    4. Date of Next

  295. ralphm

    +1W

  296. Guus

    wfm

  297. ralphm

    5. Close

  298. ralphm

    Thanks all!

  299. ralphm bangs gavel

  300. Guus

    Thank you

  301. MattJ

    Thanks!

  302. nyco

    thx all

  303. Seve

    Thank you, everybody :)

  304. 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?

  305. pep.

    replace the last "we don't want" by "it is unlikely"

  306. 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.

  307. pep.

    Ok

  308. 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

  309. 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).

  310. 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.

  311. ralphm

    I also want to note that having this discussion doesn't require pre-existing membership.

  312. ralphm

    Zash: that was mentioned

  313. Zash

    Check

  314. Seve

    If that was the case, would you need a reason to hide your name to the members?

  315. pep.

    what is visible to members is usually visible to everyone

  316. pep.

    Seve, Secretary-only might still not be a valid solution to some fwiw

  317. ralphm

    I think the only non-public thing in the XSF is the Board mailing list.

  318. 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)

  319. 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

  320. 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.

  321. pep.

    I think transparency should be in acts

  322. 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..

  323. pep.

    (Maybe I should)

  324. Seve laughs

  325. Seve

    pep., Imagine that when applying for membership to the XSF, you have a button that says 'Log in with Facebook' :D

  326. pep.

    I wouldn't apply.

  327. Seve

    pep., I would not even be able to!

  328. Seve

    (I don't have an account there)

  329. pep.

    Same, fwiw, but that wasn't why I answered that ✎

  330. Seve

    I know :)

  331. pep.

    Same, fwiw, but that's not why I answered that ✏

  332. zinid

    oh, I slept away the meeting

  333. ralphm

    zinid: hope you can work with the comments made during the meeting

  334. moparisthebest

    $ dig -p5354 @127.0.0.1 +short debian.org 5.153.231.4

  335. moparisthebest

    got DoX working

  336. moparisthebest

    that's UDP -> XMPP listener -> XMPP resolver -> TCP, and back

  337. 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>

  338. moparisthebest

    which is a real request+response for $ dig -p5354 @127.0.0.1 +short +tcp example.org -> 93.184.216.34 cc Wiktor :)

  339. moparisthebest

    I'll have the code pushed up tonight

  340. Wiktor

    moparisthebest: šŸ‘ looking forward to seeing your code

  341. jonasā€™

    and I thought I was weird

  342. Seve

    Haha jonasā€™

  343. 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

  344. 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

  345. Ge0rG

    moparisthebest: you should have some obfuscated AFD reference in the namespace tag.

  346. Ge0rG

    moparisthebest: +1 for anonymous auth

  347. moparisthebest

    what's AFD ?

  348. Ge0rG

    April Fool's Day

  349. moparisthebest

    ah right, I think it's better to leave everyone wondering forever if it's serious or april fools joke :P

  350. Ge0rG

    moparisthebest: can we have some interesting / sensible disco#items offering as well?

  351. moparisthebest

    I mean, it works, *could* be useful, meh

  352. Ge0rG

    moparisthebest: oh. There is a category of XEP to spoil that.

  353. moparisthebest

    right I think it should be Standards Track instead of Humorous for the same reason :D

  354. Ge0rG

    šŸ¤”

  355. moparisthebest

    yes, ideally everyone that looks at it has that expression on their face forever

  356. Ge0rG

    moparisthebest: also can one subscribe to NOTIFY events over XMPP? That would be a real benefit

  357. Ge0rG

    moparisthebest: I'm not sure council will be able and willing to follow that argumentation

  358. moparisthebest

    yea it's up to them of course, but I can try :)

  359. moparisthebest

    it's no more silly than DoH which is a *real thing (tm)*

  360. 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

  361. moparisthebest

    that makes it *more* efficient than DoH if you only connect once and send multiple queries over hours/days/years

  362. Ge0rG

    Touche

  363. zinid

    Ge0rG: +1 and the reason I don't want new SASL or how it's called

  364. jonasā€™

    zinid, wat? SASL2 is supposed to reduce number of roundtrips

  365. jonasā€™

    it saves a stream reset

  366. Zash

    Did anyone remember why that stream reset exists?

  367. jonasā€™

    the wording in RFC 6120 which I remember talks about something security I think

  368. 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.

  369. Zash

    I was convinced it was to make sure that there wasn't any trace of credentials in the parser that could leak

  370. Zash

    Also security layers, but that's gotten replaced by TLS these days

  371. 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?

  372. Zash

    (DIGEST-MD5 could include negotiation of encryption)

  373. Zash

    moparisthebest: You mean how it was before?

  374. jonasā€™

    moparisthebest, SASL gives you flexibility and good stuff like SCRAM

  375. moparisthebest

    worded another way, if TLS is mandatory, what's the point

  376. Zash

    SCRAM

  377. jonasā€™

    SCRAM allows both parties to not store the plain text password

  378. moparisthebest

    jonasā€™, is that "hiding password from server" ?

  379. moparisthebest

    eh

  380. Zash

    Hides password from everyone

  381. jonasā€™

    avoiding to ever have to store the plaintext password

  382. jonasā€™

    which is a good thing

  383. moparisthebest

    is that really worth all the complexity?

  384. Zash

    Client can store magic hashes, magic hashes sent on the wire, magic hashes stored on the server.

  385. jonasā€™

    SCRAM isnā€™t that complex

  386. Zash

    It's fairly simple in fact

  387. Zash

    But maybe that's just bias from exposure to DIGEST-MD5

  388. moparisthebest

    and un-upgradeable etc etc if I follow along correctly?

  389. Holger

    And expensive if you allow PLAIN.

  390. Zash

    Why would you upgrade again?

  391. moparisthebest

    sounds pretty expensive/complex overall, for almost no benefit, to me

  392. jonasā€™

    e2ee is more complex

  393. jonasā€™

    ;P

  394. zinid

    Holger, in that SCRAM mail thread I'm told to adjust the server capacity (read: hardware is cheap). This is pathetic.

  395. lovetox

    Did it not only have value if we assume people use the same password often on many services?

  396. zinid

    it's like suggesting using O(N) instead of O(log(N)) and "adjust the capacity"

  397. 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`)

  398. lovetox

    jonasā€™, i think this is only true if you assume the password is not a unique password for only that service

  399. jonasā€™

    lovetox, ah, yes

  400. jonasā€™

    but weā€™re still not quite at device passwords

  401. lovetox

    which is probably a correct assumption for most people in this world

  402. moparisthebest

    but we've long been at "seperate password for each service" so I don't get the point

  403. jonasā€™

    moparisthebest, thatā€™s the ideal world, but not the real world

  404. lovetox

    moparisthebest, you maybe :)

  405. moparisthebest

    simple auth would also support per device passwords, TOTP etc etc

  406. lovetox

    i know my parents are definitly not at one password per service :D

  407. moparisthebest

    isn't "use a password manager" basically been the industry standard advice for years now?

  408. jonasā€™

    you confuse the industry with what normal people do in the real world

  409. moparisthebest

    well, those people also don't use XMPP :'(

  410. jonasā€™

    not quite true

  411. lovetox

    moparisthebest, if this would be true there would be no value in services like "is my password pwned"

  412. lovetox

    dont know what the name of the site was

  413. jonasā€™

    haveibeenpwned

  414. jonasā€™

    or something like that

  415. lovetox

    yeah

  416. 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

  417. moparisthebest

    if you don't re-use it, it doesn't matter, if you do it's everywhere elso on your computer in plaintext?

  418. 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

  419. lovetox

    from a client pov, this is not much work to implement

  420. lovetox

    from a server pov it probably has downsides

  421. lovetox

    but also some upsides

  422. 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.

  423. Holger

    And obviously they must be successful in taking over your server in the first place šŸ™‚

  424. lovetox

    Holger i think the most likely scenario is, your server gets pwned

  425. lovetox

    they steal the emails and passwords

  426. lovetox

    and try other services

  427. lovetox

    not other xmpp accounts

  428. jonasā€™

    good thing XMPP services donā€™t store emails :)

  429. moparisthebest

    which bcrypt/scrypt/pbkf2 etc all have had solved for years

  430. lovetox

    as a server hoster i would see it as a positive if i know i dont store real passwords from users

  431. moparisthebest

    servers don't store plaintext passwords anyway

  432. moparisthebest

    I think it's worthless for the client not to store it basically :/

  433. Zash

    SCRAM uses PBKDF2 already

  434. Zash

    Along with one weird trick that means you don't have to do the expensive computation

  435. lovetox

    moparisthebest, what do you mean they dont store it in plaintext? how do they authenticate a PLAIN connection than?

  436. moparisthebest

    they store them hashed

  437. jonasā€™

    lovetox, ... by pbkdf2-ing things and comparing hashes?

  438. zinid

    SASL EXTERNAL!!!1111

  439. 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.

  440. lovetox

    jonasā€™, so why use SCRAM then?

  441. jonasā€™

    lovetox, less expensive when both sides support it

  442. jonasā€™

    Holger, except for the upgradability, *does* it have downsides?

  443. zinid

    jonasā€™, external services?

  444. 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

  445. 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.

  446. jonasā€™

    zinid, ah, yes, the pain with the external services. I know it myself.

  447. 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.

  448. 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?

  449. moparisthebest

    what's the benefit again?

  450. jonasā€™

    Holger, see what I wrote about the PLAIN issue.

  451. jonasā€™

    it is only more expensive if you consider storing plaintext passwords a real alternative

  452. Holger

    Yes, I wasn't making your assumption.

  453. Holger

    Of course it's an alternative.

  454. Zash

    moparisthebest: Ugh. I don't even.

  455. zinid

    is storing plaintext an alternative? I don't think that's what users expect you to do

  456. zinid

    but you can lie of course!

  457. lovetox

    So there is no perfect solution?

  458. lovetox

    DoS vector with plain, SCRAM does not work with external services and not upgradeable easily

  459. zinid

    SASL EXTERNAL, bitches!!111

  460. lovetox

    how does that work, you authenticate over another channel?

  461. Zash

    zinid: Also problematic

  462. moparisthebest

    if... all HTTP services ever can handle the "DoS vector of plain" then I'm pretty sure XMPP servers can

  463. Zash

    zinid: Or rather, which kind of SASL EXTERNAL?

  464. zinid

    Zash, X.509 certs

  465. zinid

    Zash, also, you can say about everything "also problematic"

  466. moparisthebest

    HTTP has far more auths in comparison, sometimes on every request

  467. zinid

    read this http://upload.zinid.ru/xep-eax-csr.html (it's not finished, I'm still working on it)

  468. 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.

  469. Zash

    zinid: Mostly I'm concerned about certificates being sent in the clear, tho maybe TLS 1.3 fixed that. Not sure.

  470. zinid

    Holger, yeah, but the ones who question are very loud

  471. Holger

    Indeed.

  472. 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.

  473. zinid

    Zash, it's fixed in TLS1.3, we checked that with Wiktor recently

  474. zinid

    Zash, both client and server certs are now encrypted

  475. Holger

    jonasā€™: Yes, and my point above was that this is more of a hype thing than a sensible practice.

  476. Zash

    zinid: Then yes, client certs are pretty nice

  477. zinid

    Zash, so read my scribble!!!111

  478. jonasā€™

    Holger, to be clear, you think that not storing plaintext passwords is more of a hype thing than a sensible practice?

  479. zinid

    feedback is welcome even at this stage of the scribble

  480. lovetox

    but how does the client obtain the client cert? what if he changes device?

  481. 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.

  482. jonasā€™

    sure itā€™s a trade-off

  483. zinid

    lovetox, sigh, look at my proposal please šŸ™

  484. jonasā€™

    (Iā€™m storing passwords with SSHA, which is pretty much plaintext for a determined attacker)

  485. zinid

    at least at intro

  486. lovetox

    yeah im reading now

  487. lovetox

    sorry :)

  488. Holger

    jonasā€™: So "plaintext is NO-GO" is not the obviously correct decision.

  489. 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"

  490. Holger

    All else being equal, sure. That's stating the obvious. The hype is about stopping at this point.

  491. jonasā€™

    I see

  492. 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) :)

  493. moparisthebest

    it's invisible to users anyway

  494. moparisthebest

    I don't know what conversations, gajim, dino do when I type my password in

  495. pep.

    It is indeed

  496. moparisthebest

    if anything, users expect the website they type their user+pass in to have their user+pass

  497. moparisthebest

    because that's how every website ever works

  498. pep.

    tbh, I don't think users expect :/

  499. pep.

    (at all)