XSF Discussion - 2023-02-28

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

Let me tell you about RFC 6331 ✏

it's that, or PLAIN. You pick.

I pick PLAIN

at least there's no perceived sense of security?

indeed

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/

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.

Amazing 🎉 thank you

Thanks Ralph!

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

That's good news Ralph, thanks!

ralphm: thanks for being there and for the update

EXcellent, thanks for the update.

awesome Ralph

thanks for participating ralphm, that's great news!

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

gooya, "it's complicated"

It is a certain time after the gatekeepers have been designated

Which is still to happen

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

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

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)?

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

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.

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

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

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

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

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

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

Yes, that's a good explanation :)

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

> 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

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

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

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.

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

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

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

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

nicola: and thank you for your post.

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

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

MLS?

MIMI?

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.

MLS ? MIMI ? Don't recall

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

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/

yeah

pep.: you mean for the encrypted payload?

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

especially since it will standardize encrypted calls and such

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

so we have time

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

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

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.

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

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

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

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

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

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

true. and if a sufficient amount of shareholders agree

from the other parties

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.

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.

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

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

Zash: I am old enough to remember

maybe with mastodon federation has got a bit more mainstream

who knowss

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

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"

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

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

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

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

So yeah, federation is great

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

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

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

mjk, yeah but they first need to see your mail

To reply to it

exactly

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

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

...and the more, the merrier

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