XSF Discussion - 2019-08-07

  1. Ge0rG

    This sounds like it will also affect xmpp clients on ios https://www.theinformation.com/articles/facebook-hit-by-apples-crackdown-on-messaging-feature

  2. pep.

    Do you have a version of the full article

  3. Ge0rG

    pep.: isn't that the full article?

  4. Kev

    There's a registration wall.

  5. Ge0rG

    oh, sorry. didn't realize it's paywalled if not opened from https://news.ycombinator.com/item?id=20629567

  6. Holger

    > Right now, the calling feature in these apps runs in the background even when it’s not in use I wasn't aware this was still the case.

  7. Ge0rG

    Holger: at least you can send silent pushes this way.

  8. Holger

    Yes. I thought that was the only remaining VoIP privilege.

  9. ralphm

    Isn't the gist here that if you use another protocol for non-calling features, you're fine? Like, say, XMPP. It reads to me as if they want to limit piggybacking stuff on WebRTC data channels, or something.

  10. Ge0rG

    ralphm: I've interpreted it as further limiting background activity, maybe also silent notifications

  11. ralphm

    Well, indeed if they are no longer allowing async pushes waking up an app without bothering the user, that's bad.

  12. ralphm

    I'm very curious how you'd implement muting conversations in such a scenario.

  13. jonas’


  14. ralphm

    I guess.

  15. ralphm

    But how does that *improve* privacy?

  16. jonas’

    is that the goal?

  17. ralphm

    Well, that's the story

  18. jonas’

    I didn’t read the article and just suspected they want to make life for app developers harder and reduce battery drain

  19. ralphm


  20. Kev

    The suspicion is that Facebook is using running-in-background to gather data.

  21. Kev

    Which sounds very unlike Facebook, to me 😈

  22. ralphm

    The video from WWDC seems to nicely sum up the various use cases and how do achieve this in the future. For 'us' it probably means that we should differentiate between different kinds of pushes (e.g. message v.s. call) in XEP-0357 and/or server-triggered pushes.

  23. ralphm

    It might be that servers need to know more about e.g. when a call is made to resources known to be dormant. There are more reasons to revisit Jingle calling in the face of multiple resources, some of which might be offline, which are badly covered by the way a jingle call is initiated with iq stanzas, and this is one of them.

  24. jonas’

    didn’t we have a XEP which does that with messages instead of IQ?

  25. ralphm

    That's not optimal in my opinion.

  26. jonas’

    what would be optimal?

  27. ralphm

    Placing calls to bare JIDs and have servers take care of it.

  28. jonas’

    but E2EE!!!

  29. jonas’

    ralphm, what would the server do that clients can’t do with carbon-copy, MAM and messages?

  30. ralphm

    E.g. know that this is about a call and not something else, and wake up clients properly.

  31. ralphm

    Also I don't see how this is a problem for e2ee.

  32. Zash

    Caps/disco#info based magic? Or some opt-in subscription thing?

  33. jonas’

    I don’t either, but the E2EE mafia will jump on this with "but the metadata!"

  34. ralphm

    Well, if you don't want servers to know that calls are being signalled, then, well, I guess you can't use XMPP directly. You might negotiate a p2p XMPP stream but then you have metadata about that.

  35. ralphm

    Zash: huh?

  36. Zash

    > E.g. know that this is about a call and not something else, and wake up clients properly. Only wake up voip-capable clients for voip requests eg?

  37. Kev

    I think we need explicit client existance, rather than magic, for these.

  38. Kev

    I think we need explicit client existence, rather than magic, for these.

  39. Zash

    Persistent serverside device tracking?

  40. Kev


  41. Kev

    And management thereof.

  42. ralphm


  43. ralphm

    And as you have to register clients for push notifications, you might want to define it there.

  44. Kev

    I think you might care about this for more than push, so extracting it out probably makes sense.

  45. ralphm


  46. ralphm

    The push registration might become a side-effect.

  47. Kev

    I think the push registration then probably becomes an action on a registered device.

  48. Kev

    s/on/against/ whatever.

  49. jonas’

    and then we can finally have per-device credentials

  50. ralphm

    I am more and more convinced we need servers to have more smarts on behalf of the clients. This goes from call setup to pubsub subscriptions (including MIX).

  51. jonas’

    hasn’t that been the idea of XMPP from the beginning?

  52. ralphm

    Well, as in all technology, there always the pendulum swinging between thin and fat clients.

  53. Zash

    Thin client and E2EE is kinda tricky tho

  54. ralphm

    (see also X11 v.s. wayland)

  55. Zash

    Or earlier X11 vs later X11

  56. ralphm

    Zash: yes, but at least with registered devices, you could potentially know about a fix set of keys to encrypt against.

  57. ralphm


  58. ralphm

    I'm myself rather skeptic about the viability of e2ee in a dynamic multi-device setup, including server-side archiving, and potentially web based clients.

  59. Zash

    Me too.

  60. jonas’

    *ubiquitous e2ee

  61. jonas’

    OTR works just fine here ;)

  62. Zash

    Mandatory E2EE everywhere always as some people seem to demand, doesn't seem to be compatible with how I see XMPP

  63. ralphm

    I personally explicitly disable e2ee in my clients, and keep being reminded of it when I get another of those messages saying that a particular clients could show the real message.

  64. ralphm

    client could not

  65. Zash

    I went as far as to make my server reject publishing of OMEMO keys so that me testing various clients wouldn't trick my contacts into encrypting everything, thus rendering everything unreadable.

  66. ralphm


  67. Kev

    Zash: Doesn't seem compatible with how I see *messaging*, not just XMPP.

  68. ralphm

    Well, yeah.

  69. jubalh

    If I create a PR for a XEP to fix a typo should I add a new revision field?

  70. jubalh

    also I wonder why we only put initials there and not a name :)

  71. jonas’

    Seve, don’t forget to re-apply :)

  72. Seve

    Yes, yes! Alex also told me :D Thank you :)

  73. Alex


  74. lovetox

    So, on the topic of moving jdev, another week or more has gone by, no reply from stpeter

  75. lovetox

    i dont think there will be something happening on jabber.org anytime soon

  76. lovetox

    could we move the chat to muc.xmpp.org?

  77. MattJ

    I don't think I'd be opposed to this

  78. MattJ

    "Move" would entail a few things: "forcing" the current jdev members to relocate, updating the website, and everywhere that mentions jdev

  79. MattJ

    It's not a simple thing to do, unless we actually destroyed the current MUC (which I don't think would be sensible), it's not going to disappear overnight

  80. Zash

    Destroying and leaving a tombstone with a redirection is kinda neat 🙂

  81. lovetox

    i dont think the software that currently runs on jabber.org would allow setting a tombestone

  82. lovetox

    but who knows, no not detroying just setting the subject, to -> We moved to jdev@muc.xmpp.org

  83. Ge0rG

    Yes, change the subject, change all references and let time sort things out.