XMPP & SIP
There you are :)
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
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
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.
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
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.
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.
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.
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.
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 :/
....until we have intermingled both into the next, new best protocol: XMPatrix lol :-)That said, basic things like "user avatars" are categorized as "advanced client" support so whatever "core" functionality is listed is pretty useless to me.
The "X" in XMPP stands to extensible... How well that actually works is XMPP's killer feature...
Conversations[1]?