XSF Discussion - 2018-01-17

  1. moparisthebest

    Zash, jonasw: you thought xmpp over TLS on https port was bad https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-02

  2. moparisthebest

    How about take udp DNS request, bas64 it and send it over https, then get answer back the same way :)

  3. Zash

    moparisthebest: Was that the one with or without JSON?

  4. moparisthebest

    Zash: without at least, so that's better

  5. zinid

    DNS over HTTP, finally

  6. zinid

    So we finally have everything over http on a single port and single tasking OS (in the phone)

  7. zinid

    IT is progressing

  8. pep.

    > SamWhited> pluging in a 4k monitor everything on it is tiny, if I make it bigger when I unplug it the bar eats half my screen That's an X issue I believe

  9. Ge0rG

    zinid: but now we have ALPN to multiplex

  10. Dave Cridland

    Ge0rG, Ports in userspace.

  11. jonasw


  12. jonasw

    it’s only a matter of time until ALPN is handled by thekernel

  13. daniel

    now i'm wondering if iptables can filter based on alpn

  14. Ge0rG

    Dave Cridland: I might not make it in time for the Council meeting today. I need to relocate 500km between now and 5PM, and my arrival depends on traffic conditions.

  15. Ge0rG


  16. Ge0rG

    But I'll try hard because I want some qualified feedback on user-invite-protoXEP (for which I'm obviously +1)

  17. Ge0rG

    daniel: you might be able to construct something with BPF and marks.

  18. Ge0rG

    but kernels are getting less important every day, with the dockerization of our IT infrastructure

  19. Ge0rG

    you don't need a kernel in SaaS :P

  20. jonasw

    I’d be happy if ip6tables were able to filter on ipv6 neighbour discovery

  21. jonasw

    I’d be happy if ip6tables were able to filter on ipv6 neighbour discovery fields, like it can for arp

  22. Kev

    Yay. Thon rejected my booking because the deadline of the 12th had passed. *facepalm*

  23. SouL

    Oh, really? :(

  24. Kev


  25. Kev

    They've got about a 24hour roundtrip time on emails, so this can only go well for me.

  26. Kev

    And two of my team's went through fine, when we sent the forms at the same time. Oh, Thon, we love you.

  27. intosi

    This is the point where I would give them a ring, really.

  28. pep.

    All we need is IP over http right.

  29. pep.

    Apparently there is such a thing already. "Microsoft used to discourage IP-HTTPS use because it was slow." duh

  30. edhelas

    can't wait for XMPP over HTTP

  31. edhelas


  32. zinid

    There is tcp over http, called http2

  33. Kev

    Having now got Thon to honour the block booking rate, they still seem to be silently ripping me off by charging (much) more than the block booking rate anyway.

  34. Kev sighs

  35. intosi


  36. Guus

    Kev: I have written confirmation that Thon extended our block booking rate deadline to the 17th (today)

  37. Guus

    This was offered to us by David Hutsebaut on January 8th, by mail, to me.

  38. Guus

    I'm also interested in how much they're now charging you.

  39. Kev

    Actually, looking at the number they're charging me less for the second night, just much more for the third night, so in the end it only ends up being £20 or so difference. I can live with that.

  40. Ge0rG

    If only somebody would disrupt the hotel business.

  41. moparisthebest

    what do you want an 'Uber Hotels'

  42. Ge0rG

    moparisthebest: I thought about a web portal where private people offer rooms or flats to random strangers from the Internet, filming them naked.

  43. moparisthebest

    isn't there already something that does that, uh, airbnb or something?

  44. Ge0rG

    moparisthebest: no way!

  45. jonasw

    no, airbnb just gets you spider-infested flats which are half as large as claimed in the ad

  46. Ge0rG

    jonasw: maybe the difference between sqft and m²?

  47. jonasw


  48. jonasw

    just fraud

  49. jonasw

    that was pretty clear from the way the photos were and the general state of the flat

  50. Ge0rG

    But you can rate down the flat!1!

  51. jonasw

    we complained

  52. Ge0rG

    daniel: as the operator of a public server, I don't want a module to expose user avatars to the general public by loading a "compatibility" module.

  53. daniel

    > I'm not sure we should be messing with vcard anymore, but we can probably discuss afterwards unless this is critical to someones vote and it can't be done on list? I think there is an argument to be made that vCard will be needed for as long as muc is around

  54. Ge0rG

    s/a module//

  55. Ge0rG

    Maybe there are people still using vcard as designed.

  56. jonasw

    Ge0rG, aren’t user avatars factually already open to the general public when they’re stored as vcard?

  57. Ge0rG

    jonasw: yes.

  58. daniel

    I'm not really happy about that either but I can't remove MUC from existence

  59. jonasw

    could you run a query which tells you how many users have their avatar *only* in PEP?

  60. Ge0rG

    jonasw: except that most clients will warn you about your vcard being public

  61. jonasw

    (and how many have their avatar in PEP and vcard?)

  62. daniel

    > jonasw: except that most clients will warn you about your vcard being public What clients do?

  63. jonasw

    I’d like to have numbers on clients which do *not* warn you and only support PEP.

  64. jonasw

    daniel, conversations? ;-)

  65. daniel

    jonasw: no

  66. Dave Cridland

    There is the argument that maybe, while vCard is pretty rubbish, it's also good enough.

  67. jonasw

    Ge0rG, because I think that clients are simply neglient about warning users about their o+r avatars.

  68. Ge0rG

    jonasw: that might be true, but doesn't invalidate my argument.

  69. SamWhited is temporarily not here, will rejoin discussion shortly hopefully.

  70. jonasw

    daniel, I remotely recall that the avatar is visible to everyone, but maybe it was just "to your contacts" :)

  71. jonasw

    Even though, for the record, I *was* surprised to see that my avatar passes through anon MUCs.

  72. Ge0rG

    I see merit in having a public vcard by opt-in.

  73. daniel

    jonasw, Conversations had a message saying that pep avatars are only available to contacts. but i don't know a single client that warns you before publishing a vcard avatar

  74. pep.

    Ge0rG, agreed. I recently cleared my own vcard for that. Avatar is fine-ish

  75. jonasw

    daniel, ok, it’s been a while since I set conversations up

  76. daniel

    so as far as I see it the argument is either users expect avatars to be public in that case pep-vcard-conversion is not a problem. OR users expect avatars to be private in which case we need to fix vcard

  77. jonasw

    so, what do we need vcard avatars for exactly?

  78. jonasw

    is it only anon MUCs?

  79. daniel

    jonasw, pretty much

  80. jonasw

    if so, couldn’t we make MUC implementations handle that case like they handle vcards?

  81. Ge0rG

    pep.: depends on how you use your avatar. If you just put in some random picture from google images, everything is alright. if you have your photo there... not quite

  82. daniel

    + a little but backwards compat

  83. daniel

    but mostly muc

  84. pep.

    Ge0rG, sure

  85. pep.

    I was talking about mine

  86. jonasw

    like, a generic PEP-through-MUC XEP which specifies how that works (welp, obviously updates won’t get pushed necessarily etc., but how queries are passed through), with a whitelisting approach and suggesting a list of things to allow based on MUC configuration and affiliations of the involved entities

  87. jonasw

    because going forward we might want to abandon vcard entirely (or finally replace it by vcard4 proper)

  88. Ge0rG

    pep.: I don't see your avatar.

  89. pep.


  90. daniel

    fwiw i'm fine with resubmitting the XEP as informal like 'look this is what ejabberd and prosody can do. take it or leave it'

  91. Ge0rG

    pep.: I'm on a console client.

  92. jonasw

    I’m fine with the XEP as-is. It has clear security considerations, it can be built upon and whether public operators do this or not is their matter.

  93. daniel

    but i'd prefer to 'fix' this by putting the kind of access control Ge0rG described in front of vcard

  94. pep.

    Ge0rG, I'm on the same console client with borked avatar support :P

  95. jonasw

    daniel, that’d be better but I don’t see that as an requirement

  96. daniel

    jonasw, not for that XEP, no

  97. jonasw


  98. SamWhited

    My view is that we should be moving towards a world in which vcard doesn't exist, so we shouldn't modify the historical spec. It's worked "well enough" for years, so why add more stuff that things will have to implement? If the privacy thing is a concern for some clients (with the note that it's never been a concern for any client I've seen, so I don't know why that could change now), people could always do Daniel's hack if they have the pep node set to public and not do it (thereby losing avatars in MUCs) if it's set to private. If you want your avatar to be private, you probably don't want it showing up in MUCs anyways, no?

  99. jonasw

    SamWhited, I think that the privacy expectations for avatars and the actual privacy delivered by the XMPP network diverge.

  100. SouL

    The problem I would say is having to choose one avatar (or let's say identity) for everything.

  101. daniel

    oO(it's really annoying to read long texts in Gajim when you have been mentioned. because gajim makes that into bold text with a low contrast)

  102. jonasw

    and that clients do not care about this is not a sign that everything is alright

  103. Ge0rG

    jonasw: historically, XMPP clients don't care about privacy.

  104. jonasw


  105. Ge0rG

    SamWhited: we should be talking about _users'_ privacy expectations, not clients'.

  106. jonasw

    I mean, it’s fine-ish if you don’t care about MAM things, because you’re supposed to trust your server anyways.

  107. jonasw

    (or at least, one can argue that it’s "fine-ish")

  108. Ge0rG

    jonasw: MAM is another messy issue in my eyes.

  109. jonasw

    but it’s less fine if data gets available to everyone.

  110. SamWhited

    Ignore that part, it's irrelavant, as usual I shoudln't have mentioned anything extra.

  111. SamWhited

    The point is "if you want private avatars, they probably shouldn't show up in MUCs, so don't do the vcard thing and now you don't have to make changes to vcards"

  112. Ge0rG

    jonasw: https://prosody.im/issues/867

  113. Ge0rG

    SamWhited: the vcard thing is a server-wide module.

  114. jonasw

    Ge0rG, unless coupled with PEP permissions, which is what SamWhited was saying I think.

  115. Ge0rG

    SamWhited: so the server admin decides for all users if public avatars are fine

  116. SamWhited

    Ge0rG: that's an implementation detail; we can tell servers "do serve vcards in MUCs or don't"

  117. jonasw

    (then the client gets to decide)

  118. SamWhited

    but yes, whether or not they implement the XEP we write is a server admin decision, but there's not much we can do about that. Server operators can share avatars online publically over HTTP for all we know, all we can do is provide guidance.

  119. Ge0rG

    SamWhited: the world is full of implementation details. The XEP does not contain this detail, so it's changing the status quo

  120. SamWhited

    I didn't understand that?

  121. Ge0rG

    SamWhited: if we tell server admins "this will make avatars of your users work in MUC" but don't tell them "this will make all user avatars public" we've failed our job

  122. SamWhited

    It won't make user avatars public if it says "don't do this if user avatars are private"

  123. Ge0rG

    it's an interesting related question whether we should apply the same ACL to anonymous MUCs we are in as to our contacts.

  124. admin

    Hi everyone! Can someone please type 123 to comfirm everything is connecting properly and this server works?

  125. Ge0rG


  126. SouL


  127. Ge0rG

    a.k.a. "test failed".