Opinion on the Matrix protocol
-
The whole network is de facto centralized on Matrix.org
That's not true there's plenty of people using different homeservers
-
Matrix is good for private general messaging. The fact that it's decentralised means it can also withstand things like government-ordered shutdowns or back doors, since there is no central point that controls the whole network.
Two things to be aware of:
- Some non-message bits (e.g. room topic text and membership) have not yet been moved to the encrypted channel, so those could be read by the administrator of a homeserver that participates in your chat room. Since most people care primarily about keeping the message content private, this is an acceptable trade-off to get all the things that Matrix offers.
- The upcoming Matrix 2.0 features and design choices simplify the UI and fix some occasional errors. It might be worth waiting until this stuff officially lands in the client apps before bringing your contacts to Matrix, for a better experience all around.
-
sure that is how pop3 does it
but metadata is still replicated to the server, so this does not solve the metadata problem -
encryption regularly breaks in weird ways, usually you see a message that you can’t read
This was once common, but it's somewhat rare now in my experience, and the upcoming Matrix 2.0 apparently addresses most (all?) of the remaining causes.
if you enable encryption in a chat room you cannot disable it
I consider this a good thing, for the sake of the people who joined or wrote in the chat with the understanding that what they write is and will remain encrypted. If you want to abandon encryption, you can always create a new room.
we now have two official clients for Android (Element and Element X) in the first one encryption breaks in weird ways, in the later there is no way to use Spaces properly
No, there is one officially released client for android: Element. Element X is in beta. When it leaves beta, it will take over as the one officially released client.
direct messages between people don’t work well - it is like they are a room with the two people
It works well for me. How is it a problem for you? It looks just like the person-to-person chats on other platforms I use, including SMS.
privacy wise matrix is weak,
Privacy of message content is not weak at all.
leaks metadata,
It's true that some metadata can be read by admins of the servers that have been invited into a chat. Given all the features that Matrix uniquely offers, that's an acceptable tradeoff for many of us. Also, the developers have stated that moving most of that metadata to the encrypted channel is planned.
attachments are not encrypted, etc.
This is just plain false.
https://spec.matrix.org/latest/client-server-api/#sending-encrypted-attachments
-
Matrix literally syncs the entire data/metadata history to all other servers where someone pops in
How else would you expect a decentralized and persistent chat room to work? If that stuff wasn't synced among the servers that were invited to participate in a room, then it wouldn't be decentralized; one server going down would kill the room (or at least lose data).
chat is meant to have an ephemeral aspect to it.
There are use cases where that makes sense, but for general use? No thanks. When I lose my account password or my phone breaks, I want to be able to sign in on another device and still have my message history.
It sucks so much RAM, so much storage,
Synapse is indeed a heavy server implementation. Several lighter ones are in development, some of which people are using already.
-
Along with the other bits that people like and dislike about it, I have another problem with it.
In order to deploy software in a manner that is resilient, it's necessary to deploy it in a "High Available" manner. This usually involves duplicated the service across multiple machines, and then automatically switching from one server to the next if one machine goes down. I consider this necessary for something to be a true alternative to the big proprietary software like discord/slack/etc, for smaller groups or nonprofits who want more reliability. Someone losing internet at their house should not result in the whole service going down. A datacenter going up in flames should not result in that lemmy instance going down (forgot which one this happened to, but I'm referencing a real thing).
The most common way (and arguably, one of the easiest) to do high availability is Kubernetes. Kubernetes has a sort of package manager, called helm where you can quickly spin up services in a highly available manner. Many services offer official helm charts (Unofficial ones are not going to be maintained reliably, so I don't like them).
The helm chart for Synapse and the rest is enterprise only meaning you have to pay. Discovering this is what finally really soured me on Matrix as using it as a discord alternative.
Of course, I never really considered Matrix a discord alternative. It lacks certain features that people want, mentioned below, like voice rooms (although voice rooms are by definition, metadata leakage, meaning people who dislike matrix for the metadata leakage would dislike voice rooms lol).
Rocketchat appeals to me because of this. Kubernetes/helm, single sign on, and interestingly, it seems to be able to federate with matrix (although I don't know if it supports e2ee with matrix). It seems that rocketchat has it's own e2ee, though I don't know how it works (or if it's any good). It also seems to support matrix clients, but doesn't seem to actually be based on matrix.
But otherwise, rocketchat seems like a much better discord alternative.
-
Overall, it's good, but you need to know what exactly you're signing up for. The reality is that you can run a decentralized or centralized E2EE chat server, along with voice/video calling, without much effort. There are hiccups with the key exchange that suck, and metadata isn't really protected. It really comes down to if it meets your particular requirements.
-
This was once common, but it’s somewhat rare now in my experience, and the upcoming Matrix 2.0 apparently addresses most (all?) of the remaining causes.
I still see it - usual case is when someone has two clients. One of them will have issues with this.
I consider this a good thing, for the sake of the people who joined or wrote in the chat with the understanding that what they write is and will remain encrypted. If you want to abandon encryption, you can always create a new room.
Disabling encryption in the room did not have to mean decrypt past history. Yes you can create a new room. But for big groups who wants to risk it. The room admins I know steer clear of encrypted group chats because of the previous issue.
No, there is one officially released client for android: Element. Element X is in beta. When it leaves beta, it will take over as the one officially released client.
One would never guess based on the release announcement
This is just plain false.
https://spec.matrix.org/latest/client-server-api/#sending-encrypted-attachments
The docs say it clearly "If encryption is enabled". Otherwise attachments are just a link, nothing special there.
-
I have used XMPP for some time now and I tried Matrix for a bit, but have stuck with XMPP until now.
I found it practically very easy to set up a prosody XMPP server in a raspberry pi. In XMPP you have the core standard that is kept quite minimal and then you can extended your implementation using XMPP extension protocols (XEPs) in a highly modular fashion. This approach of building on top of a light core using well-documented extensions I like very much.
With Matrix, JSON is used instead of XML. I think that JSON is a nice format when trying to look under the hood at how the message data is structured. XML is a bit of a pain to look at in my opinion. And I think JSON might be more efficient in how it moves the data around. So, that is a big positive for me. But I Matrix appears to be more focused on being feature rich than on having a flexible modular structure. While it does have extensions, successful extensions do have a chance of being eventually integrated into the core protocol. This makes the core feel bloated to me, because I have very minimal requirements.
In terms of security, in XMPP you start with the core and then you select the type of encryption that you like (OpenPGP, OMEMO, etc). OMEMO encryption has plausible deniability built into its design, and for me, plausible deniability is a property that I consider important for messaging. The modular approach to XMPP also means that these are choices that one gets to make in an active manner, and the protocols are open protocols that come from outside of XMPP. With Matrix you get their encryption protocol as part of the core - it is a protocol that they designed and that you need to accept to use their tool with encryption. It is probably a good protocol, but I don't think it has plausible deniability built in, and that's a choice you did not get to make.
As for moderation, I don't know. Do they mean moderation tools, or the actual absence of moderators and unmoderated communities? Because the latter is more a property of the people using the tool that the tool itself. You can have your own private communities.
If someone asks me, I could recommend Matrix but would rather recommend XMPP, depending on what they are looking for specifically.
-
forgot which one this happened to, but I’m referencing a real thing
OVH Strasbourg campus on March 10, 2021: https://corporate.ovhcloud.com/en-ie/newsroom/news/informations-site-strasbourg/
-
Its definetely more polished for users, but it leaks metadata. XMPP is nicer to work with, as a developer.
-
Using fluffy chat i have none of those issues. But voice/video calling is buggy, using the official server.
-
That is nowhere near the mass of the centralized community & the fact it can’t be reasonable ran my medium-sized groups on a budget shows it doesn’t scale right & is not accessible. Sure you can run your own ATProto/BlueSky node if you have $80k USD / mo to host it—it’s technically open source! This is the kinda the same thing… costs too damn much so folks flock to the buggered instances.
-
I’m not aware of any service that [goes fully peer-to-peer] while being practical for most people, yet.
Retroshare is almost ready for prime time after remaining in development for over 20 years. Each "friend" runs it's own service for the decentralized network of "friends" and hands off message fragments from immediate "friends" for swapping files, store-and-forward messages, chats, etc., to other more distant network participants.
The swindle is that your friends know you by your IP address. If Big Government, Big Media, or Big Crime knocks over one of them, they've got you, too. But — not to worry — you can actually — so I'm told — run an RS instance behind a TOR hidden service.
I much prefer the article from 22 Mar 2019 about "TOR Onion Services" preserved at the Wayback Machine instead of the current article.
-
Persistence is for forums. Chat has horrible discovery / search UX which makes it a black hole for knowledge—which is why it should be seen as temporary (I think even Signal sets 4 week expiry as default). Folks often say things the regret 5 years down the line in chat space & that sort of info needs to just fade away than be some target of some weirdo doxxing campaign.
You know you can have archive management & multi-devices without syncing the entire history right? Many protocol think hold onto the last 20 messages in a new group & the last year of private messages is good enough (can be saved local to the device if desired). Copying the Discord/Telegram/Slack model ain’t it.
Synpase is the reference server. It’s Python & slow as balls because of it, but the others are always playing catch-up. With Element moving with it & graceful fallbacks not being a high priority, shit just doesn’t work in practice using anything but Synapse / Element since mosh other users are. Technically having alternatives is not the same as the current situation in actual practice. Even if they can try to hide the some of the perf issues behind these gland concepts like sliding sync, there are literal fundamental issues with how the protocol is architected that a server of hand-written optimized assemply could never overcome—the eventual consistercy is by design.
-
I dislike how little security and moderation it has myself. Too basic, IRC seemed to have better moderation support but granted they used bots for more advanced stuff. Not to mention how clunky it seems. That is ignoring the even higher bar required to even get started, having to find both a client and a server to get started is a pretty high bar for a lot of people.
