XSF Discussion - 2023-02-27


  1. nicola

    Ready to participate today remotely in the "DMA stakeholder workshop on "Interoperability between messaging services" organized by the European Commission. We hope it will be a profitable opportunity.

  2. ralphm waves from the floor of the EC DMA Interoperability Workshop in Brussels.

  3. MattJ

    👋

  4. neox

    Hope something good comes out from this ! 😊

  5. larma

    ralphm, thanks for making sure XMPP is dropped as early as possible 🙂

  6. larma

    ralphm, thanks for making sure the name XMPP is dropped as early as possible 🙂

  7. nicola

    Great intervention @ralphm !

  8. larma

    the proposal to connect identities on multiple services totally confused me as well

  9. MattJ

    Yeah, I've seen this come up a few times (including within MIMI). In the XMPP community we obviously think about interop as federation, but not everyone has that perspective on things.

  10. ralphm

    💪️

  11. Tim R

    i

  12. Tim R

    [wrong room, apologies]

  13. Seve

    > ralphm, thanks for making sure the name XMPP is dropped as early as possible 🙂 What did I miss?

  14. MattJ

    Seve, https://competition-policy.ec.europa.eu/dma/dma-workshops/interoperability-workshop_en is today

  15. MattJ

    Another example of our biased perspectives: we think it's all about the protocol, but gatekeepers providing interoperability by distributing proprietary SDKs is one scary version of the future (a point raised by Alissa Cooper)

  16. pep.

    Who's "we"? :P

  17. MattJ

    This community (but not only)

  18. ralphm

    I'm not sure anyone is buying the statement by Stephen, of Meta, that no gatekeepers have been identified, yet.

  19. MattJ

    Well that's *technically* true

  20. MattJ

    There companies that are eligible to be designated gatekeepers, but that is not automatic - it is to be done explicitly on a case-by-case basis and it hasn't happened yet

  21. MattJ

    There are companies that are eligible to be designated gatekeepers, but that is not automatic - it is to be done explicitly on a case-by-case basis and it hasn't happened yet

  22. nicola

    > This community (but not only) Probably, he forgot this press release: https://www.europarl.europa.eu/news/en/press-room/20220315IPR25504/deal-on-digital-markets-act-ensuring-fair-competition-and-more-choice-for-users > *During a close to 8-hour long trilogue (three-way talks between Parliament, Council and Commission), EU lawmakers agreed that the largest messaging services (such as Whatsapp, Facebook Messenger or iMessage) will have to open up and interoperate with smaller messaging platforms, if they so request.*

  23. nicola

    > There are companies that are eligible to be designated gatekeepers, but that is not automatic - it is to be done explicitly on a case-by-case basis and it hasn't happened yet Indeed, but everybody knows who they are.

  24. MattJ

    Right, but no requests have been sent yet. Which is why the statement is (only) technically true :)

  25. singpolyma

    MattJ: in the "proprietary sdk" world one could still stuff that into a nonfree slidge plugin or similar I imagine. And it would give more cover for reversing efforts

  26. MattJ

    Interesting that they basically just rejected MLS

  27. nicola

    > Right, but no requests have been sent yet. Which is why the statement is (only) technically true 😊 Yes, correct (formally) 😊 The DMA was created for them 😊

  28. MattJ

    and MIMI rejected

  29. MattJ

    No surprises here :)

  30. Zash

    > they who? EU? GAFAM?

  31. Guus

    'they' being the not-official gatekeepers or EU?

  32. MattJ

    Zash, currently a guy from Meta/WhatsApp is giving a (clearly pre-written and carefully worded) statement, word for word

  33. MattJ

    They want E2EE interop to be based on the Signal protocol

  34. Zash

    So what they already have?

  35. MattJ

    Yes :)

  36. nicola

    Guys, the DMA provide the definition of gatekeeper about their turnover. It’s simple to identify them, and there isn’t a need to formally identify them

  37. nicola

    Guys, the DMA provides the definition of gatekeeper about their turnover. Identifying them is simple, and there isn’t a need to formally identify them.

  38. jonas’

    is this where misanthropy intensifies?

  39. Ellenor Malik

    This... might be the end of jabber. Lol.

  40. MattJ

    nicola, it's easy to identify which organizations meet the criteria, yes

  41. MattJ

    But the DMA does require the EU to explicitly notify gatekeepers, they do not automatically have any obligations unless notified

  42. pep.

    jonas’, only hatred of capitalism

  43. MSavoritias (fae,ve)

    > and MIMI rejected So that means that MIMI goes back to drawing board right? In the sense that MLS was an assumed part of it as i remember.

  44. singpolyma

    Well, we always knew meta wasn't going to use it unless forced

  45. MSavoritias (fae,ve)

    True

  46. singpolyma

    And I feel any kind of forcing is very unlikely

  47. MSavoritias (fae,ve)

    Just curious how they spinned it

  48. singpolyma

    Probably they'll do the least they can to avoid the bulk of fines

  49. MSavoritias (fae,ve)

    I think ietf is hopelessly optimistic when capisalist companies are involved

  50. MSavoritias (fae,ve)

    I mean past efforts to standardize messaging didnt work

  51. MattJ

    MSavoritias (fae,ve), the spin was simply that MIMI's planned timeline is too ambitious

  52. MattJ

    They need to (legally) provide a solution sooner than MIMI can be standardized and tested

  53. MSavoritias (fae,ve)

    Makes sense

  54. MattJ

    Which, being pragmatic, may well be true - however if they actually involved themselves and their resources in its development, I'm sure things could move a lot faster if needed

  55. MSavoritias (fae,ve)

    Agreed

  56. ralphm

    To be honest, I think the timeline is ambitious for everyone

  57. MattJ

    But that would involve some compromise and unnecessary exposure from them, they'd rather just stick with what they already have if they can get away with it

  58. MSavoritias (fae,ve)

    Yeah. I would love for EU to give more time to be honest

  59. MSavoritias (fae,ve)

    But even then i dont think that facebook is gonna use MIMI

  60. singpolyma

    I mean, the clock hasn't started yet due to no gatekeepers having been identified ;)

  61. MattJ

    Yeah, but that will happen soon, and then I think they have... 6 months (?), which is an incredibly short amount of time, no matter how many resources you have

  62. MattJ

    I think they could do it if they wanted, even if MIMI/MLS are not "finished", they have the opportunity to make it what they want right now, but they're apparently choosing not to

  63. MattJ

    Without their involvement, I feel MIMI will struggle to see serious adoption

  64. singpolyma

    If they think shipping an sdk will fit the law that's probably the target

  65. MattJ

    Yes, it sounds increasingly likely

  66. MattJ

    which will make "client-side bridging" that Matthew has been presenting seem all the more likely

  67. jonas’

    do I want to know what that is?

  68. jonas’

    is that a fancy term for "multi protocol client"?

  69. singpolyma

    Yes

  70. jonas’ backs away slowly

  71. singpolyma

    But I expect we could shove such tech into a gateway also, as we have done with eg libpurple in the past

  72. MattJ

    jonas’, kinda, but more like actually running a bridge on your device

  73. Daniel

    Isn't client side bridging just called swimming?

  74. singpolyma

    And use it as cover for reversing

  75. MattJ

    The difference being, primarily, they the messages will still end up going via your server before coming back to your "native" client

  76. MattJ

    The only change is that it runs on your device instead of on some server, and the only reason is because it breaks E2EE and you want that to happen within the user's domain

  77. jonas’

    right

  78. MattJ

    i.e. their device, which is already considered the encryption endpoint

  79. Kev

    That sounds ... easy? ... to cope with with multiple clients.

  80. jonas’

    so someone would have to shove such an SDK into an XMPP component, write down an abhorrent privacy policy w.r.t. E2EE, define some protocol to somehow advertise the E2EE keys in both directions and we're done?

  81. MSavoritias (fae,ve)

    Sounds like an afternoon /s

  82. MattJ

    Meta/WhatsApp wants contact with out-of-WhatsApp users to be an opt-in feature

  83. MattJ

    So that users have informed choice about "the risks involved"

  84. Kev

    Honestly, I don't think that's a stance without merit.

  85. Kev

    But... I don't necessarily agree with it :)

  86. MattJ

    Nope, again it's no surprise

  87. Zash

    Adding someone out-of-WhatsApp to your contact list seems like pretty clear opt-in

  88. Matthew > * <@_xmpp_ralphm=2fxsf=40muc.xmpp.org:matrix.org> waves from the floor of the EC DMA Interoperability Workshop in Brussels. waves back from sitting next to ralphm

  89. edhelas

    Stop using WAN to wave at eachother, LAN seems enough then :p

  90. Matthew

    more a PAN thing tbh ;;P

  91. Matthew

    (although apparently the reply fallback looks horrible; oh well)

  92. MSavoritias (fae,ve)

    Yeah that xmpp address has been through some stuff

  93. larma

    Matthew, maybe add support XEP-0461 to the bridge? 🙂

  94. Matthew

    yup, we should. hopefully DMA will encourage more bridge dev!

  95. Zash

    and the future version of the fallback XEP that looks like '461 examples do, but for real

  96. MattJ

    I think the aria-net bridge may already have some improvements in this area (not sure if it has been extended to support '461 yet though)

  97. larma

    Zash, did you just ask the editor to merge PR 1188?

  98. Zash

    larma, maaaaaaaybe

  99. Kev

    Sorry, I know I'm getting increasingly behind on Editor things, I'm *hoping* to find time to work through the triaging of recent PRs in the next day or two.

  100. Kev

    (I've been unwell twice since the Summit, which has assorted knock-on effects)

  101. Zash

    Kev, get well! health should take priority.

    👆️ 1
  102. Kev

    Oh, nothing serious. Just that the summit makes me fall behind on everything, so a few days out ill on top of that means much attempting to tread water until I'm caught up.

  103. nicola

    No answer from Stephen (Meta) to the question about the phone number as identifier. Good point! 😊

  104. ralphm

    nicola: I wanted to see if I could poke that out, while also casually mentioning that WhatsApp is based on XMPP.

  105. ralphm

    Another thing I noticed is that video conferencing seems to be considered a solved problem, because WebRTC. However, WebRTC doesn't standardize signaling.

  106. MattJ

    (including E2EE)

  107. ralphm

    Great comment by EKR on opt-in (per provider) being very weird if you consider interop the default (using telephony as an example)

  108. MattJ

    I'm not surprised at no clear answer from Stephen for a number of reasons: 1) proprietary internal info, 2) I don't think he's an engineer (?), 3) even if they are still internally using '+1234...@whatsapp.com' that doesn't mean much... the assumption is probably baked into so many internal systems that it's no less difficult to change than if they only used '+1234...' internally

  109. nicola

    > I'm not surprised at no clear answer from Stephen for a number of reasons: 1) proprietary internal info, 2) I don't think he's an engineer (?), 3) even if they are still internally using '+1234...@whatsapp.com' that doesn't mean much... the assumption is probably baked into so many internal systems that it's no less difficult to change than if they only used '+1234...' internally 👌

  110. nicola

    I submitted a question online, but I think they will not consider it

  111. larma

    ralphm: WebRTC in browsers use SDP according to the WebRTC spec. Transporting the text-based SDP isn't really a complex thing, it's basically a chat message.

  112. larma

    WebRTC itself is hardly a proper standard though (or, precisely, browsers just do something that's not really well defined)

  113. ralphm

    MattJ: sure. But he started explaining how they started to think about it in the beginning of WhatsApp, so I ventured to see if he'd maybe respond anyway

  114. ralphm

    larma: I think equating signaling to just exchanging a bunch of SDP is too simple a representation of what signaling does.

  115. larma

    ralphm: well, that's what the WebRTC standard says. You're not even really supposed to do anything with the SDP. The browser has a callback "here's some blob" and you're supposed to forward it to the other browser and call a function "here's the blob from the other browser"

  116. Zash

    WebBLOB ?

  117. edhelas

    We need BLOB over XMPP then

  118. Zash

    the BoX protocol?

  119. Peter Waher

    One exists in XEP-0332:

  120. Peter Waher

    https://xmpp.org/extensions/xep-0332.html

  121. Peter Waher

    https://xmpp.org/extensions/xep-0332.html

  122. Peter Waher

    negotiates transfer of BLOBs, using existing mechanisms

  123. singpolyma

    Peter Waher: hmm, that's interesting. I like the text/xml/base64 options there, I always feel icky transporting svg as base64 for example

  124. singpolyma

    I've thought about an extended "bits of binary" that is "bits of stuff, sometimes binary" 😅️

  125. Matthew

    mattj: stephen is a lawyer

  126. Matthew

    so yeah, was not exactly in his depth on tech

  127. MSavoritias (fae,ve)

    so they send a lawyer to a meeting about how to solve tech problems? encouraging

  128. Ellenor Malik

    kategeeper

  129. Ellenor Malik

    blobs of bubbles?

  130. emus

    https://jabbers.one:5281/upload/4SiBgEb-dC09omhUGS6tSQyX/a6ac26ec-6538-467c-a2b7-cf63b5ca09f5.png

  131. emus

    uhh wee

  132. nicola

    FYI Many thanks to jabbers.one to have implemented the upload folder. Now it’s possible to send attachments.

  133. mentos124

    https://sure.im:443/upload/cf0b0313-f4a4-4a4b-a827-32e743a663e3/heppy2.jpg

  134. mentos124

    very cool

  135. nicola

    After my insistence, they created the upload folder as MattJ suggested in the issue (https://github.com/tigase/siskin-im/issues/37#issuecomment-625880042).

  136. emus

    Hey folks, I will announce soon via Fosstodon and Twitter. https://xmpp.org/community/gsoc-2023/ But please start over with advertising yourself and consider to place flyers in you unis or hackerspaces or what ever applies: https://github.com/xsf/xmpp.org/blob/gsoc23-promo-EN-DE/static/images/promo/Flyer_XMPP_GSoC2023_EN.pdf https://github.com/xsf/xmpp.org/blob/gsoc23-promo-EN-DE/static/images/promo/Flyer_XMPP_GSoC2023_DE.pdf

  137. emus

    promo works now nicely in fullscreen via the website: https://xmpp.org/images/promo/Flyer_XMPP_GSoC2023_DE.pdf https://xmpp.org/images/promo/Flyer_XMPP_GSoC2023_EN.pdf

  138. pep.

    btw, I got reminded of the following (biboumi@): 20221231T13:48:02Z 000 <Link Mauve>  You are not allowed to mix ltr and rtl characters in the localpart as per the stringprep spec. 20221231T13:48:23Z 000 <Link Mauve>  Consider it a spec bug if you want. ^^

  139. pep.

    Where do we report such issues

  140. pep.

    This would typically surface in a bridged IRC room with a name composed of RTL chars