60 million in the Matrix as users seek decentralized messaging

The decentralized Matrix network has crashed through the 60 million user mark with user growth rate exceeding 70 percent in 2021, according to the company behind the messaging service. It's impressive stuff, although definitive figures are tricky to ascertain thanks to the decentralized nature of the platform. Element boss …

[Hubert Cumberdale]

"fed up with Teams"?

Yes. Extremely. I have to work with a client that uses the whole MS shebang, and I find myself constantly irritated by how Teams is not as intuitive/seamless/good as Zoom in most respects yet it somehow manages to be a massive and unwieldy bloated application at the same time.

[Anonymous Coward]

I didn't find Zoom that much fun either but Teams via the Web interface was bearable for a basic meeting.

As an aside wasn't Skype originally decentralised to some extent.....

[MatthewSt]

Technically Skype was "distributed" rather than "decentralised". Was still more reliable than any of today's systems!

[Anonymous Coward]

Decentralized, yes. Open, no.

It was also funded and built by a web of shady holding companies using laundered money from piracy. The same Estonian hackers that built the Kazaa "file trading network" built it on the same architecture.

Big surprise then that AFTER they sold it to M$, they turned around and sued the company they just sold it to for infringement. Pirates. Sharp coders, but bloody pirates.

So yeah, as big a deal as Skype was during it's heyday, I trust an actually open project much more.

[EnviableOne]

Teams is "Included" in the solutions businesses already pay for.

Zoom, Webex, Chime, Meet, etc cost on top of that.

Teams like all things Microsoft is full of holes and bloat and its update mechanism looks like an ATP maintaining persistence, but you get what you pay for.

at least its vaguely useable has caught up with most of the features of the easier-to-use systems, doesn't make claims that it has security that it doesn't, and is bringing online new features too...

Basically Teams is here to stay, so you are going to have to get used to it

[Anonymous Coward]

Using software is just like being a freaking smack junkie!

Companies cutting costs and MS make their software, when bought in sufficient numbers, very cost effective. We're dumping tons of useful apps like Skype, Siebel, etc in my shop in favour of MS across the board due to the cut price deals.

MS kit is barely usable but like any good drug dealer, the more you buy, the more you're hooked and as a favour they cut you good customer discount to get you hooked until you have everything they offer, then the costs start going up as they know you can't leave 'em 'cos cold turkey is very, very painful!

[Michael Wojcik]

