XSF Discussion - 2021-02-23

  1. emus

    ==== Reminder to add your news 📝 If you have somethibg to say for February Newsletter now is the perfect time! Newsletter draft on Github: https://github.com/xsf/xmpp.org/milestone/3 Or drop your news text to our online pad: https://yopad.eu/p/xmpp-newsletter-365days We are always happy for supporters at the end of the month to finalize the draft! 🎛 ============

  2. emus

    ==== Reminder to add your news 📝 If you have something to say for February Newsletter now is the perfect time! Newsletter draft on Github: https://github.com/xsf/xmpp.org/milestone/3 Or drop your news text to our online pad: https://yopad.eu/p/xmpp-newsletter-365days We are always happy for supporters at the end of the month to finalize the draft! 🎛 ============

  3. moparisthebest

    this is finally available, update on SRV2 and encrypted client hello (replaces encrypted SNI and ALPN) https://www.ripe.net/participate/ripe/wg/active-wg/dns/remote-sessions/svcb_https_-ripe-2020.pdf

  4. Zash

    > The page you requested is undergoing maintenance and is temporarily unavailable.

  5. Zash


  6. Zash

    Can't serve a PDF without Javascript???

  7. moparisthebest

    works for me in firefox and wget

  8. Zash

    It worked after enabling JS

  9. moparisthebest

    I think firefox's built-in pdf viewer needs JS

  10. Zash

    I doubt that

  11. Zash

    I mean, it's written in JS, but I don't think that would have caused RIPE to send me an error page

  12. moparisthebest

    yea that doesn't make sense I agree

  13. L29Ah


  14. L29Ah

    i guess Zash enabling JS in his browser coincided with ripe fixing their crap

  15. Zash

    Still screams "the web stubbornly refused to go with SRV records and now NIHed an overcomplicated hack for it" to me

  16. moparisthebest

    SRV records don't support "use key X for host Y but key B for host A"

  17. Zash

    But you can publish full keys with DANE

  18. moparisthebest

    well it's not *only* keys either

  19. Zash

    Hence "overcomplicated"

  20. moparisthebest

    it can also say "use http2 with host Y but http1.1 with host X"

  21. L29Ah

    moparisthebest: don't they? _foo.bar.baz and _foo.rab.baz are different contents for different hosts

  22. moparisthebest

    which will actually be very helpful for XMPP too

  23. moparisthebest

    L29Ah, right, but for 1 domain, not 2

  24. L29Ah

    1 domain = 1 host

  25. Zash

    As a cynic, I have to say that I doubt it will be of any use for anyhing but https.

  26. Zash

    Since HTTPS gets a special record of its own, I'm counting on that being the only thing supported

  27. moparisthebest

    L29Ah, no, google.com is not hosted on 1 server/host

  28. SamWhited

    I don't think 1 domain = 1 host has been true for any multi-host service that I've ever run or helped work on :)

  29. L29Ah


  30. L29Ah

    and sharing a key is not an option; what about sharing a CA though?

  31. L29Ah

    though X.509 stuff is an abomination anyway

  32. moparisthebest

    the key used to encrypt the client hello isn't shared across hosts, necessarily anyway

  33. SamWhited

    oh hey, one of my coworkers is an author on this; I should ask him to give me the rundown

  34. L29Ah leaves mumbing about roots of trust

  35. SamWhited

    *former coworkers

  36. moparisthebest

    but roughly, XMPP-wise, we can replace RFC SRV, xep-368 SRV, and xep-0156 TXT, with a much better single-SRV2 lookup

  37. moparisthebest

    then get encrypted client hello for free, and future QUIC support is easily implemented the same way

  38. moparisthebest

    the main thing I'm not understanding is everything seems to say SVCB and HTTPS record types are identical, except for the record type code

  39. Zash


  40. moparisthebest

    anyway it might make sense for XMPP to use the HTTPS record specifically for the reasons Zash mentioned above :D

  41. Zash

    so shose shitty consumer router vendors will do what, you think?

  42. Zash

    you know, those that don't support SRV records. at all.

  43. moparisthebest

    right but that'll be fixed quickly when people have a degraded facebook/gmail experience

  44. Zash

    tho it would be good to do deeper investigation into those ~10% of users behaving as if no SRV exists

  45. mathieui

    There is nothing preventing available presences to come from bare JIDs, right?

  46. mathieui

    (looking at https://dev.gajim.org/gajim/gajim/-/issues/10461)

  47. mathieui

    The RFC does not disallow it (and it makes sense for components), but it explicitly allows unavailable presence

  48. Daniel

    i think we've discussed this recently and the vibe in the room was that this is not ok

  49. Daniel

    i have seen gateways do this though and Conversations has support for this

  50. Daniel

    but i'm really unsure that this is correct behaviour

  51. Daniel

    unavailable from bare means all resources though

  52. mathieui


  53. Daniel

    so the fact that this is allowed doesn’t mean available should be allowed

  54. Daniel

    on the contrary this might be an argument to not allow it

  55. mathieui

    XEP-0100 makes use of this though

  56. mathieui

    https://xmpp.org/extensions/xep-0100.html#usecases-jabber-addcontact-pri at step 4

  57. lovetox

    so gateway users have no resource Oo

  58. mathieui

    lovetox, well, lots of networks have no concept of "resource"

  59. lovetox

    yeah and others have

  60. mathieui

    in which case the gateways can reflect that

  61. Daniel

    well the fact that some gateways might decide to omit the resource doesn’t mean all gateways have to

  62. Daniel

    but of course they could also decide to go for a static resource

  63. mathieui

    Of course, if that is relevant to the gateway, I don’t think anything forbids sending gatewayed presence from full-jids

  64. eta

    hey, I write a gateway

  65. eta checks what they do here

  66. lovetox

    i really dont like that

  67. lovetox

    this is again something i need to special case

  68. eta

    answer: using no resource

  69. eta

    I didn't know that was bad

  70. Daniel

    well we don’t know if that's bad :-)

  71. Daniel

    it's certainly unusual

  72. lovetox

    i find this is the job of the bridge, like i dont care some other chat network has no concept of resource

  73. eta

    I send presence subscription requests from the barejid too fwiw

  74. Daniel

    and creates weird corner cases like: can you have a resource from bare and one from a full

  75. Daniel

    aehm presence i mean

  76. eta uses bare JIDs as much as possible

  77. mathieui

    eta, that does not matter as much, afaik

  78. eta

    although I think messages do come from a resource

  79. mathieui

    because subscription requests are expected to be resource-less

  80. mathieui

    but available presences are used to display things in UI, generally

  81. Daniel

    foo@bar.tld type=available, foo@bar.tld/something type=available foo@bar.tld type=unavailable is foo@bar.tld online or offline now?

  82. mathieui

    Daniel, offline, per 6121 :p

  83. mathieui

    though an entity sending both resourced and bare presences would have a weird thing going on