XSF Discussion - 2023-02-28


  1. Guus

    does anyone happen to know if phpBB's XMPP integration (notably, it's SASL DIGEST-MD5) is operational?

  2. Zash

    Let me tell you abouet RFC 6331

  3. Zash

    Let me tell you about RFC 6331

  4. Guus

    it's that, or PLAIN. You pick.

  5. Zash

    I pick PLAIN

  6. Guus

    at least there's no perceived sense of security?

  7. Zash

    indeed

  8. egnun

    Hello #XSF, the other day I found another interesting site, where XMPP projects could try to get funding from. It's called "SecureIT". https://securit-project.eu/

  9. ralphm

    I may do a longer summary later, but I wanted to note that I think that yesterday's DMA Interoperability Workshop was a success. From my conversations around the sessions, this was an exceptional meeting for the EC. I.e. there was a high turnout of people in the messaging arena, and unusually technical and productive discussions. For those who've listened to the summary at the end, it seems that the representatives of the EC picked up more than I had hoped. I think we have good shot at moving forward, if we put some energy into this, and I'm working on follow-up steps for the near future to do just that.

  10. MSavoritias (fae,ve)

    Amazing 🎉 thank you

  11. MattJ

    Thanks Ralph!

  12. wurstsalat

    Thanks a lot for attending and participating, ralphm! Let me know if you're interested in a short blog post - I would certainly help where I can

  13. Guus

    That's good news Ralph, thanks!

  14. nicoco

    ralphm: thanks for being there and for the update

  15. intosi

    EXcellent, thanks for the update.

  16. Alex

    awesome Ralph

  17. goffi

    thanks for participating ralphm, that's great news!

  18. gooya

    What was the deadline again for major IM companies to incorporate interoperability? I thought somewhere in november this year?

  19. MattJ

    gooya, "it's complicated"

  20. ralphm

    It is a certain time after the gatekeepers have been designated

  21. ralphm

    Which is still to happen

  22. MattJ

    There is no single deadline. The DMA comes into effect in May, then there will be a few months during which gatekeepers are identified and designated, and then they have 6 months to comply

  23. MattJ

    So there is no single deadline, and the exact date may differ for each gatekeeper, depending on when the process kicked off for them

  24. gooya

    So safe to say somewhere in the next year or year and a half, the basics should be interoperable (so normal messaging no encryption and no a/v calls)?

  25. MattJ

    Safe to say that in the next year, the gatekeepers will have collectively done the bare minimum they think they can get away with :)

  26. gooya

    I think it's gonna be really weird and funny to tell someone on whatsapp to add your JID and they will probably be confused as hell.

  27. MattJ

    Also, DMA explicitly requires common features and especially preservation of end-to-end encryption

  28. gooya

    > Also, DMA explicitly requires common features and especially preservation of end-to-end encryption But not at the start right? Thought I read somewhere that within x amoumt of months after DMA passed, gatekeepers will have to have basic messaging support with no e2ee. After that deadline they will have another x amount of months to implement e2ee and then another round for a/v.

  29. gooya

    Atleast that is what I remembered from reading all the articles a few months ago

  30. MattJ

    Yes, there is a gradual roll-out of required features. But E2EE is not one of them, it's expected from the start.

  31. gooya

    Oh just read the article by nicfab which explained most of my questions

  32. gooya

    MattJ: https://notes.nicfab.eu/en/posts/dmaworkshop/

  33. MattJ

    Yes, that's a good explanation :)

  34. gooya

    I think it is pretty cool to see xmpp getting some attenttion there especially since many services are based on it

  35. mjk

    > I think it's gonna be really weird and funny to tell someone on whatsapp to add your JID and they will probably be confused as hell. then you tell them to try anyway and then it doesn't actually work because they're outside EU

  36. nicola

    Thank you. I hope to be somehow helpful, especially to XMPP and XSF

  37. mjk

    good news anyhow and many belated thanks to ralphm for being there and asking the hard-for-lawyers questions

  38. ralphm

    mjk, you're welcome. To be honest I am curious about the EU/non-EU user thing. This requires an operator to be able to tell the difference. I do not think that e.g. a phone number is sufficient to make that determination. That's also why I asked that question, yesterday, and I'm not sure that the answer I got is correct. For perspective, if you are outside the EU, but are an EU "citizen", or if the service resides in the EU, GDPR applies.

  39. nicola

    @ralphm You didn’t have any answer yesterday on that point You touched on a crucial point regarding transfers of personal data to third countries or international organisations. You are right, the GDPR applies according to article 3.

  40. mjk

    in my (user) experience, companies are eager to default you as belonging to region X, wrt legal issues (with some way for you to change that default). like google did it to me a year or two ago based on some heuristics like my phone # country code or geoip or languages I use or my DNA...

  41. ralphm

    mjk: such eager companies will have a field day for their DPO

  42. ralphm

    nicola: right. However, my impression was that I got a "no", but indeed it wasn't very convincing

  43. ralphm

    nicola: and thank you for your post.

  44. pep.

    "preservation of end-to-end encryption". I understand this may be a thing legislation is aiming for, but concretely, that's not possible until everybody has the exact same serialization format right? Or that bridging happens on the user machine

  45. pep.

    "preservation of end-to-end encryption". I understand this may be a thing legislation is aiming for, but concretely, that's not possible until everybody has the exact same serialization format right? Or that gateway-ing happens on the user machine

  46. moparisthebest

    The ietf is trying to spec that out with M-something I think

  47. pep.

    MLS?

  48. pep.

    MIMI?

  49. ralphm

    There was some discussion on this, with Stephen Hurley of Meta clearly not wanting to move away from Signal, with MLS not being "proven", while also stating that two authors of MLS are Meta employees. Look, if you want to go the API route, then for Meta it doesn't really matter. You just have to support what they do. But, to be honest, I think the way forward here would be for all parties to support MLS.

  50. moparisthebest

    MLS ? MIMI ? Don't recall

  51. pep.

    ralphm, I have no clue about MLS, but doesn't that still require to have the same serialization format?

  52. ralphm

    MLS is Messaging Layer Security. https://datatracker.ietf.org/wg/mls/about/ MIMI is the More Instant Messaging Interoperability Working Group: https://datatracker.ietf.org/wg/mimi/about/

  53. MSavoritias (fae,ve)

    yeah

  54. ralphm

    pep.: you mean for the encrypted payload?

  55. MSavoritias (fae,ve)

    it could be that long term if matrix and xmpp get onboard with mimi and mls it could push meta to support it

  56. MSavoritias (fae,ve)

    especially since it will standardize encrypted calls and such

  57. MSavoritias (fae,ve)

    which is 4 years in the horizon as per the blog post

  58. MSavoritias (fae,ve)

    so we have time

  59. pep.

    ralphm, yeah. If I need to extract info from the payload to decrypt it then that means I need to be able to deserialize it

  60. moparisthebest

    Yea mimi was the payload thing, ralph was faster :)

  61. ralphm

    pep.: well, depending how the interop happens, if you assume a common protocol, then yes, at least the agreed-upon common bits need to have a singular format, while potentially having an operator specific blob next to it.

  62. moparisthebest

    MSavoritias (fae,ve): meta will support the bare minimum and try to keep users locked in, imho it's crazy to think they'll get on board with any actually open protocol

  63. pep.

    Right yeah this isn't doable without a common protocol for e2ee, otherwise a gateway needs to decrypt/deserialize to reserialize and reencrypt so that clients understand

  64. moparisthebest

    Recall they supported XMPP until they got so many users they shut it off to lock them in

  65. moparisthebest

    That's actually a common story across all the evil corps

  66. pep.

    s/evil // really. That's literally capitalism 101. Milk your cows as much as you can

  67. MattJ

    moparisthebest, while it's crazy to think they'll voluntarily get on board with an open protocol, I don't think it's ultimately out of the question if enough holes get poked in their walled gardens

  68. MSavoritias (fae,ve)

    true. and if a sufficient amount of shareholders agree

  69. MSavoritias (fae,ve)

    from the other parties

  70. MattJ

    If they can no longer rely on the walls keeping people in/out, they've lost the competitive advantage. Especially if any of the other gatekeepers make moves to open up, it actually becomes the opposite.

  71. ralphm

    moparisthebest: first of all, the bare minimum is probably not too small. Basically what people expect now, so that's the entire WhatsApp feature set w.r.t. chatting. Second, this is a living thing in that the protocol needs to be able to account for extensibility as future requirements will be broader, as new features become commonly expected.

  72. Zash

    Imagine an email service where you can't send messages to other email services :)

  73. MattJ

    There's still a good dose of optimism needed to see this outcome, but it's suddenly much less impossible than it seemed 5 years ago

  74. ralphm

    Zash: I am old enough to remember

  75. MSavoritias (fae,ve)

    maybe with mastodon federation has got a bit more mainstream

  76. MSavoritias (fae,ve)

    who knowss

  77. pep.

    Zash, my provider (me) must not be competitive enough then, It's having difficulties sending to gmail.com!

  78. moparisthebest

    So they'll throw up some hard to use and ever changing APIs and say "we don't know why no one is willing to integrate with us, we did our part"

  79. ralphm

    pep.: but at least you don't have to use UUCP, right?

  80. moparisthebest

    It's not like we haven't seen this before, remember Microsofts open docx standard?

  81. pep.

    ralphm, no I literaly have to use another channel to tell every new gmail.com user I send to to un-spam me, so that I can end up in their inbox

  82. ralphm

    moparisthebest: that was actually referenced. I think the difference is that there are more gatekeepers involved, and many more so-called access seekers.

  83. pep.

    So yeah, federation is great

  84. ralphm

    (going to go drumming now, but will catch up)

  85. mjk

    pep.: > no I literaly have to use another channel to tell every new gmail.com user I send to to un-spam me, so that I can end up in their inbox google seems to simply have a "cooldown" on their ability to shoot down any and all incoming mail from an address. once the recipient sent something back, the mail goes both directions just fine, for some time. then the timer resets...

  86. mjk

    I had to re-repair communication at least once, maybe twice

  87. pep.

    mjk, yeah but they first need to see your mail

  88. pep.

    To reply to it

  89. mjk

    exactly

  90. Zash

    I hear the secret trick is to have a gmail account and email yourself

  91. pep.

    "We're feerated but you still need to create an account on our servers and tell us which accounts you own"

  92. pep.

    "We're federated but you still need to create an account on our servers and tell us which accounts you own"

  93. mjk

    ...and the more, the merrier

  94. nicola

    > nicola: right. However, my impression was that I got a "no", but indeed it wasn't very convincing @ralphm I agree with you