What are the differences between Matrix and Jabber?
Jabber implemented a protocol with similar mechanisms several years ago, with a custom xml protocol which could also pass not only text but also rendezvous data for voip/video calls and whatever else custom data you could codify.
Jabber has native protocol implementations for both clients and servers and can handle a reasonable amount of connections with ease. Clients are available throughout all platforms.
I'm asking this question because I believe the reason Jabber "failed" (read: didn't catch as much as other closed alternatives like WhatsApp) wasn't because of technology hurdles, because it was poised to solve the very same problem Matrix works against - which is 'IM fragmentation', but actually a lack of a proper plan to generate interest with its intended population.
I'd say work on your release plan and make your clients 'tasty' and snappy, because technologically speaking, I believe Jabber has already solved all the technological problems Matrix strives for.... and it sadly wasn't enough.
One use of Matrix is defragmenting IM, and it's true that both XMPP and Matrix can be used to power chat systems.
However, architecturally they really couldn't be more different:
* Matrix's main data primitive is synchronising conversation history within a room - not message passing. In fact, there is no way to just 'send a user a message' in Matrix: instead, you can only synchronise your copy of a room's state and history with someone else's copy of it.
* Matrix rooms are replicated equally over all participating servers - there is no focal point as there is in a XMPP MUC.
* Matrix provides a single monolithic (beta) spec, which compliant clients have to implement (for a given class of clients). There are no optional features or competing extension proposals for a given feature for a given class of client (e.g. 'desktop messenger'), to try to avoid fragmentation.
* Matrix's baseline transport and encoding is super-simple-stupid HTTP+JSON, but with room for folks to propose superior transports & encodings as we see fit. So far there's been WS+JSON (which nobody seems to use, as it's not that massive an improvement over HTTP+JSON), and this year there's a GSoC project to look at MQTT-and-similar as an alternative.
IOW, Matrix is best suited for replacing IRC or Slack, for communication around organized teams/communities or topical conversations with strangers; while Jabber/XMPP is a better Facebook Messenger, WhatsApp, Hangouts or Gadu-Gadu, best for staying in touch with friends and talking in ad-hoc group chats between them.
Plus, XMPP can be used for great amount of stuff non-IM related, while Matrix seems very focused around its IRC-like use case, where XMPP doesn't really improve much over IRC.
> Plus, XMPP can be used for great amount of stuff non-IM related, while Matrix seems very focused around its IRC-like use case
I don't really agree here. While Riot is focused on a IM use of Matrix, Matrix itself is open enough to be usable in any use case requiring a payload to travel from A to B. You could think of Matrix use in IoT, social networks, forums, etc. Some people even made a working PoC of a blog using Matrix, and I heard some others are also working on building a system to bypass information censorship using Matrix as its only back-end.
I don't know XMPP enough to state which spec is wider than the other, but what I know is that Matrix isn't limited by what Riot or other Matrix-based IM clients can do.
Of course you can (ab)use a lot of protocols in various ways, however, XMPP was designed with this extensibility in mind and that's exactly why its basic RFC is so minimal. Heck, even basic instant messaging over XMPP is defined in a separate RFC (RFC 6120 for Core and RFC 6121 for XMPP-IM).
GP already stressed it out:
> Matrix's main data primitive is synchronising conversation history within a room - not message passing.
So Matrix might be well suited for things like blogs, but XMPP will be certainly better for push notifications, for instance. However, you can easily build Matrix-like primitives on top of XMPP, while the other way around will be less flexible.
> In fact, there is no way to just 'send a user a message' in Matrix: instead, you can only synchronise your copy of a room's state and history with someone else's copy of it.
I've read in a different thread that sending a message in Matrix can be easily achieved with a simple curl. Is it true? Synchronizing my copy of room state doesn't sound so simple. Maybe it's optional or I misunderstood the "message via curl" post?
However, what's happening under the hood is that you're not saying "Hi Bob, here's a message from Alice" - instead, you're saying "Hi everyone, I've added a message to the history of this room. Please can everyone sync their copy of the room with mine?". In other words, it's talking about the way the federation (server<->server) protocol is architected.
There literally isn't a way in the federation protocol to say "please send a message from Alice to Bob"; instead the way you do it is to say "create a room and invite Bob to it (if you don't have one already); add a message to the room's history, and once the history has synchronised with Bob's server he'll have a copy of the message too".
So if I understand it correctly the client-to-server API is simple but servers internally build a Git-like structure? Interesting design, I think I'll read the specs for how history is stored.
Seems we now just have to wait for the next generation that's a rip-off of piul[1] rather than git, and we'll be all set!
On a more serious note, this seems to be a trend; to model chat as a converging set of edits. From an architectural pov it sounds similar to Google wave and lotus notes.
I think that main difference is the fact that Jabber has important features (in 2018 year) as an optional extensions. So you have to carefully search for a proper client and server which support those features (and your companion's client AND server should support those features as well). Matrix should have those features in core and any server or client is supposed to support them.
That said, I think that main problem with Jabber is lack of a single entity pushing it. So it'll naturally lose fight against corporation with billion-dollar marketing budgets. With Matrix it might be better.
Sometimes technologies losing or winning for very ackward reasons. I don't believe that Jabber will win, but with Matrix it's possible. We should keep trying.
The thing that concerns me about this is that while Matrix might be a more modern protocol today, it won't be long before the world moves and it requires an upgrade, and extendability has been the killer feature that has helped XMPP survive a long time albeit not to prosper. Unless the problem of convergence is solved this will haunt evolving distributed networks no matter how strongly they start.
Long story short, if you ever try to implement something in XMPP/XEPs, you'll learn the hard way why it never seems to gain any traction. Very, very quickly. There are real technical reasons.
Extensibility is good. I believe the Matrix developers when they say it's extensible. (I've been a user for several years now. Features regularly get added in backwards-compatible and smooth ways.) Extensibility in the way XMPP tried to go about it -- for patching over core inadequacies of the basic protocol -- is not the same beast.
What would really help with XMPP is some idea of profiles - like a Jabber2018 profile that requires all of the XEPs used by Conversations[0]. That way, client and server implementers would know exactly what they need to be compliant with other implementations using the same profile.
They are only part of the solution however because:
- Open-source projects are developed by volunteers, and implement what their users (actually typically their developers) want implemented. Having a document that says "you should implement these things" is good for guidance, but it doesn't magically get them implemented.
- Commercial projects will implement the things that they can get revenue from. Having a document that says "you should implement these things" doesn't magically make those things earn the company money.
E.g. in the open-source category, Pidgin is the classic example of a once-popular client that has fallen behind (with feature requests for some "new" protocol features open on their bug tracker for many many years). The document doesn't fix this part.
But yes, I do agree it's an essential part of solving the problem.
It's still so common to see clients tout a list of supported XEPs like they expect users to know what any of it means. It's great there is a list of importantant XEPs but this must be communicated to users better so that it's easier to find suitable clients. It might even be good to refer to compliant clients as something other than Jabber/XMPP then you can easily search for an "XTalk" (for example) client and know this means the full list of XEPs are supported.
Part of this might include some new XEPs to indicate to users when they are communicating with non-XTalk users so the experience might differ.
A certification programme even might help motivate devs to meet compliance quickly.
I doubt any platform uses vanilla XMPP, that wouldn't be sane, but like using XML, XMPP is a relic of its era. Whose to say what super-critical "how can you not have this as standard!?!" feature won't come up in the next 5 years that Matrix devs hadn't even known of in 2018. That doesn't mean we should flip over the table and start again every now and again and hope the users will follow, this is why extensibility is an important part of the recipe and make ways to ensure the standards of the day are always implemented before being considered ready for prime time.
It also does not and never did support consistent history or multi-device.
And it never will, because having some way to identify a message is a prerequisite for even phrasing the question "does device_foo have message_x synced yet?"
Bouncers don't count. They reintroduce centralization as a way to solve the problem. It's a solution, of a sort, but it's a fairly poor one if your original aim was decentralization.
And "working fine" is also frankly a bit of a stretch, isn't it? I can't count how many times I've seen a "netsplit" in freenode or the other IRC networks. That means messages aren't delivered. It's so common we have a word for it: "netsplit".
I shouldn't dunk on IRC too much, because at least it's honest about itself for being simple, and there's a virtue in that. But if we were to construct a statement like "IRC manages reliable message delivery without any concept of message IDs", then that would be false (or technically, vacuous), because it doesn't manage reliable message delivery.
I don't think you get the idea of extensions in XMPP. If something is published as a XEP, it doesn't mean "it's a completely optional thing you can ignore". It does mean "it's a thing that might not be useful in some cases, so it doesn't belong to the core that everyone and their pets must implement".
If you build an IM client for XMPP (which is just one of the use cases of XMPP), you absolutely have to implement at least a few of those extensions in order to have basic functionality. Heck, there's even a separate RFC for XMPP-IM on top of the XMPP-Core RFC. That's expected, by design and very fine.
Of course, what's considered "basic" changes over time and it's easy to find outdated clients out there. That's why Compliance Profiles exist, so you can look around for clients that implement, for instance, 2018 desktop IM profile. It also imposes some burden on new implementations to consider backwards compatibility with those clients. No solution is perfect, but while I think Matrix' way allows them to move forward faster now, in the long term it's probably XMPP that will age more gracefully.
> I don't think you get the idea of extensions in XMPP
I don't think you read the other comments I linked to. My fault for not copy-pasting the entire thing every time the "y u not be exactly XMPP" train comes on HN again...
---
> - unique message IDs? Absent. XEPs kind of provide; but I can't tell you which of the three or for relevant ones are the most relevant (AMP IDs from XEP 0079? Stream Management from XEP 0198? Acking from XEP 0184? Something from Carbons or MAM in 0313 or 0280? You know, if you wanted some light reading...).
> - multi device? Oh. My. God. It's bananas. The spec behavior is that whenever a client sends a message, the server is supposed to consider that one the most alive, and then route all future messages exclusively to that one. So you send a message on your phone? Yeah, your desktop is just going to silently stop receiving messages.
> - there's a concept of "message carbons" to deal with this. This involves re-sending all your messages back to the server after you receive them, with special instructions to send them back again to your other clients. The amount of redundantly redundant XML involved is eyewatering.
> Combine that multidevice behavior (messages can get randomly routed anywhere at any time) with the wild-west nature of message delivery acks, and you can see how ridiculously difficult this makes the basic idea of "all clients should see the same picture".
> Overall, the XEP process, conceptually, is a great example of open extensibility. The trouble is, so much of this stuff is core to sane message delivery semantics that it really, practically speaking, causes huge problems when it's all considered "extensions". Stuff like message IDs fundamentally shouldn't be an extension because it's just too critical that all minimum-viable clients agree. You just can't build higher level stuff without that. XEPs are great. A community process for extensions should exist. It just needs to exist for extensions, not subsume the total set of realistic minimum viable features.
(All of this is a shameless repost from https://news.ycombinator.com/item?id=9772968 ; please forgive my humble attempt to save the dear reader from the need to traverse any links.)
---
I get the idea of extensions in XMPP. I have tried to implement them. It is based on this first-hand experience that I am now arguing that the XEPs are a swamp. It is time to move on.
Yes, even with Compliance Profiles. It's too late. The horses have left the barn, developed tools, formed their own complex civilizations, invented light speed travel, and in fact left the galaxy. That's how far out of the barn they are.
Message ID and multi-device messaging is in fact fundamentally broken in such a unique, fascinating way in XMPP that all other clients will cease to operate correctly in the presence of a single bad client.
That's right. Any bad client can cause other clients which are following the spec to the letter to begin to drop messages, forward them incorrectly, and generally lose history and form desynchronized views of the world. I'm not kidding. If you haven't read the XEPs, and don't believe me, go read the XEPs. The only way to implement a reasonably correct multi-device behavior requires ignoring significant parts of XMPP because it is wrong.
Guess what: I was implementing (at least some of) them too, successfully.
> but I can't tell you which of the three or for relevant ones are the most relevant
I can. Check out XEP-0359. MAM and some other XEPs depend on it.
Also, unique message IDs are not a feature. They are means to provide some feature. You will deal with different kinds of IDs when trying to ensure network reliability (0198) or when trying to implement read markers and delivery receipts (0333, 0184). Without telling us what feature would you like to implement (threading? attachments? something like 0367?) just spewing all different kinds of IDs from various XEPs starts to look like a FUD to confuse uninformed reader.
> multi device? Oh. My. God. It's bananas.
I can agree with opinion that the protocol is really "bananas", but it works. Basically 0280 solves this issue, especially when combined with 0198 and 0313 - the only situation where it breaks is if you connect with a legacy client that doesn't support carbons and set it a presence with higher priority than any other client. You'll still get the content of the messages on modern clients thanks to MAM though. So, basically, don't use legacy clients on your account, cause they will degrade your overall experience. Doesn't seem very surprising, especially given that you can't connect at all to most IM networks out there using outdated clients. My N900 with stock OS won't connect to Skype or Facebook at all, even though it tells me it can. It will to XMPP - with limited functionality, but it's better than nothing.
XMPP accumulated its great share of backwards compatibility weirdness, but it doesn't seem unmanageable and I believe that the way XEPs are handled made it better, not worse. I suspect that Matrix might be in worse shape when it reaches current age of XMPP. I would like to be wrong though, I wish them best.
So basically you reiterate what I said. And specifically:
> So, basically, don't use legacy clients on your account, cause they will degrade your overall experience.
Yes. As I said.
But let's not put a bouquet of roses on it: it's even worse than that, because you don't just have a degraded experience when using a legacy client. Using a "legacy client" -- of which there are many because of the XEP swamp -- will make all other clients behave wrong. And it is impossible[1] to tell which client (or server) to blame. Thus resulting in even the most modern and chose-the-right-XEPs clients regularly getting bug reports about lost messages... even if some other client is at fault.
If that's not a trainwreck I don't know what is.
---
[1] inb4: nothing is "impossible". But "practically speaking impossible for an end user who has other things to get done today and a limited time budget for debugging a problem which is a $n$-dimensional matrix of their clients and servers in use", yes.
I briefly worked on an XMPP client for an internal chat app. I ran into tons of issues (multi device problems being the main one I recall. This was over 5 years ago now.) It would've been simpler to build my own client and server with a custom protocol.
Someone else really wanted to build on XMPP though. XMPP has fundamental issues. No thanks.
Matrix is very extensible too; it's just that we aim to merge extensions as rapidly as possible into the core monolithic spec, rather than having them get fragmented into optional extensions.
I wonder what happens when there's 10 implementations of the matrix spec controlled by different groups. Being able to indicate where the implementation gap is seems like a strength rather than a weakness.
Hm, even when there are 10 different server implementations (or the ~50 client implementations there are today), we’d hope they would align to the same spec - just as with HTTP, SMTP, TCP/IP etc. There’s room for experimentation without introducing fragmentation, and any useful experiments would hopefully rapidly get merged into the spec. And if they don’t then yes, you risk a fork on that particular feature (the equivalent of only Exchange supporting email recalls, or browser vendor extensions), but it’s not the end of the world.
it really depends, if the features are difficult to implement it may not be very quick at all, we see this with XMPP often where features take years to implement or never appear. If a homeserver targets a particular use-case then they may actively choose to ignore certain features that are not relevent. Really when people talk about the flaws of XMPP they often have in mind the problems of private e2e encrypted chat on mobile which is a hard problem to crack, but there's many more private servers inside organisations that don't even federate and work fine for how they are used. This flexibility perhaps makes it better to view XMPP as a toolkit for building networks out of, similar to how IRC networks which have a converged set of servers but outside that network all bets are off. The idea of viewing XMPP as a single network inevitably causes it to look fragmented but there are pockets within the network that interoperate just fine they just don't identify themselves as a group.
>Bridging to other protocols and defragmenting existing communication apps and networks is very much a second class citizen feature
Not sure what this means. XMPP gateways have been around forever, tend to actually work and are completely standardized with a specification and everything. The reason you don't hear more about them is because there is nothing much to gateway to any more. All the other IM systems have managed to close off their gardens to such an extent that gateways are pointless...
I guess that raises an obvious question. Is there an XMPP gateway to Matrix? I know there are some projects that are about gatewaying from Matrix to XMPP. One potential complication is that Matrix isn't an IM network as such, it is more of a IRC like distributed conference. There is a XMPP to IRC gateway, so it must be possible at some level...
It does exist, via libpurple. I think it was one of the first bridges. It is not currently maintained, AFAICT due to lack of general interest. Telegram, IRC, discord, slack, gitter etc. bridges are actively maintained, for comparison.
on xmpp clients:
"Baseline feature set is so minimal that fragmentation of features between clients and servers is common, especially as interoperability profiles for features have fallen behind (as of July 2015)"
Indeed, there are a large number of people still using Jabber/XMPP today with "popular" clients like Pidgin or Adium that haven't stayed up to date with modern advancements in messaging.
It leads many people to believe that XMPP is incapable of many of the features that are considered normal in modern messaging applications.
A hard break in the protocol would solve it (i.e. so old clients would no longer be able to communicate with new clients), but it would also frustrate and fragment the significant existing userbase. Given that open decentralized standards-based networks are something to be treasured if we're to stem the tide of proprietary walled-garden messengers, that option would potentially be shooting the open movement in the foot.
...and outdated, as it's 2018 now and XEP-0387 exists.
Actually, most of this FAQ is severely outdated, XMPP already catched-up in most of these points. Some clients are lagging, sure, but that's just a matter of time for Matrix to suffer from the same issue.
Is there an up to date wiki/guide of a subset of features and implementations that go well together for modern xmpp?
As in these mobile clients for ios and Android, these for desktop and these for cli. With these servers - Together give you in-band registration, ssl-only client/server and server/server, maybe audio/video, file-sharing, server-side history - e2e encryption (I'd settle for otr) - and sane defaults for each client and server to make it difficult to accidentally disable encryption or certificate validation?
Honest question - last time I looked I couldn't find a simple&secure, recommend setup for xmpp.
A thing I often see is people pointing to specifications and saying "look it's all fixed".
But you can't chat using a piece of digital paper. What matters not is what the protocol can theoretically do, but the experience you can have if you open a client right now.
That point that needed "fixing" was specifically about lack of specification... plus there are multiple clients and servers already implementing this spec.
It is nice to see Matrix in HN: this project needs more visibility.
In a world dominated by Slack, which removes privacy/history control from users and place walls, Matrix is the promise to have a better open scenario than IRC was.
I am crossing my fingers. I hope with all my heart to this technology to flourish.
- work on stability: the status quo is unreliable. Until this is solved it's hard to recommend Matrix to anybody who is looking to use it for serious work
- disable signup on main server: this is a decentralized netword and the main server is overloaded already. It is overloaded so badly, that devs decided to turn off presence for as long as I can remember first seeing matrix. So even IRC is more usable in that regard because I know when I see a user they are online or they even have presence and an away message
There's more but those are two issues I think should be dealt with urgently.
You bring up a good point about disabling signup on the main server.
I've recently been wondering why the Matrix team wouldn't want to lose some of the control they have over the Matrix universe..
They could solve their scalability problem by bringing up other homeservers (why not a paid riot.im server even?) or promoting other open servers hosted by the community.
Seems like Mastodon folks are favoring horizontal scalability by making people use various servers, but the Matrix team wants to keep mostly everyone on matrix.org.
(I hope this doesn't sound too negative.. I know it's not like Matrix folks want to centralize things.. It's just, I wonder why they don't promote other homeservers more)
The reason we haven't disabled signup is to try to provide a server which we can point people to over which we have some level of control and quality (even if that quality is pretty crap right now).
Once we have account migration sorted out (hopefully coming sooner than expected thanks to work being done for GDPR), then the situation should be much better as folks can flee off the overloaded server onto one of their choice... but first-time newbies don't need to make the complicated and confusing call on picking an alt server.
GP brings up an interesting point, though - couldn't you run multiple smaller homeservers rather than one huge one? I suppose it depends on how much of a challenge that is operationally, but Matrix federation as a whole seems to scale much better than individual homeservers do at this point.
(Users who have already signed up on the matrix.org HS are stuck there until account migration is a thing, of course.)
Splitting matrix.org into smaller homeservers wouldn't necessarily help (even if we had account migration), as you'd just end up switching client<->server traffic for server<->server traffic. As New Vector (the startup we setup to support Matrix) we're also working on providing a homeservers-as-a-service though which should help.
That's of course true for the massive rooms, such as #matrix:matrix.org, but if there are enough 1:1 conversations to contribute significantly to the overloadedness of matrix.org splitting the servers up and 'randomly' assigning a server to users would decrease the load.
The problem is that the 1:1 conversations are a negligible weight relative to the massive 15,000 user rooms like #matrix:matrix.org - and spreading those 15,000 users over 15,000 servers rather than 1000 is going to just swap a client<->server API overload problem with an server<->server API overload...
Do you know what exactly the bottleneck is on Synapse? Is it syncing everything to users, or the actual room processing? I wonder how much of an impact JSON (de)serialization has, assuming you don't cache serialized requests.
We do. The main bottleneck is merge resolution when unifying your copy of your room with everyone else’s. If the room starts to fragment due to netsplits or unreliable servers then this can get incredibly resource intensive. https://github.com/matrix-org/synapse/pull/3122 is the fix which switches the algorithm from roughly O(N) to O(1).
For context, a typical synapse actually only uses around 300MB of RAM. It only spikes up to 1-2GB when trying to resolve state on big rooms like Matrix HQ, and then python doesn’t relinquish the RAM.
We do cache responses in JSON to avoid serialisation overheads.
Am I reading this right that this is the algorithmic fix, but it still needs a concrete implementation - and then the main server should be back down to "vertically scalable"?
Without going and reading the doc(yet); does this relate to:?
It would seem that a simpler, deterministic merge algo would be possible to parallelize - but I'm not sure if it's easy to match matrix idea of merges with what's discussed in that post/paper?
The algorithm is already being implemented in synapse (but got delayed by dealing with some security bugs). There's also a rust test jig for playing with algorithms around merge resolution at https://github.com/erikjohnston/rust-matrix-state/.
It's not directly related to the Categorical Theory of Patches paper - the merge resolution here is much simpler than reasoning about VCS patches, although the approach of taking a formal mathematical approach is similar :)
I'm on the public Matrix.org server and I recommend new folks to sign up on the public server unless they're 100% sure they're willing to commit to the devops burden of maintaining their own homeserver.
I also know at least a halfdozen people who immediately said "yes" to the devops burden of maintaining their own homeserver (and reportedly, it's actually really easy).
Different strokes for different folks. If self-hosting it was a pre-req for using it, I'd still be saying to myself "yeah, I'll do that riiiight after I get my closet k8s cluster just the way I want it", and, well, I know myself better than that, so I use the public one, and I'm happy.
Mastodon gets away with just telling people to go find a server to register with, you don’t have to self host to get some reasonable level of decentralisation.
Stability should be okay if you're not on a massively overloaded server, but it's very much something that we're working on alongside performance - in order to try to get out of beta as soon as possible (as well as support massive deployments for folks like the French Government). https://news.ycombinator.com/item?id=17031626 is a list of stuff we're doing to address it atm.
That and working on bridges. Some people suggest that bridges solve the problem of onboarding but the quality of the bridges has been abysmal last I checked, the only one that is somewhat maintained being the IRC bridge and even that having some problems (like showing users online even if they aren't)
The main guy working on bridges left during the funding crisis we had last year, unfortunately. Luckily we have new people joining in May to work as their day-job on it. The IRC bridge should never show users in a room who aren't currently joined online on IRC (other than when it's recovering from a crash).
The most popular OS is Windows. And Qt is not a native client, at least for Windows. Something modern built with UWP would be nice. Second popular OS is macOS. And native for macOS is Cocoa.
PS not requiring anything, just my 2 cents. I, personally, like Riot.
Last time I checked, Qt still used completely its own rendering, input handling, etc, imitating platform. So it's conceptually not different from, e.g. Java Swing. Probably imitation is better.
That said, Windows is bad at UX consistency. Native used to mean WinAPI with built-in window classes handling input, buttons, etc (and wrappers like MFC or Windows Forms). Then it was WPF with its own DirectX-based stack. Now it's UWP with even different code. I guess, Qt is not the worst solution. macOS is much more coherent ecosystem when it comes to native.
So it's true that Qt may not be perfect at mimicking native Windows UI, but in practice people don't seem to care too much for apps if the end result is still ergonomic & responsive and integrates nicely with the overall OS (unlike Swing or XUL). And Qt seems to do that quite well. In practice, I'm not sure anyone would even want a mIRC-style pure-windows UI Matrix client...
Does E2E work now? Last time I tried, it did not. That was some time ago so things might have changed. It still is listed as "working on it" for many clients though.
To develop a new communication platform today without E2E as a core functionality is odd.
for Riot, it still is not enabled by default due to bugs though?
> As of May 2017 Riot’s end-to-end encryption is technically in beta, but this is due to some residual stability bugs and missing usability features. Once these are resolved we plan to get the full implementation security assessed and out of beta. End-to-end encryption will then be turned on by default for private conversations.
I really would like to have a single chat client. I have friends/business partners on Skype, WhatsApp, FB Messenger, iMessage, Discord, Slack and (ze horror)MS Teams.
I wish I had a single app, be it on desktop and mobile, to use, with the combined feature set of all of those (filtered down to whatever my communication partner supports).
I know: how dare I dream of such a magnificent beast?
I'd say they're quite high because not being "yet another IM thing" but rather becoming the way to bring all comms togeter is one of Matrix's core missions.
Of course it's not there yet, though it's quite likely to get there in the future.
"
Tox.chat looks to be a very cool clone of Skype - a fully decentralised peer-to-peer network. Matrix is deliberately not a ‘pure’ peer-to-peer system; instead each user has a well-defined homeserver which stores his data and that he can depend upon.
"
What's the rationale behind "impure" decentralizing? Why not go fully decentralized like Tox does?
Battery usage, network utilisation, complexity of implementing clients, and wanting a more guaranteed home for your data than having it smeared over endpoints.
That said we will hopefully move to a more hybrid model in time.
Can someone point me to a good comparison of Matrix, Mattermost, Zulip, Rocketchat, IRC and XMPP (say, Prosody) or explain what niche each fills if they are not competing.
Assuming for a small company with a dozen employees, all of whom sometimes work remotely.
Let me take a crack at it. This is highly opinionated and probably biased.
IRC is reliable, can be forced into encrypted client-server communications, and has the fewest client-side features. The strength is the number of available clients and the primacy of channels (rooms). File-sharing is available but not a focus. There are lots of bot libraries.
XMPP is reliable, the server can mandate client-server encryption, and has some client-side features including simultaneous appearances (being one person logged in through several devices) and better one-to-one chat than IRC. File-sharing is an optional add-on. There is no good iOS client that I know of; mobile clients tend to be bad at requesting history.
Mattermost, Zulip and Rocketchat I have the least experience with; they all seem to be very popular with small groups of users but are complex to install and have very few clients.
Matrix is promising. It does one-to-one and chat rooms smoothly, server config is pretty easy, and you can have the server mandate client-server encryption. There are lots of clients that all seem to be in mid-alpha development. If it survives a year or two, I think it will be widely adopted.
> XMPP is reliable, the server can mandate client-server encryption, and has some client-side features including simultaneous appearances (being one person logged in through several devices) and better one-to-one chat than IRC. File-sharing is an optional add-on. There is no good iOS client that I know of; mobile clients tend to be bad at requesting history.
ChatSecure works on iOS and has history fetching features (MAM), for Android there is Conversations.im, IMHO the best XMPP client to date.
> Mattermost, Zulip and Rocketchat I have the least experience with; they all seem to be very popular with small groups of users but are complex to install and have very few clients.
At least for Mattermost I have to disagree with the "complex to install". All you need is a sql database (MySQL/MariaDB or Postgres), for production you then also should put a reverse proxy in front.
With "very few clients" you are referring to client software, correct?
History has always been a major concern for me with IRC and XMPP. IRC has no support (though I think there's an upcoming standard that does), and my (admittedly several years old) experiences with XMPP weren't good in that regard either.
I work on Zulip, so will only attempt an answer for that. Zulip is designed to scale team chat past when you're getting 1-200 messages a day.
With an IRC- or Slack-like communication model, waking up to 100+ new messages every morning is a big drain on time and energy. Also, once a channel starts getting 100+ messages a day, it stops being useful for real communication. If someone starts a conversation at 10am, and you come by after lunch, it's hard to respond in context.
You can see how Zulip solves this problem on the Zulip community server, https://chat.zulip.org (send test messages to "#test here", follow the code of conduct, etc., it's a live server). Feel free to PM me there if you set things up and have any questions/feedback.
To address a previous post: Zulip, Mattermost, and Rocket.chat all take about 5 minutes to install, so I wouldn't worry too much about that. Zulip and Rocket.chat also come with SaaS versions if you don't want to run your own infrastructure.
Last I looked, only rocket.chat had a sane, minimal docker-compose setup that worked for getting started. I'm not thrilled about the mongodb dependency - but my overall impression of rocket.chat was very good. And the rest api is well documented and easy to work with.
It may be that zulip has "scaled down" a bit now - when I looked, it seemed you got the complexity of serving 10k users even if you only had 100s.
(Not meant as a dig at zulip, I think it's awesome that the project was made open source!)
Is this project affecting by the pgp sMIME issues in the news recently?
(starting to learn this matrix thing, thanks in part to this nice synopsis posted in the article)
Jabber implemented a protocol with similar mechanisms several years ago, with a custom xml protocol which could also pass not only text but also rendezvous data for voip/video calls and whatever else custom data you could codify.
Jabber has native protocol implementations for both clients and servers and can handle a reasonable amount of connections with ease. Clients are available throughout all platforms.
I'm asking this question because I believe the reason Jabber "failed" (read: didn't catch as much as other closed alternatives like WhatsApp) wasn't because of technology hurdles, because it was poised to solve the very same problem Matrix works against - which is 'IM fragmentation', but actually a lack of a proper plan to generate interest with its intended population.
I'd say work on your release plan and make your clients 'tasty' and snappy, because technologically speaking, I believe Jabber has already solved all the technological problems Matrix strives for.... and it sadly wasn't enough.