Products vs. Protocols: What Signal got right | Hacker News Reader

Products vs. Protocols: What Signal got right

snikket.org

145 pointsMattJ10089 comments

In the authors table:

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

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

That's exactly how it works, yes.

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 had the exact same experience with the pass phrase. Never could get it to work after spending a couple of hours on it. Gave up and uninstalled.

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.

Even so, the fact that this could cause such confusion is a valid point, and more care need to be taken to differentiate the purpose and situation for each. It's a software problem, not a user problem.

Of course you might agree with this, and i personally find the key and password management quite problematic after using it with a few non technical people.

They should have taken a page out of Bitcoins/Ethereums book and used mnemoic phrases and clearly labelling them as "Recovery key" with big red bold letters everytime you enter it.

yeah, that would definitely help! I find it sad that so many high profile open source projects lack in UI, even though there's a lot of smart people working on them.

Maybe it's a question about prioritizing time for technical features and downgrading the importance of a good UI and onboarding. Since time is limited, but in the case of matrix, I would say UI is just as important as the technical part. If they get more funding, maybe it will change in the future.

This caught me out aswell, when it asked for "recovery key" I assumed it was looking for 12 words, rather than my matrix day-to-day password.

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.

If the the Signal Foundation gets acquired by Facebook, Singal as we know it will soon die.

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.

Agreed. I was only thinking of technical failures :)

Can foundations even be acquired? If they can, isn't that a bit daft?

Foundations, like companies or any organization, are composed of people. People can and do get replaced, corrupted or bored and move on, they can eventually decide to take the organization in a direction unlike what was originally intended. Takes more time and effort than just throwing a pile of money at the founders and shutting it all down, of course.

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"

[0] https://play.google.com/store/apps/details?id=eu.siacs.conve...

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.

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

There is no interoperability between systems that use ideas from Signal Protocol and it is unlikely that there will ever be. There is no published standard. The best you can do is transiterate existing source code. It is a very complicated protocol with lots of state. It requires a server infrastructure to work. To be interoperable clients need access to information on the same server.

The protocol is simply not designed for interoperability...

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

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.

Not sure what you mean by "dead", but what do you use to communicate with colleagues at work?

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 have four messaging clients running on my desktop: Signal, Telegram, WhatsApp & Slack. It's not dead.

How many of those have full functionality? I know that WhatsApp is just a client for the mobile app, without voice and video.

It has voice and video now (marked 'beta' and only for 1-to-1 calls).

