This and this alone explains why people flocked to Signal rather than matrix or xmpp, which the average user couldn’t “flock to” even if they wanted to. Signal made a conscious choice to be user friendly rather than nerdy/wonky and that is why tons of people have more secure chat now.
The single “point of failure/compromise” point is valid and I like the authors idea of “balancing” the two approaches, though it sounds a bit like “we’re building a new protocol,” practically speaking. If I send a threaded reply and your XMPP client doesn’t support that, then what?
I tried matrix lately. It created a security passphrase for me. I copied it into my password manager and made sure about surrounding whitespace etc. Then when it asked me for the first time to enter this passphrase I pasted it. It told me it was wrong. I had to go to the web version to reset the passphrase because the desktop variant would ask me for the passphrase to reset the passphrase. I created a new passphrase stored it in my password manager, this time making painstakingly sure it was exactly as displayed.
Guess what. I was asked to enter it immidiately after. It was wrong again.
Even if I am convinced of a decentralized, federated concept, software just needs to work. If I, as a programmer with a ton of patience can't get it to work, asking my non-programmer friends to use it is something I won't do.
I think where it went wrong here is that when it asked you for your "passphrase" (which is called a recovery key) it's very likely it wanted your login password instead. (Because that is indeed needed to reset the recovery key).
The recovery key (whitespace doesn't matter btw, it's just a 48 char string) is only needed when you logout of all devices and subsequently want to restore your encrypted messages.
> If I send a threaded reply and your XMPP client doesn’t support that, then what?
I don't know how XMPP works, but a well designed protocol would be backwards compatible such that threaded messages would simply be normal messages in older clients. Here, those with the old clients would still get something useful while those with new clients get the full experience.
I, on the contrary, disagree with the single point of failure point. Nothing prevents Signal to internally build n systems that federates together and can be down/broken independently.
Isn't think sort of zero sum thinking a bit uncreative? I'm not sure there is any law of nature that says you must pursue one to the exclusion of the other.
I think the flexibility of XMPP is also it's big problem. All the features are optional, so you cannot even answer a simple question like:
- Hey, my friend says she uses XMPP. If I send her a picture to a phone, can she later print it on the computer?
- So if I install that XMPP app I found on the internet, do I get offline messages?
The "compliance suites" are nice, but they are usually not shown in the program description. I mean, even conversations.im lists individual XEPs [0] -- this is not user-friendly at all!
What XMPP needs a nice, catchy name for "compliant" software which one can use to search for apps, and which can be used to communicate. Maybe "XMPP-2020"? Or even all-new name like "Snikket"? Something that will clearly tell users: "yes, this is a modern chat programs with all the features you'd expect from others"
That's pretty much what Snikket is aiming to be. "XMPP" is a term for developers, and at most informing users that it's compatible with other XMPP software.
Users don't even really want to keep track of annual compliance suites, let alone XEPs. "Snikket" can stand for a consistent set of the latest XMPP features.
Yes that's precisely what the Snikket project is about. There also joinjabber.org (disclaimer: i'm part of it) which is just getting started: we don't build an XMPP distribution, but part of our mission is to evaluate and/or recommend clients based on high-level features and usability for end-users.
This piece kind of misses the point of the "Ecosystem is Moving" post. It's not that XMPP, the protocol, can't develop new features like OMEMO (I guess it's easier when you have Signal to crib from, but whatever). It's that you can't guarantee most mainstream clients will support those features, and so you're stuck at a lowest common denominator --- not of the protocol, but of the installed base.
This was touched upon - the point is that XMPP's extensibility means we aren't "stuck at the lowest common denominator".
One of the burdens of the ecosystem, for example, is Pidgin. I don't want to pick on the project too hard, I know they're working on various things including a big refactor for Pidgin 3.0. But the reality is that Pidgin has implemented few (if any) of the XMPP features introduced in the past decade. Yet it's still an amazingly popular client.
That means the experience for Pidgin users is getting progressively worse as the rest of the XMPP ecosystem moves on, but we don't add new features to XMPP and think "but no, because Pidgin!". We do consider backwards compatibility in general. And while it's surely slower and more effort than just rolling out an update to a single app on the app store, it's not "stuck".
I appreciate the path Signal took (possibly more than many in the decentralized protocol communities), but simply believe that what was lost in pursuing a centralized model is not something I'm okay with losing.
> This was touched upon - the point is that XMPP's extensibility means we aren't "stuck at the lowest common denominator".
To echo the sibling comments - with security you are stuck at the lowest common denominator. If anyone in your ecosystem can negotiate down the security (because they don't support it) then the system as a whole is vulnerable. There are UI things you can do to highlight this ("messages to this destination are not secured") but it becomes complex and confusing for users (what happens if you have a group of people with secure features and you add someone without?).
In summary - I can see where Snikket is coming from. It gives a common name to talk about - a new lowest common denominator feature set.
I think the real problem isn't that some clients support emojis and some don't, it's that Signal is a security product and lowest common denominator in the installed base can mean broken security. I can see why Moxie makes this tradeoff, but I am also pleased by the way the encryption system is making its way into other platforms. Hopefully, this will over time result in some kind of useful ecosystem, but you might only want to trust the part of it that is more strictly controlled for "serious business".
Interesting aside: Instant messaging on the desktop seems to be practically dead. The signal desktop client is only meant as a companion to the phone app. And now Snikket doesn't even list a desktop client. I still don't really understand how we got here and why nobody is talking about it.
Well sure that's a strong selling point of both matrix and XMPP. What matrix clients are you using and which do you recommend for desktop use? I stopped using matrix because Element was really slow/buggy, but decent CLI/desktop clients with tor integration do interest me (there was just none of those at the time).
Presumably because one of the main attractions of IM clients is being able to quickly get someone to respond. Many people carry their personal phone around all the time and are proactively notified when you send them a message, whereas they spend far less time on personal desktops, and notifications there are far less intrusive.
Still, most of the time a lot of people will be sitting in front of or pretty close to their laptops. Having the clients available on the phone should not mean that we can't have it on the desktop as well. Though, of course, the number 1 priority is being accessible, so unfortunately the priority will be the mobile app, even if quite a lot of people would use that less, for longer chats if they had a choice.
Actually a desktop client is planned. But it's definitely a minority of people who want one, so we're working to get mobile right first.
I actually think we have a competitive advantage here... developing native desktop apps is costly, and most commercial platforms don't bother these days (most you'll get just use a web client in Electron).
However I believe open-source makes it possible to sustain. You can already use native clients such as (the latest version of) Gajim with a Snikket server, but currently without the guarantee it's been tested and interoperable on every single feature... we'll get to that.
> I actually think we have a competitive advantage here... developing native desktop apps is costly, and most commercial platforms don't bother these days (most you'll get just use a web client in Electron)
Telegram has a Qt client which is faster and slicker than anything electron-based tho
You should give dino.im a try. I've been using it for the last few months alongside conversations.im and it's been great with syncing even encrypted messages.
He's not talking about corporate messengers, that's for sure.
He's talking about the most used apps in the world, the ones you use to keep in touch with friends and family. Most of their apps are either websites on top of a bundled browser.
I think the biggest reason we don't see a bigger adoption of federated XMPP is because unlike email chat wasn't seen as a serious communication tool or essential for business until recently. I feel like it was seen as a nice to have "toy", almost something for the kids growing up on the internet to use to talk where as "real" adults used the phone or wrote "digital letters".
For that reason it was never bundled with your internet connection like email and so the main stream masses never learned how the federation worked. So when stripped down versions with no out of the box federation (see Google and Facebook's early chat offerings) started to became popular it was easier to pull up the walled garden with impunity.
As they were able to introduce the new bells and whistles faster because they could safely ignore federation issues they could then have nice differentiation's from other competing chat networks
While rarely seen that way my employer was using XMPP in 2006. It was great for compliance when one couldn't be leaking client data into AOL instant messenger.
This post promotes Snikket, a chat app built on top of XMPP. It talks a lot about decentralization and protocol development, but I doubt it will be able to best Matrix in this regard. Matrix has bridges connecting it to other apps like Facebook Messenger.
XMPP, meanwhile, seems to have been shuffling along slowly for 20 years without many users or features that appeal to a mass audience (GIFs, etc). So while Matrix could potentially (or already does) link up with Signal, this app doesn't seem like it could get traction/expand because of the dubious base that it stands on.
> XMPP, meanwhile, seems to have been shuffling along slowly for 20 years without many users or features that appeal to a mass audience (GIFs, etc)
GTalk was based on XMPP and for many years supported federation with XMPP servers, even for a year or more after Google announced it was going to end federation. (IIRC, it supported XMPP almost until the day they pulled the plug entirely, circa 2016-2017.) Because of its integration with GMail[1] and GMail's prevalence, XMPP (both the protocol and the network) was one of the largest, if not the largest, IM network.
Matrix is a nice protocol but at the end of the day it's biggest differentiator with XMPP is using HTTP and JSON for transport. Theoretically that means it should be easier to implement Matrix clients and servers, but in reality AFAICT the XMPP ecosystem is still richer than Matrix. Worse, Matrix deployment still seems far more centralized than XMPP ever was. I'm curious, by show of hands who in this forum runs or has run for any significant amount of time their own federated Matrix server? XMPP server? I ran my own XMPP server for years until GTalk dropped off.
I would love to see Matrix achieve widespread federated deployment. Personally I think XMPP stands a better chance, if only because it came tantalizingly close to critical momentum, joining the ranks of HTTP and SMTP, before Google killed it[2]. But I really couldn't care much one way or another which protocol wins so long as we see a real, federated solution.
I would try running my own Matrix server but I'm still confused whether I need to register my own user ID or my own server with a central Matrix authority (other than DNS), which seems like it defeats the purpose of traditional federation. Running an XMPP server was easy--once DNS records were properly published people could just contact me at my e-mail address.
[1] You could chat with anyone logged into the GMail web interface.
[2] IIRC, the official reason was because of spam, though Google seemed to have had basically solved that by the time they ended federation. The real reason seems to have been that other IM networks, like MSN, abused XMPP GTalk federation in an anti-competitive manner, so Google decided to take its ball and go home. Also, GTalk apparently worked too well--after GTalk was a series of horrible products and services that ending up destroying Google's position in the IM space.
I run a personal federated matrix server. It has many .. 'quirks', including an upgrade that screwed up my database and required me to redo it from scratch, and a lot of little ongoing http requests (as it syncs room state and what not) I'm doing it as a test run to see if it would work as an IRC replacement at my day job, but based on my experience, I have not found anything as maintenance free as our IRC server.
FWIW, my current primary use case is running a matrix/sms gateway on my phone so I can forward my SMS to my desktop; the xmpp one I used eons ago was slightly more cumbersome.
Quick edit: there is no central authority to register your personal server. you create a /.well-known/matrix/server endpoint on your primary domain that points at your real matrix server (and/or DNS SRV records) and your good to go.
I've been running a Matrix server for a half a year and I have not run into any problems. The main thing that surprised me was how much database space Synapse took on my server but that was an easy enough issue to deal with. That may also have to do with the fact that I'm in some of the most complex rooms that exist on Matrix.
I tried running a XMPP server for a bit but that was a rather frustrating experience between getting it to integrate well with the rest of my infrastructure, figuring out what configuration was needed and what XEPs were needed, what clients had the features I needed, what clients supported the OSes I used, and spam. To be fair, the reason I thought setting up Synapse was extremely easy may have been because I did it with almost twice as much experience with devops than I had when I tried to setup the XMPP server.
Regarding registering with a central authority, you're probably thinking of identity servers. Identity servers are used to provide 3PID (email/phone number) -> Matrix ID mappings and are completely optional. There have been attempts to decentralize that as well but for one reason or another, no good way to do it has been found. At least the source code of the identity server is open source[1] so there is that.
Otherwise, to set up a Matrix server, you simply have to either set up a json response from "/.well-known/matrix/server" or an SRV record on DNS that points to the Matrix server.
> Matrix is a nice protocol but at the end of the day it's biggest differentiator with XMPP is using HTTP and JSON for transport.
I feel like people overstate the benefit of this. You can make easy to implement protocols on top of http, json or whatever, or you can make hard ones. They are tools like any other. They don't magically make things easy in and of themselves, its all in how you use them.
> So while Matrix could potentially (or already does) link up with Signal
Matrix doesn't link up with Signal. The Signal devs have emphasized time and time again that they don’t want any third-party applications talking to their servers. While there does exist some outside software that connects to Signal’s own infrastructure without Signal’s permission (e.g. signal-cli), that is only tolerated because those third-party apps have very few users.
While you’re very correct about Signal’s hostility to third-party clients, there is a decently well-functioning Signal bridge for Matrix (using signald under the hood).
They very well might sabotage that, but it does link up today.
Such gateways eventually get banned/blocked by the siloed IM systems. So the XMPP people have over the years tired of the game. The same will happen in the case of Matrix.
> It talks a lot about decentralization and protocol development, but I doubt it will be able to best Matrix in this regard. Matrix has bridges
XMPP has had bridges for more than a decade. That was actually one of the core promises of the XMPP protocol, compared to others (like IRC). Both XMPP and matrix have exactly the same promise to be the only and ultimate federated protocol you will ever need, so there's no real distinction on this front.
> without many users or features that appeal to a mass audience
Many people were (are?) unconsciously using Jabber/XMPP on a daily basis. What plagued XMPP is open standards with closed-source implementations: i.e. private companies ripping off the benefits of specifications. There's a ton of fancy new features in the Jabber/XMPP ecosystem, including some unique stuff like federated forging: https://staticadventures.netlib.re/blog/decentralized-forge/
This really shouldn’t come as a surprise. The average mobile user will give you app less than 30 seconds of their attention after first install so you’d better deliver some kind of result in that time or they’re gone, probably for good.
Also chat users care more about GIFs than security.
And none of the XMPP clients or any of the Matrix clients get the on-boarding step idiot-proof. Matrix tries harder at it, maybe they will eventually succeed. I have zero hope for XMPP, but I'm happy to be surprised.
I actually am quite proud of what we've done for Snikket onboarding.
To eliminate the "argh, what server?" step we focus on invites which guide you through the process, and ensure you have an initial contact or group, not an empty contact list.
I tested it on many people while working on it. The vast majority (with no familiarity with XMPP or decentralized systems) were signed up in just a couple of minutes.
Onboarding some services is surprisingly easy. Like MattJ mentioned there is now prosody's mod_invites. For phone-based users, quicksy.im is doing a very good onboarding job. It's a fork of conversations (by the same maintainers) with phone-number based contact discovery like Signal and others do.
Also worth mentioning, when you have privacy in mind, Jabber/XMPP is very easy to join as most operators don't have any problem with Tor users, and Tor support (also other proxies) is well supported in most clients.
>Also chat users care more about GIFs than security.
This is why it is so important that the devs care about the security and just make it part of the app without needing the user to do anything other than use the app.
If I had a wish, I’d love to see a user-focused Matrix client from a big company that’s not too evil like Mozilla. Heck, if Apple changed iMessages to speak Matrix, that’d be amazing. One can only dream…
Yes I have, and it looks really cool. Only problem is that to bridge iMessage, you need a jail broken phone or always-on Mac. I’d love something native.
Readit News
- Building an ecosystem: building for developers
- Building a product: building for users
This and this alone explains why people flocked to Signal rather than matrix or xmpp, which the average user couldn’t “flock to” even if they wanted to. Signal made a conscious choice to be user friendly rather than nerdy/wonky and that is why tons of people have more secure chat now.
The single “point of failure/compromise” point is valid and I like the authors idea of “balancing” the two approaches, though it sounds a bit like “we’re building a new protocol,” practically speaking. If I send a threaded reply and your XMPP client doesn’t support that, then what?
Guess what. I was asked to enter it immidiately after. It was wrong again.
Even if I am convinced of a decentralized, federated concept, software just needs to work. If I, as a programmer with a ton of patience can't get it to work, asking my non-programmer friends to use it is something I won't do.
The recovery key (whitespace doesn't matter btw, it's just a 48 char string) is only needed when you logout of all devices and subsequently want to restore your encrypted messages.
I don't know how XMPP works, but a well designed protocol would be backwards compatible such that threaded messages would simply be normal messages in older clients. Here, those with the old clients would still get something useful while those with new clients get the full experience.
Is this likely? No. Is this a single point of failure? Yes.
All the internal federation in the world does not allow me to pack up and move while still chatting with my old contacts.
- Hey, my friend says she uses XMPP. If I send her a picture to a phone, can she later print it on the computer?
- So if I install that XMPP app I found on the internet, do I get offline messages?
The "compliance suites" are nice, but they are usually not shown in the program description. I mean, even conversations.im lists individual XEPs [0] -- this is not user-friendly at all!
What XMPP needs a nice, catchy name for "compliant" software which one can use to search for apps, and which can be used to communicate. Maybe "XMPP-2020"? Or even all-new name like "Snikket"? Something that will clearly tell users: "yes, this is a modern chat programs with all the features you'd expect from others"
[0] https://play.google.com/store/apps/details?id=eu.siacs.conve...
Users don't even really want to keep track of annual compliance suites, let alone XEPs. "Snikket" can stand for a consistent set of the latest XMPP features.
One of the burdens of the ecosystem, for example, is Pidgin. I don't want to pick on the project too hard, I know they're working on various things including a big refactor for Pidgin 3.0. But the reality is that Pidgin has implemented few (if any) of the XMPP features introduced in the past decade. Yet it's still an amazingly popular client.
That means the experience for Pidgin users is getting progressively worse as the rest of the XMPP ecosystem moves on, but we don't add new features to XMPP and think "but no, because Pidgin!". We do consider backwards compatibility in general. And while it's surely slower and more effort than just rolling out an update to a single app on the app store, it's not "stuck".
I appreciate the path Signal took (possibly more than many in the decentralized protocol communities), but simply believe that what was lost in pursuing a centralized model is not something I'm okay with losing.
To echo the sibling comments - with security you are stuck at the lowest common denominator. If anyone in your ecosystem can negotiate down the security (because they don't support it) then the system as a whole is vulnerable. There are UI things you can do to highlight this ("messages to this destination are not secured") but it becomes complex and confusing for users (what happens if you have a group of people with secure features and you add someone without?).
In summary - I can see where Snikket is coming from. It gives a common name to talk about - a new lowest common denominator feature set.
I don't know about the others. Are any of them native?
I actually think we have a competitive advantage here... developing native desktop apps is costly, and most commercial platforms don't bother these days (most you'll get just use a web client in Electron).
However I believe open-source makes it possible to sustain. You can already use native clients such as (the latest version of) Gajim with a Snikket server, but currently without the guarantee it's been tested and interoperable on every single feature... we'll get to that.
Telegram has a Qt client which is faster and slicker than anything electron-based tho
Deleted Comment
He's talking about the most used apps in the world, the ones you use to keep in touch with friends and family. Most of their apps are either websites on top of a bundled browser.
For that reason it was never bundled with your internet connection like email and so the main stream masses never learned how the federation worked. So when stripped down versions with no out of the box federation (see Google and Facebook's early chat offerings) started to became popular it was easier to pull up the walled garden with impunity.
As they were able to introduce the new bells and whistles faster because they could safely ignore federation issues they could then have nice differentiation's from other competing chat networks
XMPP, meanwhile, seems to have been shuffling along slowly for 20 years without many users or features that appeal to a mass audience (GIFs, etc). So while Matrix could potentially (or already does) link up with Signal, this app doesn't seem like it could get traction/expand because of the dubious base that it stands on.
GTalk was based on XMPP and for many years supported federation with XMPP servers, even for a year or more after Google announced it was going to end federation. (IIRC, it supported XMPP almost until the day they pulled the plug entirely, circa 2016-2017.) Because of its integration with GMail[1] and GMail's prevalence, XMPP (both the protocol and the network) was one of the largest, if not the largest, IM network.
Matrix is a nice protocol but at the end of the day it's biggest differentiator with XMPP is using HTTP and JSON for transport. Theoretically that means it should be easier to implement Matrix clients and servers, but in reality AFAICT the XMPP ecosystem is still richer than Matrix. Worse, Matrix deployment still seems far more centralized than XMPP ever was. I'm curious, by show of hands who in this forum runs or has run for any significant amount of time their own federated Matrix server? XMPP server? I ran my own XMPP server for years until GTalk dropped off.
I would love to see Matrix achieve widespread federated deployment. Personally I think XMPP stands a better chance, if only because it came tantalizingly close to critical momentum, joining the ranks of HTTP and SMTP, before Google killed it[2]. But I really couldn't care much one way or another which protocol wins so long as we see a real, federated solution.
I would try running my own Matrix server but I'm still confused whether I need to register my own user ID or my own server with a central Matrix authority (other than DNS), which seems like it defeats the purpose of traditional federation. Running an XMPP server was easy--once DNS records were properly published people could just contact me at my e-mail address.
[1] You could chat with anyone logged into the GMail web interface.
[2] IIRC, the official reason was because of spam, though Google seemed to have had basically solved that by the time they ended federation. The real reason seems to have been that other IM networks, like MSN, abused XMPP GTalk federation in an anti-competitive manner, so Google decided to take its ball and go home. Also, GTalk apparently worked too well--after GTalk was a series of horrible products and services that ending up destroying Google's position in the IM space.
I run a personal federated matrix server. It has many .. 'quirks', including an upgrade that screwed up my database and required me to redo it from scratch, and a lot of little ongoing http requests (as it syncs room state and what not) I'm doing it as a test run to see if it would work as an IRC replacement at my day job, but based on my experience, I have not found anything as maintenance free as our IRC server.
FWIW, my current primary use case is running a matrix/sms gateway on my phone so I can forward my SMS to my desktop; the xmpp one I used eons ago was slightly more cumbersome.
Quick edit: there is no central authority to register your personal server. you create a /.well-known/matrix/server endpoint on your primary domain that points at your real matrix server (and/or DNS SRV records) and your good to go.
I tried running a XMPP server for a bit but that was a rather frustrating experience between getting it to integrate well with the rest of my infrastructure, figuring out what configuration was needed and what XEPs were needed, what clients had the features I needed, what clients supported the OSes I used, and spam. To be fair, the reason I thought setting up Synapse was extremely easy may have been because I did it with almost twice as much experience with devops than I had when I tried to setup the XMPP server.
Regarding registering with a central authority, you're probably thinking of identity servers. Identity servers are used to provide 3PID (email/phone number) -> Matrix ID mappings and are completely optional. There have been attempts to decentralize that as well but for one reason or another, no good way to do it has been found. At least the source code of the identity server is open source[1] so there is that.
Otherwise, to set up a Matrix server, you simply have to either set up a json response from "/.well-known/matrix/server" or an SRV record on DNS that points to the Matrix server.
[1]: https://github.com/matrix-org/sydent
I feel like people overstate the benefit of this. You can make easy to implement protocols on top of http, json or whatever, or you can make hard ones. They are tools like any other. They don't magically make things easy in and of themselves, its all in how you use them.
Matrix doesn't link up with Signal. The Signal devs have emphasized time and time again that they don’t want any third-party applications talking to their servers. While there does exist some outside software that connects to Signal’s own infrastructure without Signal’s permission (e.g. signal-cli), that is only tolerated because those third-party apps have very few users.
They very well might sabotage that, but it does link up today.
XMPP is traditionally all about intercommunication with other systems. Here is a XMPP transport for Whatsapp for an example:
* https://git.theta.eu.org/eta/whatsxmpp
Such gateways eventually get banned/blocked by the siloed IM systems. So the XMPP people have over the years tired of the game. The same will happen in the case of Matrix.
XMPP has had bridges for more than a decade. That was actually one of the core promises of the XMPP protocol, compared to others (like IRC). Both XMPP and matrix have exactly the same promise to be the only and ultimate federated protocol you will ever need, so there's no real distinction on this front.
> without many users or features that appeal to a mass audience
Many people were (are?) unconsciously using Jabber/XMPP on a daily basis. What plagued XMPP is open standards with closed-source implementations: i.e. private companies ripping off the benefits of specifications. There's a ton of fancy new features in the Jabber/XMPP ecosystem, including some unique stuff like federated forging: https://staticadventures.netlib.re/blog/decentralized-forge/
Also chat users care more about GIFs than security.
So the product better be good.
To eliminate the "argh, what server?" step we focus on invites which guide you through the process, and ensure you have an initial contact or group, not an empty contact list.
I tested it on many people while working on it. The vast majority (with no familiarity with XMPP or decentralized systems) were signed up in just a couple of minutes.
Also worth mentioning, when you have privacy in mind, Jabber/XMPP is very easy to join as most operators don't have any problem with Tor users, and Tor support (also other proxies) is well supported in most clients.
This is why it is so important that the devs care about the security and just make it part of the app without needing the user to do anything other than use the app.
https://www.beeperhq.com/