XSF Discussion - 2018-10-14


  1. flow

    dedekin, that is not (yet) a statistic evaluation, just a single shot. I'm also not sure how meaningful the numbers regarding compression are, as I wonder if compression achieves very good results in the initial connection phase as the user's XMPP domain occurs very often

  2. jonas’

    flow, does this take into account the requirement to flush the compression state on each stanza?

  3. flow

    jonas’, not on each stanza but on each channel change, and the with compression above is using sync flush after each stanza

  4. flow

    with compression full flush and with tls recv: 9827 send: 6360 recv-aft-filter: 21594 send-bef-filter: 5677

  5. flow

    those are the numbers with full flush after a channel change

  6. jonas’

    sure, channel change is harder to implement, so I’d like to see the "worst case" numbers here :)

  7. jonas’

    but that is still pretty good

  8. Ge0rG

    Those are important inputs for the deprecation discussion in Council

  9. jonas’

    flow, which server implementation is this against?

  10. flow

    ejabberd 17.03

  11. jonas’

    aged, but neat

  12. flow

    jonas’, ^. But I'm curious, do you expect a behavior change depending on the server?

  13. flow

    zlib being zlib for ages

  14. jonas’

    flow, I was just curious, because prosody e.g. does not implement per-stanza/channel flush

  15. flow

    jonas’, well I doubt that ejabberd does this. so the full flush is probably only performed by smack

  16. jonas’

    oh

  17. jonas’

    that makes the recv number entirely irrelevant

  18. jonas’

    (which is what I was looking at)

  19. jonas’

    and the send number isn’t that impressive anymore

  20. flow

    that is why I champion that we make that feature negotiable in xep138

  21. jonas’

    which feature?

  22. flow

    full flush on stanza/channel change

  23. jonas’

    I am massively against making that negotiable

  24. jonas’

    it’s a requirement to implement compression securely

  25. flow

    well only if you use tls

  26. flow

    there are use case for xmpp w/o tls

  27. jonas’

    are there still?

  28. flow

    also it will likely be negoiatable in the end anyways

  29. flow

    because the current "zlib" mechanism does not specify this behavior

  30. jonas’

    indeed

  31. jonas’

    it might be indirectly negotiable by a namespace bump

  32. flow

    so you either add a flag to xep138 or the specific compression mechanism xep, or register a new mech like zlib-full-flush

  33. jonas’

    I think all mechanisms need that type of thing, so bumping the NS of xep138 entirely to require this seems more reasonable to me

  34. flow

    I wouldn't require it, just as there are use cases for xmpp w/o tls, there are use cases for compression using only sync flush

  35. Ge0rG

    I'm not sure there are still use cases without TLS in 2018

  36. rainslide

    http://neverssl.com

  37. pep.

    TIL https://xmpp.org/extensions/inbox/calendaring.html; Any idea what happened to it?

  38. pep.

    Apparently https://mail.jabber.org/pipermail/council/2009-April/002540.html says: Consensus to delay until after discussion with calendaring people - Dave to instigate.

  39. Zash

    https://mail.jabber.org/pipermail/council/2009-April/002546.html has some followup

  40. pep.

    It'd be great to have all this feedback somewhere easily discoverable

  41. Zash

    pep.: Shush, you'll wake up the people who want to switch to discourse.

  42. moparisthebest

    at this point, it's far too late for that, caldav won

  43. moparisthebest

    xmpp doesn't have to do *everything*

  44. pep.

    Zash, I'm not sure discourse is really better

  45. Zash

    moparisthebest: I think you'll find that Google Calendar won. Even I haven't ever used CalDAV.

  46. moparisthebest

    doesn't google calendar talk caldav?

  47. pep.

    I do use CalDAV fwiw

  48. Zash

    Not that I've been in large enough organizations to need a dedicated calendaring system on that scale

  49. moparisthebest

    I've used nextcloud on server and davdroid on phones since 2013 when I abandoned google

  50. Zash

    pep.: Seen IETFs thing? https://mailarchive.ietf.org/arch/search/?q=draft-ietf-kitten-pkinit-alg-agility

  51. pep.

    What are you trying to highlight? Is that related to Calendaring, or discourse, or?

  52. Zash

    pep.: Email archive/search thing

  53. pep.

    I see. Well it's not just about emails, we have lots of different channels

  54. pep.

    email, github, XEPs, XMPP, ???

  55. Zash

    github is not supposed to have discussion

  56. pep.

    Maybe not discussion, but changes

  57. pep.

    I think ideally I'd like to have that displayed somewhere alongside the XEP on xmpp.org

  58. Zash

    I was more thinking of the why/why-not of the changes

  59. Zash

    I have a vauge memory of someone working on something like that

  60. pep.

    https://xmpp.org/extensions/xep-0099.html anybody ever used this?

  61. pep.

    CRUD over Iqs

  62. pep.

    Or this, https://xmpp.org/extensions/xep-0101.html, I wonder how much overlaps with 0070

  63. pep.

    It seems to be the other way around? Instead of having the http server ping the xmpp server (that will ping your xmpp client), you go get a token from your xmpp client, that you then give to the website?

  64. flow

    > Ge0rG> Those are important inputs for the deprecation discussion in Council

  65. flow

    I doubt that those provide a solid foundation for such a discussion

  66. pep.

    SamWhited, there are 70 occurences of "meta-data" in the whole repo, I can sed them all :-°

  67. pep.

    it'/its was a bit more work

  68. SamWhited

    pep. even better! I just noticed those two and figured we might as well keep future diffs small since you were already editing those lines anyways, but might as well grab all of them I guess :)

  69. SamWhited

    Good job on the its/it's

  70. pep.

    I haven't touched inbox/ btw, not sure how that works in there, also not sure if XEPs I would have been edited are already accepted or not

  71. pep.

    err, I missed one

  72. jonas’

    muclumbus/jabber muc search now lives at https://search.jabber.network/ :-)

  73. pep.

    SamWhited, that sed was a bad idea..

  74. pep.

    "meta-data" is used in normative parts as well :(

  75. SamWhited

    ah, too bad. I wouldn't worry about it then; might as well just fix the two that were in lines you were touching anyways and then if we want to dig through later and find the rest we can