But I agree, all of these clients suck in their own way. :(

Signal and Telegram include audio/video functionality on the desktop.

Also, not sure what they do to it (no Electron?), but Telegram feels super fast, really pleasant experience.

The fact that Telegram is a Qt app that looks nice and is lightweight makes it really good; it's just a shame it's centralised.

Almost any other messaging platform is dominated by Electron clients (bar the few very WIP Matrix clients such as Neochat).

Slack is an Electron app. It's basically their website on top of a bundled browser.

I don't know about the others. Are any of them native?

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

That's one of the reasons I like matrix. Real multi-client support within the same account and each client is independent of each other.

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

I know far more people that use discord (on both desktop and mobile) than those that use signal.

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.

I do not share your observation that most people are sitting in front of or close to their personal laptops, and even if they did, I still think the barrier to checking messages would be higher than for their vibrating phone.

But yes, of course a phone client does not preclude a desktop client; it's just that being phone-first forces/nudges people to having it on their phone as well, making it more valuable for everyone they know.

I was careful enough not to say that most people are sitting in front or close to their personal laptops. I said a lot of people most of the time. (And also didn't say personal, but I guess that doesn't matter.)

The point of the laptop is not checking the messages, but typing them. If you're at home, which is where a lot of us are these days, it's pretty easy to open the laptop and save time on typing.

BTW, not sure why I got downvoted. Maybe it wasn't you, we'll see.

But that's exactly the point: if it's not most people, then network effects are already greatly limited. And if those laptops aren't their personal laptops, then the odds of them having a personal messaging client open are even lower. Consider that most people do have their personal phone on them at all times.

My point was exactly that pressuring people to have the client on their phone makes them check the messages more often, because that makes the service more attractive to other users. That, I think, is the reason most popular service are phone-first, even when typing messages is easier on desktop.

(And no, I didn't downvote.)

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.

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.

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

If they can undercut the resource consumption of Matrix then I'm already sold.

>Matrix has bridges connecting it to other apps like Facebook Messenger.

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

/me raises hand.

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.

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

Can you tell me more about this? I'm interested in doing this very thing.

If you're looking for something off-the-shelf, there is https://jmp.chat/ (basically linking a phone number with your XMPP account, works with Snikket).

If you're more into self-hosting, take a look at this route: https://sms4you.xama.nu/

I am using this app: https://f-droid.org/en/packages/eu.droogers.smsmatrix/

You create a login for it, and put your identity into it. When messages come in, it creates a 2-person room with itself and you, and can type your sms responses. MMS's don't work, sadly, but a few people I regularly use it with send .SMIL image attachments that get forwarded.

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

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.

[1]: https://github.com/matrix-org/sydent

> how much database space Synapse took on my server

Yes this is a common problem, and disk/RAM usage is why many hosting cooperatives have dropped matrix support entirely and come back to Jabber/XMPP ecosystem.

I hope lightweight matrix implementations like dendrite can help improve sysadmin experience and lower hardware requirements. Yet it's unclear so far whether a better implementation will solve all problems, given that the whole decentralized chatroom concept necessarily takes more resources than a federated chatroom alla Jabber/IRC.

To be clear, i'm not advocating against decentralized chatrooms. I believe they are very useful for censorship-resilience (which can also be achieved with eg. nomadic identity though not exactly with the same threat model). I just wish decentralized chatrooms weren't the only option so the matrix protocol would be easier to implement and hosting a server wouldn't need gigabytes of RAM for few users.

> figuring out (...) configuration, (...) XEPs (...), clients and spam

It's not that hard to achieve, but information is sparse and hard to discover. That's one of the reasons we have founded recently the joinjabber.org collective to have a platform centered around the UX of end-users and sysadmins of the Jabber/XMPP network. All feedback/critique/contribution is welcome.

XMPP has far better clients (at least on Desktop) available than Matrix for me.

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

So the product better be good.

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.

Good to hear! I haven't tried Snikket, but the more idiot-proof you can make it, the better.

Invites seems overly complicated. Can you make it 1 question? what's your email address?

Then you just sign them up for a server and tell them after the fact, hey look, you are all setup with server SpiffyXMPPServer Tell your friends to contact you at: <full xmpp address here>

Who would be operating that server? For how many people? With which privacy policy and which SLAs? Is it just one server (= centralisation and SPOF) or many servers?

The idea behind Snikket (as I understand it) is more along the lines of having a tech-savvy person in your environment who’ll set up a Snikket instance for you and where they all invite the folks important to them.

That means reduced centralisation while providing a lean user experience. The invites are (especially on android) super low-friction (you are presented with a nearly-complete signup after app install; you only have to enter a username (not a domain name, that’s included in the invite; just a username)).

Thanks to being federated with the entire XMPP ecosystem, it can still interoperate with users who are on Quicksy or any other XMPP service out there, which is nice.

I think an invite-based approach is a good middle-way to avoid encouraging centralisation (think matrix.org, jabber.org, or worse) and keeping the onboarding friction as low as possible.

I didn't say it was easy :) I think you could sign up across a set of servers, whoever is willing to put their server in the list. But you are correct, there are a host of issues, since it's all decentralized. That's the cost of decentralization, but there are solutions. One would be to be put on the list your SLA/privacy policies/etc must meet some min. standards(1) exist 2) be found at a .well-known/ etc. that way the client can easily show them to the curious user.

The problem with just a username, is that's not what you need to converse with ANYONE in XMPP land, you need the full XMPP address, and last I checked, no client makes that easy for you to figure out. The full XMPP address should be easy to find as that's what you actually need. Just a username doesn't work, give up on only a username being all you need, it isn't.

I think doing invites from a tech savvy snikket server instance makes sense FOR THAT USE CASE.

For Tito's Grandma, where Tito & Grandma are not tech savvy people.. that's not easy. Tito gets setup on server Y and Grandma gets setup on server Z, and neither of them can talk to each other because the client only shows the 'username'.

Again, I haven't knowingly used Snikket, but last time I played in XMPP, it was non-trivial, even for a tech savvy person.

That's why Snikket has a focus on easy invites that automate on-boarding and contact creation.

Other parts of the XMPP ecosystem also have easy invites that can be shared via QR code, SMS or any other messenger. Example: https://yax.im/i/#user@example.com or https://conversations.im/i/user@example.com See also https://yaxim.org/blog/2020/01/31/yaxim-0-dot-9-9-fosdem-edi...

neat! It's seems my client doesn't understand these though. YAY for federated protocols! :)

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…

Have you seen beeper?

https://www.beeperhq.com/

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.

"The Ecosystem is Moving" was wrong then and is still wrong today. Abandoning the goal of decentralization and federation for selfish gains is a slippery slope. Those who want to go back to the dark ages of AOL and Compuserve will always find some new excuse why to do so.

Matrix approach seems to be better than XMPP though, because it actually works well in the browser.

XMPP does work well in the browser, you can connect using websocket nowadays, and we have some really good web clients (Converse.js or Movim for instance).

> Matrix (...) actually works well in the browser.

Jabber/XMPP has standardised XMPP over HTTP back in 2014. https://xmpp.org/extensions/xep-0206.html

Arguably clients were not that good at the time, but nowadays there are pretty good web clients. ConverseJS and JSXC focus on chat usecases and implement OMEMO encryption (standard based on Signal protocol). Movim et Salut-à-Toi develop more usecases (social networking, federated forging, etc) though they are less polished at the moment.

It looks like Snikket is trying to pull together the popular opensource implementations of XMPP ecosystem as one product.

It would be a lot easier to tell people to connect to a Snikket server for their Snikket messenger rather than Element messenger to connect to a Matrix server where I've completely lost their attention.

A lot of matrix clients are designing it how you mention.

As an example, the app would be called Snikket and when a user makes an account, they’re on the Snikket matrix server by default. They don’t even know they’re using matrix protocol.

Nice, which clients?

Fluffy Chat, Element, Syphon, etc.

You actually have to go out of your way to customize the server part

A very well written comparison of XMPP and Signal, but one thing that the author seems to overlook is the significance of Signal using phone numbers as user IDs. This is what users have come to expect and what makes Signal a drop-in replacement for WhatsApp.

Seems like the @username identifier seems to be pretty well accepted, and most people would probably prefer that rather than a phone number. Similar to how the mass user base only cares about a domain name rather than an IP address.

You personally my feel that the phone number makes a great user ID, but I'd venture you're old enough to remember knowing people's phone numbers. I am too, but I couldn't tell you any of the phone numbers that I interact with on a daily basis today. In a few more generations, phone numbers may be even less understood by the younger users.

The thing about phone numbers, though, is that you already have a lot of them in your contacts. Centralized apps can leverage that.

Usernames are nice, but you probably don't know whether your dentist uses Discord, or what is their username if they do. With Signal, however, you would probably notice (or be informed) when they sign up.

I'm not a fan of discovery via phone number for privacy reasons, but if that's your thing quicksy.im is doing just that on Jabber/XMPP.

The only anectotal experience I have with Matrix and with XMPP, there is always some message that does not immediately arrive at the recipient on mobile. Signal works just as reliable as WhatsApp in that regards.

This may be because of how push notifications work on those platforms, that is applications have to contact a centralized platform (Google/Apple) to notify users instead of relying on traditional methods.

There are standards in the XMPP ecosystem (XEPs) to do that right though it's not enabled by default on most servers yet (see prosody's mod_{muc_,}cloud_notify).

This looks very similar to the Android eco system suffering from fragmentation. It has become impossible to ensure updates across OEMs and this could be affecting some of the feature work - in the name of compatibility.

With Apple owning the spec and implementation and with no fragmentation, they can move very fast.

As long as there is no authority to mandate certain communication protocols (messaging, email, video) during certification, unified messaging unfortunately will remain a dream.

> It has become impossible to ensure updates across OEMs

This is not entirely true anymore, with Google pushing for Project Treble and Generic System Images. I am angry at them for not worrying about this (or mainline kernel support) in the early days of Android, but the fact is the situation has much improved already.

> As long as there is no authority to mandate certain communication protocols

Established authorities have been using Jabber/XMPP for years (though mostly not free-software solutions), and the french State has recently settled for Matrix's Element who received an extensive security audit for the occasion.

I believe it's also possible to advance an ecosystem without authority. That's what compliance suites/checkers have been doing over the years: TLS testers, DKIM checkers, and more recently in the Jabber/XMPP ecosystem the Conversations and XMPP Compliance Suites have really helped guide the ecosystem forward.

Simply outlining what's done right and what's done wrong for specific usecases helps end-users make a choice in their clients/servers, and guides sysadmins/developers in making things right when they want to.

Reply on news.ycombinator.com