I've been working on geographically-distributed (intercontinental) teams since the late '90s, and we've gone through a number of conferencing mechanisms. POTS conference calls, VoIP conference calls, Polycom PVS, Bridgit, Skype, Lync / SfB, Fuze, and now Teams. For non-team work I've used WebEx, GoToMeeting / GoToWebinar (ugh), Amazon Chime, probably others I'm forgetting. Outside work I've on occasion used Zoom, Facetime, and FB Messenger (on other people's computers).

For videoconferencing, Teams has been a bit more reliable than some of the alternatives (Fuze was awful at my end, for example), and its UI / UIM isn't as daft as, say, GTM's. (Learn how to set the z-order properly, GTM devs.) But it's a ghastly resource hog, responsiveness on the controls is poor, and it's full of misfeatures that you can't disable, particularly in the text editor. And like anything using Sharepoint as a back end, it uses Sharepoint – the worst information storage system ever devised – as a back end. (Sharepoint motto: "Everything else about is so terrible you'll hardly notice the absurd URLs!")

As a videoconferencing system, Teams is certainly no better than Bridgit, for example, was. As a chat system, it's far inferior to RocketChat, which we used before IT crammed Teams down our throats. None of the integration features are compelling or even particularly interesting, as far as I'm concerned.

But as others have pointed out, going Full Microsoft looks good to IT and the beancounters, so that's what happens.

[Captain Hogwash]

I tried running my own Matrix server

It works but it's slow and I really can't see what it offers that XMPP doesn't. People will no doubt point to bridges but my understanding is that they still require accounts on the "foreign" services so a non-starter for me. I expect other members of the commentariat to re-educate me and I welcome it.

[Anonymous Coward]

Re: I tried running my own Matrix server

> I really can't see what it offers that XMPP doesn't.

A marketing budget.

> People will no doubt point to bridges

Known as transports, it was one of the early selling points of XMPP back in 2000. It's dead easy to write one to bridge not just to other chat services but to almost anything else imaginable.

> but my understanding is that they still require accounts on the "foreign" services so a non-starter for me.

Yes there's no magic there. For truly federated services such as email and telephone you can make the integration more seamless, without requiring an account on each service, by using the clever approach implemented (in XMPP) by Cheogram.

[Captain Hogwash]

Re: It's dead easy to write one ... to almost anything else imaginable.

Could you point me to any resources which would help me do this or any that have already been done?

[Anonymous Coward]

Re: It's dead easy to write one ... to almost anything else imaginable.

Of course! The specification is XEP-0114.

Cheogram is basically built on the basis of components.

A search on your favourite web crawler or code forge for terms such as "XMPP component", "XMPP transport" or "XMPP gateway" will reveal various examples of XEP-0114 in action.

[Anonymous Coward]

Re: It's dead easy to write one ... to almost anything else imaginable.

What XEP-0114 basically does is delegate authority for an entity, e.g., given an XMPP server example.net, the JID (Jabber ID) my_component.example.net could be delegated to a component, which is simply a separate processes that connects to the XMPP server and handles that part of the namespace.

To give an example, a fictitious component weather.example.com could provide weather forecast alerts. You could then subscribe to ("befriend" in millennial terminology) say [e-mail] and receive weather notifications for the French city. Or even to something like [e-mail].

In this sense, components are neither bots nor simple bridges but something rather more powerful.

[Greybearded old scrote]

Did I miss it?

I couldn't find the most obvious linky.

In the past I've been interested in Tox for the same reasons, but their use of Etherium for a directory would have been an issue.

[3arn0wl]

Re: Tox

I haven't looked at it in a long time, but I understood Tox to be P2P without any intermediary...

[Anonymous Coward]

Re: Tox

Yes, Tox is distributed as opposed to decentralised. So both parties have to be online at the same time to send messages, unless the client is set up to hold messages until the other party reconnects.

[NATTtrash]

Re: Tox

Same thing here. I used it a couple of times in the past when it first popped up, and it was rough around the edges, but worked OK. This was (I think) on 16.04 LTS, so about 5-6 years ago. Then internal ripples in the dev team happened and, as more frequent with these kind of endeavors, everything stagnated into a non-functioning quarreling hole. Also I remember that there were some security issues with the toxcore, which by now seem to have been solved. After that, for some time it just sat out there, probably not picked up by the fact that the devs just dumped the code out there, not really facilitating "lower-level-easy-to-install" options. Recently, installing 22.04 LTS for somebody, I saw that it is now in the *buntu base repo. Haven't tried it yet though.

I haven't looked at it in a long time, but I understood Tox to be P2P without any intermediary...

Yes, that is the nice thing about it. However, as so often, a great idea doesn't always give perfect code. Especially when there is "nothing in it" for somebody. Let's be honest, that's why we have all those MITM subscription services, right?

[FrederikSchack]

Not ready for prime time

I've tried various alternatives to Telegram, XMPP clients and Matrix clients, non of them are ready for prime time.

I'll bet that the vast majority of those 60 million "users" are deeply frustrated with Facebook and Google and have tried Matrix, but are mostly inactive.

[FrederikSchack]

One big issue that Matrix, Jami, XMPP, Signal e.t.c. don't handle well is notifications. Signal can work well if it has Google Services Framework available, but then we're still hooked on Google, so that's not really a path forward.

[EnviableOne]

Signal + google

might as well use the Signal + Meta integration known to others as "WhatsApp"

[Captain Hogwash]

Re: Signal + google

You cannot be serious!

[Anonymous Coward]

Re: Signal + google

He's spot on. There's no significant technological difference other than signal has been seen to perform poorly at scale and that it doesn't use Facebook's infrastructure. It uses Amazon's. :)

[Captain Hogwash]

Re: Signal + google

Look at the difference between the data collected by the two apps. Signal wins hands down. Whatever Google or Amazon gets is not tied to any identity.

[Anonymous Coward]

Re: Signal + google

> Look at the difference between the data collected by the two apps.

As far as I can tell it's essentially the same and just one of the items being sent is all that is needed to know exactly who you are and who you're talking with.

Both applications are easily interceptable (and intercepted) by any of a number of solutions available to an increasingly wide selection of people (of which Pegasus is the most well known).

The only real difference for those of us in the EU is that, as Facebook have a presence here, we have some (very limited) legal remedy.

I don't use either but if I had to choose (which I don't) I'd take WhatsApp, not something from the creator of Google sharing (don't give your data to them, give it to me) and the guy who went on a little tirade against F-Droid when someone pointed out that his "secure" application was in fact dumping every message, in plain text, to Android's logcat.

