XSF Discussion - 2023-02-27

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.

👋

Hope something good comes out from this ! 😊

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

Great intervention @ralphm !

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

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.

💪️

[wrong room, apologies] ✏

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

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

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)

Who's "we"? :P

This community (but not only)

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

Well that's *technically* true

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 ✏

> 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.*

> 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.

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

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

Interesting that they basically just rejected MLS

> 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 😊

and MIMI rejected

No surprises here :)

> they who? EU? GAFAM?

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

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

They want E2EE interop to be based on the Signal protocol

So what they already have?

Yes :)

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. ✏

is this where misanthropy intensifies?

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

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

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

jonas’, only hatred of capitalism

> 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.

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

True

And I feel any kind of forcing is very unlikely

Just curious how they spinned it

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

I think ietf is hopelessly optimistic when capisalist companies are involved

I mean past efforts to standardize messaging didnt work

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

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

Makes sense

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

Agreed

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

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

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

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

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

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

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

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

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

Yes, it sounds increasingly likely

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

do I want to know what that is?

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

Yes

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

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

Isn't client side bridging just called swimming?

And use it as cover for reversing

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

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

right

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

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

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?

Sounds like an afternoon /s

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

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

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

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

Nope, again it's no surprise

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

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

more a PAN thing tbh ;;P

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

Yeah that xmpp address has been through some stuff

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

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

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

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)

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

larma, maaaaaaaybe

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.

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

Kev, get well! health should take priority.

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.

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

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

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

(including E2EE)

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

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

> 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 👌

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

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.

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

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

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

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"

WebBLOB ?

We need BLOB over XMPP then

the BoX protocol?

One exists in XEP-0332:

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

negotiates transfer of BLOBs, using existing mechanisms

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

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

mattj: stephen is a lawyer

so yeah, was not exactly in his depth on tech

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

blobs of bubbles? ✏

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

uhh wee

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

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

very cool

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

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

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

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. ^^

Where do we report such issues

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