More Instant Messaging Interoperability
datatracker.ietf.org
datatracker.ietf.org
I get that it is an uphill battle, because there is money to be lost by various corporate interests, but this would likely be one of the first steps to maybe allow hope that it could happen.
You might be thinking "sounds to good to be true" or "no such thing as a free lunch", and if so - you have just won a prize: the EU's Digital Services Act[1]!
This second balancing act includes such wonderful requirements for hosting providers and data processors to pro-actively scan for and report illegal data (leave no bit unturned!), to identify and keep verifiable records of their customers' identities (match those bits!), external auditing and "trusted flaggers" (sell those bits!), full-access no-limits and thus decrypted sharing of customer data with authorities during crises (to ensure the security and continuing stability of the Galactic Republic!).
Hopefully this attempt at bringing the news in a comedic manner has helped to soften any feelings of hopelessness and impending doom :D
https://ec.europa.eu/info/strategy/priorities-2019-2024/euro...
https://ec.europa.eu/info/strategy/priorities-2019-2024/euro...
The DSA also has good parts like preventing sites from doing the following:
Site: We have suspended you account and hidden all content you posted because our buggy AI thinks some content you posted violates a law or term of service. This is a final decision and cannot be appealed.
You: What content? What law or term of service?
Site: we don't have to tell you, and we don't have to tell you. We said this was final with no appeal so you are lucky we are even replying in the first place.
You: now you must attempt to make a big enough shitstorm on twitter that the company might actually get a human to look at things and notice their shitty AI made a mistake.
Instead the law requires identifying the content with specificity, identity which law or term of service they think was violated with specificity, they must have a human powered appeals process. It provides a non-binding out of court dispute settlement process, as an alternative to suing the company to force them to comply with the law.
For reference, the act as enacted: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A...
More often than not those end up not having been too far off.
The total time to implement might get stretched out, components dirtied by general public resistance will be repackaged or repurposed, and any debate or discussion not in the plan's favour will be actively misdirected.
It's a sound strategy, and I hate everything about it.
> or only applies to very large platforms
Even a single one of which is nigh impossible to avoid. At least some data - either by you, from you, or about you - will end up on AWS/GCP/Azure. A fact of life.
> has good parts
All of which solve problems that are easily mitigated today, on my own terms, for less effort, and either for free or for cheap.
Not a very good deal at all.
Come to think of it. You raised a very interesting point. I will need to think of it a little bit more. I want open standards to reign, but is it ok to enforce destruction of walled gardens.
The rest of the world would probably say no of course.
You just have to choose which bubbles you are part of.
Global discourse on walled gardens, or geeks in a corner on IRC, or both, or neither.
The founders of Wire previously contributed to the Opus HD audio code that laid the groundwork for WebRTC, now ubiquitous in remote/WFH conferencing products. With the IETF MLS protocol for encrypted group messages now defined, interoperability between messenger services is the next step.
This IETF MIMI group may be small, but they are not starting from scratch, as interoperability was often discussed, and deferred to this anticipated project, during IETF MLS protocol design.
https://www.ietf.org/archive/id/draft-movva-msn-messenger-pr...
I wonder why they closed the source. Even if there is no 'benefit' to the team, sharing the source guarantees the longevity and preservation of MSN Messenger. That benefits the future, as well as everyone interested in MSN now.
I wonder why they haven't mentioned the Matrix protocol there.
iMessage has a unique mapping between iMessage account and phone number. Signal has another. WhatsApp has another. If you want to message 650-867-5309, who should receive the message?
If there is no account on that service, just like email, there would be a failure message but it should work.
This is how mastodon or matrix does local handles vs federated handles. Simple @user for local and @local@server for outside.
- [1] https://github.com/micro/network/blob/main/PROTOCOL.md - [2] https://github.com/micro/micro
There you are :)
SIP tried to do too much, was overly complex, XML-based and ended up doing nothing well enough to establish itself as a market/community favourite. "Nobody" outside telecoms does SIP, and I think that tells all one needs to know wrt market-penetration.
These days I'm rooting for matrix[1]. Matrix seems to solve the issues people want IM to solve, it federates, and supports bridging to other types of networks which aren't matrix-based.
It's not perfect. It may not be the final IM-solution to rule them all.
But for me at least, it's a good, working solution for a federated, decentralized platform (in the original sense, not crypto hog-wash sense) for the IM needs I have.
It might "just" be one step towards a better solution, but I'm sure the experiences people have with using and developing matrix is crucial in forming the solution-space in the right direction.
We're not going to get to a decentralized and "good enough" solution unless someone is willing to walk down this road and take the first bumps for the team.
I got my own instance, my own users, my own federated channels, serving my communities. Are you?
XEP-0313: Message Archive Management https://xmpp.org/extensions/xep-0313.html
> This document defines a protocol to query and control an archive of messages stored on a server.
Since 2012. Implemented in all the major servers and clients for at least 5 to 10 years now.
he said "good"
MAM does not work with encryption and multiple devices, it relies on potentially different servers for each room -> other server goes down -> part of your history is lost, it is only for MUCs
False. MAM is explicitly designed for use with multiple devices. OMEMO is fully compatible with MAM and multiple devices too.
> it relies on potentially different servers for each room
In XMPP, as deployed on the public network, each group is responsible for hosting its own data. That is, they do not replicate the group data and state between all federating servers that are part of the group in the way Matrix does. If the group goes down permanently and you do not have the history from the group saved locally in your client, you are correct that the data for that group is lost. Most XMPP clients default to keeping history on the user's device, rather than treating the server as a permanently available source of history.
My experience is that this is good enough for most people, and the extra complexity of fully replicating groups is not necessary for the average person. That's not to say it doesn't have some uses (for which XMPP does have solutions, such as FMUC, they just aren't usually implemented or deployed on the public network - https://www.isode.com/whitepapers/federated-muc.html ).
> it is only for MUCs
This is also false, as you can see from even a cursory reading of the spec.
please expand on how OMEMO encrypted messages land readable on other devices of you through MAM
> If the group goes down permanently
= certain single server in the group
> My experience is that this is good enough for most people
In mine it isn't when virtually anyone is (supposed to be) able to run a server, which he might abandon due to lost interest or might fail due to unprofessional maintenance.
> This is also false, as you can see from even a cursory reading of the spec.
you take that point
Not GP, and I don’t know how it works technically, but I can confirm that OMEMO encrypted messages sync to other devices when I come back online there.
To be clear, only the server that the group is hosted on. Servers are not "in groups", so your statement doesn't make sense.
> please expand on how OMEMO encrypted messages land readable on other devices of you through MAM
MAM is a feature of XMPP that provides a way to query all incoming and outgoing messages, including those received while the client was offline.
OMEMO is a many-to-many end-to-end encryption protocol. Whether a message is delivered while a client is connected, or later via synchronization after a period of disconnection, doesn't have any effect on the encryption or ability of a client to decrypt the message.
These things can all be verified by reading the specs or simply using any modern XMPP client and observing it work for yourself.
Fullstop
> Whether a message is delivered while a client is connected, or later via synchronization after a period of disconnection, doesn't have any effect on the encryption or ability of a client to decrypt the message.
what about when a client creates a fresh connection and I want to read my messages on it?
I agree that this does not create the best "user experience", but if that is what you are looking for, maybe you didn't want E2EE in the first place? It could be possible to have a XEP that covers "history syncing between my devices", but what's the point of E2EE if encrypted information can just be transferred and duplicated like this?
It's also possible to disable OMEMO if having history sync'ed on any new device is what's most important to you. It's not like messages are sent as plain unencrypted text (unlike email...), TLS is used. If you and the other end are on servers you trust (or own), there is little reason to use OMEMO anyway. Except that nice lock icon that supposedly means "safe" without really defining "safe *from what*".
why?
> If I sent encrypted messages to a trusted device of yours, I suppose I don't really want any new device of yours to get these messages.
I actually do.
> maybe you didn't want E2EE in the first place
I am sure I do want E2EE.
> but what's the point of E2EE if encrypted information can just be transferred and duplicated like this?
being able to read my messages on all my devices?
> If you and the other end are on servers you trust (or own),
I have to also trust the servers of all my contacts. Where did I imply that?
> Except that nice lock icon that supposedly means "safe" without really defining "safe from what".
safe from anyone being able to read my messages except me and my communication partners
If you have E2EE but then one the two ends can be substituted for a new one, does it really qualifies as E2EE? If I have a hard requirement on E2EE, it probably means I don't want encrypted messages stored forever on remote servers, and easily decrypted on new devices. Or it can also mean I don't really understand what encryption mean, and I'm only interested in having a nice looking lock icon next to my messages.
>> If I sent encrypted messages to a trusted device of yours, I suppose I don't really want any new device of yours to get these messages. > I actually do > I am sure I do want E2EE.
Then what you are looking for is opengpg-type encryption (which is available via XMPP's most popular clients too). It's a lot less convenient to set up but this is how you switch from "device key" to "personal key".
> I have to also trust the servers of all my contacts. Where did I imply that?
Where did I imply that? I just gave you an example use case that is generally not tagged as E2EE but where no one but you and your contact can read your messages (self hosting).
> being able to read my messages on all my devices?
I can read all my OMEMO encrypted messages on all my devices. If I use a new device, I cannot read history. But that's because OMEMO isn't just for show (the nice lock icon), but actually something that makes it nearly impossible for anyone but you or your communication partner to read what you exchanged.
Also, most XMPP clients also allow to export local history, which could then be imported again, so if keeping all chat history really matters to you, it's also possible. But again, if you plan to store messages forever, you increase the chance of it being read by third parties significantly.
> safe from anyone being able to read my messages except me and my communication partners
If that is all that matters to you, facebook messenger has E2EE and it should suit your needs. It has the nice lock icon you're looking for. I think that who you talk to and how often you do is also rather important for privacy concerns, that's why I self host my XMPP server.
You seem to like the matrix protocol, where even if you self host, a lot of data is sent to the mother ship, cf https://hackea.org/notas/matrix.html
That article is bullshit and FUD (as its subheading seems to acknowledge). No data is sent back to matrix.org if you selfhost (unless you point your config at matrix.org, obviously).
There is a lot of FUD about XMPP in comments on HN, and I feel bad for (potentially) doing the same thing about matrix, this was not my goal.
np; thanks for listening :)
> I think my other points about E2EE still stand, don't they?
I think the question is whether the recipient should be able to move message keys between their devices so they can decrypt messages from the server when they log in on a new device. Given the recipient already has the plaintext of the messages, they can obviously copy the plaintext to the new device (as Signal and Wire do, for instance).
Alternatively, if the recipient has the message keys (as in Matrix), they can copy those to the new device and use them to redecrypt the history off the server. This gives the same end result, but with less data being transferred between the clients. It doesn’t violate any E2EE; it’s just the recipient chosing to process their history as they like.
it's not only two ends, but as many ends as there are people belonging to a conversation. And yes, replacing or adding one device for one end with a device that belongs to the "end", still qualifies e2ee.
> If I have a hard requirement on E2EE, it probably means I don't want encrypted messages stored forever on remote servers, and easily decrypted on new devices.
"probably" it doesn't mean that. It means that no one except the (intended) ends (all legitimate people in the conversation respectively their devices) can read my messages.
> Where did I imply that? I just gave you an example use case that is generally not tagged as E2EE but where no one but you and your contact can read your messages (self hosting).
I don't know why we are talking about this. It requires everyone to self host btw. Not realistic.
> But again, if you plan to store messages forever, you increase the chance of it being read by third parties significantly.
True, but I think that should be a choice of the user. Don't want to have slightly increased risk? Delete the messages. For all devices (you are still storing them forever if you only do that for one device). Perhaps even delete automatically after some time after arrival/viewing the message.
I do agree that can be a source of friction for users. And perhaps an encryption system that doesn't require forward secrecy would be enough for most.
I am not aware that forward secrecy is contradictory to that.
Turn any XMPP client into that fancy multiprotocol chat app that every cool kid want.
> Signal, Telegram, Discord, Steam, Mattermost, Facebook, Skype
Spectrum is an open source instant messaging transport. It allows users to chat together even when they are using different IM networks.
https://github.com/louiz/biboumi
Biboumi is an XMPP gateway that connects to IRC servers and translates between the two protocols. It can be used to access IRC channels using any XMPP client as if these channels were XMPP MUCs.
------
I'm using all of those daily to connect to all my other accounts, Slidge is the most modern one and is having lots of features ported to the modern XMPP extensions.
Nice, didn't know this exists. Thanks for the link.
I was planning to install it, but still didn’t find the time yet :/
If we want to have messenger interoperability we need standardization. Matrix should focus on compliance with the existing XMPP internet standard instead of inventing yet another set of incompatible primitives.
They chose Zulip, because it is a product that has various features that are attractive for the IETF's use cases. The protocol it uses internally is pretty irrelevant from the IETF's perspective, as a user.
If the IETF had developed its own chat tool and did not use XMPP for that, your comment would have more weight.
It does. Incoming and outgoing messages are synchronized across all your devices. Work on that feature began in 2012 (before Matrix was born), and is specified in XEP-0313: https://xmpp.org/extensions/xep-0313.html
Due to people having multiple devices, and those devices having unreliable connections, it's obviously an essential part of any XMPP-based IM client these days. It's been required for full XMPP IM compliance since at least 2018.
....until we have intermingled both into the next, new best protocol: XMPatrix lol :-)The "X" in XMPP stands to extensible... How well that actually works is XMPP's killer feature...
That said, basic things like "user avatars" are categorized as "advanced client" support so whatever "core" functionality is listed is pretty useless to me.
Conversations[1]?
There are a lot of problems in the IM space, but lack of standards isn't one of them.
They obviously need their own SMTP servers, I'm not giving a third party my e-mail login?
SMTP and HTTP... everything else is crap.