[Dan 55]

Re: Signal + google

WhatsApp has copies of your contact cards, Signal uses an md5sum (or similar) of phone numbers.

[Anonymous Coward]

Re: Signal + google

> Signal uses an md5sum (or similar) of phone numbers.

I expected someone was going to parrot that.

The net result, and forgive me for pointing out the bleeding obvious, is that the company running the service still have a complete graph of every one of their users and many non-users.

While hashing phone numbers is good practice from a privacy point of view (and I'm not sure WhatsApp don't do it), the net result is that those are still correlatable to the actual numbers. Which is the whole point of that data being collected in the first place.

Also note that the reason they use to justify doing this is pants. You could just run the discovery query without storing the data off-device, like Quicksy does.

[Dan 55]

Re: Signal + google

While hashing phone numbers is good practice from a privacy point of view (and I'm not sure WhatsApp don't do it)

If you use the option in WhatsApp to download your GDPR data it includes the list of contact phone numbers.

[Anonymous Coward]

Re: Signal + google

> it includes the list of contact phone numbers.

Does it say under what legal basis they keep that data and for what purpose?

It seems dubious compliance wise, to say the least.

I don't use Facebook services or any proprietary or walled garden communication tools aside from the telephone network so I can't check myself.

[Dan 55]

Re: Signal + google

No idea, it's just a zip file.

In the online help it's clear that WhatsApp (the organisation) supply no contact management tools and put the onus on the user to somehow limit the number of contacts that WhatsApp (the app) sees using unspecified methods.

[Mark 124]

Re: Signal + google

Signal used to do that, but the number of possible phone numbers is low enough compared to compute power today that they gave up and just store the actual numbers on their servers.

Where Signal differ massively from WhatsApp, as I understand, is that they encrypt everything in your messages. WhatsApp servers can see, or at least store permanently, the content of pictures etc - everything that's not text.

And they *may* have a user graph, but as a charitable entity they aren't going to be able to sell it

[Anonymous Coward]

> One big issue that Matrix, Jami, XMPP, Signal e.t.c. don't handle well is notifications

Either everyone else is wrong or Google's proprietary approach to the issue is flawed.

[3arn0wl]

Anecdotal, but...

I've used Krille's excellent Matrix client, Fluffychat, on UBPorts' Ubuntu Touch (on a Nexus5) extensively for quite a while, and never had any issue with notifications.

One thing that did used to happen occasionally, was that a server would go down... so I kept a username on 2 servers : 60 million users won't be 60 million users if everyone else does the same!

There is, somewhere, a debate about the relative merits of the somewhat similar Matrix and XMPP services. I guess, if I wanted to use either now, it would come down to which is the easier to set up a server for.

[Anonymous Coward]

Re: Anecdotal, but...

> the somewhat similar Matrix and XMPP services.

Not really similar. When it first came out, matrix aimed to be an eventually consistent distributed data store. Chat was kind of a "showcase application", but then it stuck, they saw the potential and started marketing it as a chat tool.

> I guess, if I wanted to use either now, it would come down to which is the easier to set up a server for.

XMPP without a doubt. Performance is way better and resource usage orders of magnitude lower. You can google stats from the many people who have tried both.

[steelpillow]

What I'd like to see

is a way of making a call where you just click your contact, a temporary room is then opened, they are invited to join and afterwards the room is shut down. During the call, others may be invited and anybody including the originators may leave. Voice/text/video each work seamlessly according to your individual client options.

Would also be cool for the odd server to have a POTS connection so that ordinary landline users can call in and dial up the desired contact's and/or room's extension.

Apologies for the ramble, I must have used too many crap services for too long.

[Captain Hogwash]

Re: What I'd like to see

I also have a Jitsi server, PBX and SIP accounts, so all of the components are there. I just need some vision from the Jitsi client developers to make all of that happen.

[skeptical i]

Re: What I'd like to see

I was just going to say that Jitsi ticks most, if not all, of Steelpillow's boxes. However, I'm not a daily "power user" and while it works just ducky for me, YMMV.

[Anonymous Coward]

Re: What I'd like to see

You hit the nail on the head.

The last thing I want is to try to reach someone who then has to have an account with some service or has to download specific software. I want it to be as easy as group chats or group calls on my phone. I'd like it to handle video but that is much less significant to me.

[Anonymous Coward]

XKCD hit the nail on the head as always.

The solution to problems with communications protocols isn't to spawn an endless chain of new clients and protocols. Sadly, the solution is also not to put up with the crap we are using now. So the two things we as a whole always do make the problem worse.

The only strategy that avoids the twin pitfalls is 1) stop using crap messaging platforms. If it's run by an evil empire or the code base is closed and unsalvageable, delete it. Move on. 2) Pressure the networks that are already large enough to keep moving the ball down the field. Most of these platforms start to lose forward momentum once they reach feature parity with IRC. 3) We need unified communications, but we need that to be lean and modular to control the bloat.

Since none of us control any of the projects that pass test 1) all we can do is vote with our feet for stuff thats unfixable, and try to be clear as a community what we need, what is working, and what needs to be fixed.

[Doctor Syntax]

Re: What I'd like to see

"The last thing I want is to try to reach someone who then has to have an account with some service"

How do you envisage finding that someone if they don't have an account with some service? They, and, come to that, you, would need to have a unique ID. Who manages IDs in order to ensure uniqueness? You then need the system to be able to contact them. How do you manage that without using some form of service mapping the ID to some communications address?

Example: "I want it to be as easy as group chats or group calls on my phone"

The telecoms companies provide the ID, and map ID to the handset and locate the handset in the mobile network.

[Anonymous Coward]

Re: What I'd like to see

Briar is a good proof of concept of such a purely protocol based communication scenario.

[Anonymous Coward]

Re: What I'd like to see

Isn't that what Cheogram does (minus the group video)? (No, I'm not affiliated with them)

[Gene Cash]

Impressive numbers

If true.

But are they as trustworthy as oh, say, Twitter's?

And no, I don't believe them for a second, with something I've never even heard of.

[Anonymous Coward]

Teams is gonna give them a hard time

Now they have introduced emojis that can only please five year olds, they are set to explode their market share. Sure, us grown-ups, who've already been tired by its years-long bugs and UI shortcomings, will finally run away screaming...

Not necessarily into the Matrix, but just back to good old open standards. Just like I can read (almost) any web page with any browser, and read or write an email with any client (except if it comes from My Crowsoft, who hide attachments and whatnot inside non-standard attachments), so too I again want to chat to anybody via any chat client!

They would have chat:<app-or-policy-based-id>@what.ever.server as interop ids. And the (evolving) standard would be a superset of all chat-features. The sending client would query the receiving server about its subset of supported features, and only allow those to its human.