The Matrix Trashfire
blog.koehntopp.info
blog.koehntopp.info
Side note - this kind of this is why good QA people are awesome. They'll show you what users will actually do.
I'll add in something here. Element the app said they were logging into matrix.org.
matrix.org has a "try matrix". The first thing is it tells me to choose a client (this feels like a loop), then says to choose a server but also maybe I don't need to, then has a create account button.
The create account button takes me to a docs page. Which tells me to go to the element site, and then create an account with matrix.
So that's matrix -> use element -> element says to use matrix -> matrix says to use someone else, ok you can use us -> to use us go to element -> element says you're making an account with matrix.
edit - oh you can and should also do this with your dev process.
Create an empty folder, check out the repo and follow the readme. Do you actually get a running system for local dev? Can you successfully run the tests? If you are able to, do this on a clean machine (maybe load up a docker image and see if you can follow it in a truly clear system). Does it turn out it assumes you already have tool X installed because your developers already have it from another project? Do you actually need postgres running with a specific user with specific login details?
If you're like me you don't like writing docs, so this may actually just push you to add scripts that do the setup required.
To not sound sanctimonious about this every time I've done this with my own code I've found issues with the documentation.
The fact that it's not being done doesn't bode well for their perceived engagement to this project.
I remember when it launched and how much they hyped it up to be the future of secure messaging. That was how many years ago now? It was pre-pandemic.
I'm a lover of all selfhostable federated solutions so I actually hosted a Matrix server for a couple of years. My conclusion is that it's just not ready for production scalability.
And you can't migrate easily between implementations because of their unique database design.
A bit of a side-note: this sort of analysis is a great answer to "I want to contribute to open source, how?". Some fairly simple wins for significantly better user experience, and no coding required!
At the Japanese company that I used to work for, it meant that you were one of the most powerful people in the corporation, and was a sought-after adornment.
Different strokes, and all that...
They never reported a "NotABug." They could back up every report, and give exact reproduction steps.
They found weird, obscure corner cases, and that was by hand (they hated automation tools).
They had 3,000-line Excel spreadsheets. If even one of those rows failed, the whole shooting match (like an entire product line) could come to a halt (so that meant they had to cross their t's, and dot their i's).
They seldom had "opinion-based" reports, and, when they did, the report was presented by the manager, after long discussions.
The company I worked for, was renowned as one of the highest-Quality optical corporations in the world.
If you ever get the chance, take it - you will learn way more about software quality than you thought existed!
Heh, this reminds me of an episode of Top Gear I was watching years ago about quality of British cars. They said something along the lines of "The manufacture sais 'eh, good enough' the moment the car is able to move under its own power.
Hardware != software.
Hardware companies have a really difficult time, understanding this. They insist on running in-house software projects as waterfall-based-measure-twice-cut-once-never-accept-a-bug-count-greater-than-0.
Anything different is "bad quality cowboy."
It can be difficult. I rapidly learned not to use the word "agile," within earshot of many senior types.
This applies to US hardware companies, as well as Japanese ones.
Most folks, hereabouts, seem to think of me as an unbearable, retentive, snob, but my former managers would often think of me as an undisciplined, reckless, slob.
"Every ticket should result in a code change, *or* a documentation change"
was one of the coolest sentences I ever read on some web page.
I've seen QA get run over by aggressive developers.
I've seen QA people who were so good, detailed and provided clear reproduction steps that developers couldn't wait to see them work.
I've seen QA people who were completely unwilling to work on efficiency improvements, automation or even testing things in parallel so they became a bottleneck to the entire organization.
I've seen QA people who just fall into a routine, do exactly what is asked of them and never try to improve.
Like with anything, it comes down to the person in the job. If you get QA people who are really committed to the work, take pride in what they do and are always trying to improve it's the dream.
When you don't have that, it's a very mixed bag.
In general, I'd say that's because it's a position that's shit on.
You're apt to be paid far less than actual dev positions. If you're a QA manager you're always pushed on by upper management to outsource and lower costs. There is none of the prestige of being a "QA 10xer" that you'd see heaped upon a dev in the same position. And I see little training/courses pushed out for QA like is typically seen for dev.
It seems like QA in most companies is a necessary evil that management would take out back and shoot the first moment they could.
Good QA will be sensitive to this when creating feedback, and good Devs will understand that tunnel vision from submerged in the product full time every day will typically lead to a built experience that isn’t amenable to large portions of their users.
Providing QA feedback tactfully is an impressive and appreciated skill, as is receiving feedback gracefully. Everyone should aspire to do both.
True.
A good tester is the kind of person who revels in running the same lab experiment many, many times and chortles for always getting results within the error bars.
A good QA is the kind of person who can think of every way something will fail, and then come up with a proactive risk mitigation strategy that makes everyone smile with pride.
> QA get run over by aggressive developers
True.
Back when we had QA/QC, my "One Weird Trick" was to put the QA / Test team in charge of releases. Running the bug triages, in charge of acceptance testing, running the go/no-go meetings, etc.
Worked f@#$ing great. Almost like magic. Zero drama. Our releases were almost anti-climatic.
I miss the '90s.
Well, I miss my '90s QA/Test experience.
Most everyone else was stuck in Kem Caner's world. The preeminent "SQA" guru who preached victimhood and grievances. Probably did more than any one to pile drive the QA Test profession into the Mariana Trench of irrelevance.
(Apologies, weak sauce, I know. I usually have a better "colorful metaphor" ready to deploy for these types of rants.)
This kind of article is super valuable since it gives us the perspective of a new user. I opened https://github.com/matrix-org/matrix.org/issues/2178 to translate the gripes mentioned in the issue into actionable items for us. I took action on the most urgent one (updating the Try Matrix page), but want to take the time to go beyond the surface symptoms and address the root cause of the other gripes.
On the Foundation side, we're a small but mighty team of four. The website is currently maintained part time by me and a volunteer who is doing an excellent job at it.
As I wrote recently in a blog post "Tracking what works, not people" (https://ergaster.org/posts/2024/01/24-tracking-what-works/), I would love to have the resources to conduct user research and user testing on the website but I unfortunately don't. We deployed privacy-preserving analytics to see where people drop and what confuses them. It's not nearly as good as proper QA and user testing, but that's what we can afford for now.
Overall I'm grateful to the author for documenting their frustration, and even more grateful for reacting constructively to our responses and integrating them in the blog post! One of the strengths of open source is to find and address issues collectively. I consider this blog post to be a good open source contribution.
If people around believe in our mission and want to help us with their brainpower, I invite them to join our "Office of the Matrix.org Foundation" room: https://matrix.to/#/%23foundation-office:matrix.org
For those aligned with our mission and who want to support us financially, the https://matrix.org/support/ page should give you all the information you need to help us out.
I think there are several things we can do improve, and the process should be fairly similar with Element:
1. Refine who the website is for, and what they are coming here for. We need to narrow down who our audiences are, what they want, what they known and don't know, and how we can best serve them.
2. Conduct user research with a diverse set of people representative of who we think our audiences are. We need to sit down with them, ask them to create a matrix account unguided, and ask them to comment what they are doing and how they feel about things.
One of the difficulties of the website is to find the right balance between not overwhelming the user with difficult decisions (picking a client? picking a server? I just want to chat with my friends!!) without being too biased. We need to be opinionated to guide newcomers through a decently simple process, but we need to leave room for all the vendors to thrive.
also, i myself gave up contributing small fixes because you don't host source map files and I'm too lazy to setup a dev env.
Thanks for working on matrix, I'm building some things on matrix and it's been pretty interesting.
> For those aligned with our mission and who want to support us financially, the https://matrix.org/support/ page should give you all the information you need to help us out.
Great highlight, I've donated.
I've read that a strategy for this is create an ad and pay people $50 to come in and try to use your software. Tell them to do something in your software and see what they get hung up on. The worst UX problems will be hit by nearly every user.
As simple as that is, none of my employers have ever done this. The closest was one of the bosses asking his wife to try out the software.
Having someone in person can be extremely valuable for other reasons, but this can be a quick approach.
For larger customers, going onsite and watching them use your tools is so valuable.
> Once people are familiar with the product (devs, QA, and anyone who has used it before) then they're "tainted".
I broadly agree, though this is where I'd split out really good QA people I've worked with. The added advantage is they can also explain the change required that would get some user X to have a better experience (e.g. how your autistic users may get more stuck at a certain place, or how to change the flow such that a 3-4 year old can navigate a UI).
Two more years. I've been a matrix user for almost a decade. Things have not gotten better at all.
I used to use Riot, I invested (and subsequently lost) a good amount of social capital on boarding my close circle, mostly non technical people, to using it. We used it. It was a little janky with the key sharing and verifying users and what not, but we managed. Then Element came out, and at first, whatever, but then a lot of those verification tools just stopped working. Several of our accounts became locked in some limbo where they couldn't be verified because the verification methods didn't support legacy verification. Nobody wanted to move to a new client which was less feature rich. We moved to signal eventually and have been mostly happy ever since.
I still use it with a couple of people. Its still just as janky as ever. First riot, then element. Now Element X? Dendrite... How many times are these guys going to rebuild from scratch before they realize they're in over their heads?
I just gave up on it, I still use it with the couple of people I'm connected to and I don't do new contacts on it with anyone. I treat it like I do Discord. For me now it's XMPP and email, and signal for real world contacts. I mess with some of the newer messaging tools out there like Simplex (which absolutely has a terrible onboarding flow, but they're new so they get a pass for now) and things, and I hope to get utility out of them, but I'm never going to burn myself again pushing people to use something new, I'll wait until these things prove themselves, a lesson I learned from Matrix which never did mature into anything worthwhile.
However I use Beeper all day every day, via their iOS, Android, and macOS clients. Beeper (not the iMessage app, but their previous and continuing multi-network app) is pretty great. I get one consistent UX across all chat networks I use. Sometimes the networks drop out, but rarely due to Beeper issues.
Beeper is essentially a Matrix homeserver, plus a bunch of hosted Matrix bridges, and as far as I can tell, that whole part of Beeper was a great technical decision. The Beeper clients started off as forks of the Element clients, and honestly they were a trashfire at the beginning, but Beeper have been quickly iterating and replacing parts, and they're now pretty solid. They're not yet WhatsApp quality UX, but they're approaching it.
I don't think the problem is Matrix.
Matrix could have a fancy landing page pitching itself to implementers who implement homeservers, bridges, or clients, and they could market to end users.
ActivityPub, HTTP, XMPP, etc sound like technical things. If you land on a page talking about the "XMPP specification" then you quickly get the idea that it's not where you want to be as an end user.
"Matrix" does sound a lot like the name of an end-user relevant product of some sort, and a client sending users to matrix.org compounds the issue.
There's a reason why big companies have brand guidelines. They have people on staff that understand that people are confused quite easily and don't want to figure out where "Matrix", "Element" and "Element X" stand in relation to each other.
The client I use doesn't send users to matrix.org, and I would assume that's by choice. Why do users need to know? Matrix.org is clearly a hub for the spec, documentation, GitHub links, developer community.
I keep saying that they should make a Matrix branded client that lets you easily donate to the foundation (like Signal does) and creates accounts only on matrix.org.
Unfortunately that doesn’t really work with the ethos of the project.
We definitely aim for Matrix-based products to be used by the general public, in the same way emails are. For this to happen, we need to be mindful of who our audiences are, what they are looking for, what they know and don't know, and how to deliver a message that works for them.
If you're interested in how we thought the website, you can check https://github.com/matrix-org/matrix.org/issues/1502 and https://github.com/matrix-org/matrix.org/issues/1543 for example
That said, the Element/Element X migration is a mess. But if he'd just gone to the Element website and clicked "get started", it would have just worked.
> my recommendation is to avoid Matrix for at least two years
which seems arbitrary. Why wait 2 years and not one or just a couple months? The french administration is already using it now https://www.tchap.gouv.fr/
In federated protocols it's always harder for the user to choose an instance for them. Not sure if the responsibility for that should be on the protocol managing party.
If they did manage to find Element at all, I would guess that would be through the "try matrix" button on matrix.org, which has an "install Element" button, which then leads to a "download for macOS" button.
More realistically, people would be typing "Matrix" into GPlay or the app store on their phones. The confusing Element/Element X situation would still apply, of course.
No it wouldn't.
element.io -> get started gives this:
> Get started.
> Setup a self-hosted or cloud deployment, with powerful enterprise capabilities.
edit - expanding.
The element site is entirely about getting something for your business. It has a pricing page that tells me it'll be free for up to 200 users but I have to self host. Nothing on the front page of it tells me it's a free app I can use elsewhere. I have to go to "product" (!) and choose the app.
To get started with element the app and create an account to chat you are saying I should not install one of their applications, instead I should
1. Go to the element site
2. Ignore all the talk about it being a product for teams
3. Still want to get started with not what the page is about, click on get started
4. Totally ignore what it tells me the page is for, because it's about setting up a server
5. Still want to download the application regardless
6. Scroll past all the CTAs and the form
7. Download the app
Going to element.io and clicking "get started" takes you to a form to submit some kind of enterprise inquiry, asking what the name and size of your company is...
Separate but they work closely from what I gather. New Vector develops Element/ElementX and has seats on the Matrix.org board. Element is the Matrix.org flagship client.
I do appreciate that Matrix.org has its own foundation and I don't mean to disparage New Vector in any way, but they are undeniably closely linked. I'm not sure if Matrix would survive without New Vector.
I onboarded a family member onto my Matrix server with FluffyChat as the client. This person is a power user, fairly technical, yet still refers to the chat as "FluffyChat" and although I've explained several times that choosing FluffyChat was maybe a mistake and they should use Element, it never seems to really click that multiple clients are possible.
And really, they aren't possible. They have different subsets of features.
If you want to see a trash can fire, just try to follow the discussion for adding custom emoji to Matrix: https://github.com/matrix-org/matrix-spec-proposals/pull/195...
it's been going on for years. It's a feature the competitors have had for half a decade, as long as this discussion has been ongoing. I've been watching this issue for half a decade thinking "surely they'll decide on something" but mostly all I've been convinced of is this: Matrix is design by committee in all of the worst aspects and at every level of design. If anything gets done at all, it's a convoluted mess, and it's a miracle that it even happens.
I wish community software developers would focus their attention.. somewhere else.
We don’t even have captions for images yet!
I think this is a key issue here. Element X is unfinished, but isn't labeled as such. The rest seems to be the result of a buggy, unfinished process, that I don't think exists on the stable client.
It probably also doesn't help that the Element app on iOS has received relatively little attention over the years compared to the Android app, which has had several rewrites. This is probably also why Element X is getting so much focus, as it's the first fresh start for Matrix on Apple's platforms in ages.
Matrix is cool tech, but it's not easy to get into. I'd argue the same for XMPP and other federated services, as their competition has the advantage of having one app managed by one company. Even things like email are confusing to people beyond the very basics; setting up an email client is still something technical support needs to hand-hold people through, no matter how many wizards and step-by-step guides apps may add.
I trust my homeserver, since I host it myself. I do not need end to end encryption. I understand this is an issue of the client, not the protocol. But there aren't many clients. Prebuilt element for android from fDroid will connect to matrix.org, vector.im and other network hosts and I don't want that at all, although this tracking can't easily be disabled. It feels very centralised.
I run my own homeserver and want to chat with my friend that runs his own server. It is unacceptable to me that clients connect to anything other than those two homeservers (apart from CRL and OCSP, which should also be disabled by default, as I consider those protocols great spyware). Not to mention the fact that homeserver software itself is known to make connections to the servers of the developers by default, without ever talking to someone on matrix.org. This is also unacceptable. My homeserver should only connect to other homeservers.
3PID is a failed attempt, as it centralises identities and works by utilising a single point that gathers a lot of personat information at one place. I don't want it.
XMPP does not have those issues. Set up prosody and use dino or Conversations and they won't make any connections to non-essential servers. Furthermore, the end to end encryption is way easier to use in XMPP (OMEMO), and it's easy to turn it off if you don't need it.
I like that Matrix puts an emphasis on message history, but on XMPP that seems like an afterthought. For example on XMPP multi user chats, messages history retention relies on the server that hosts the chatroom and this is sometimes very limited, sometimes even disabled. And if that's the case, you only get messages when you have a _client_ online, as your server won't store messages when you don't have a client connected. Or something like that.
And AFAIK, multiple clients with a MUC room opened will appear as multiple users sometimes. I'm not sure how it all works really, so take my words with a grain of salt.
XMPP seems more like a pubsub system for system messages, like MQTT (:
XMPP had that promise but due the XEP situation it quickly became difficult to actually federate as most XEPs are optional or not supported on your federation partners.
Everything you said is true; if you can tolerate centralisation then just stick to XMPP, it's pretty good.
Here's the first one I found that causes server<->server incompatibility: https://xmpp.org/extensions/attic/xep-0369-0.7.1.html
What was always missing was a golden set of standards. Maybe XMPP "2" is XMPP and a set of XEPs and so on.
Otherwise all you have is a bunch of half-working XMPP implementations.
Very famous ones of course include voice/video. The UX on that is atrocious.
What kind of incompatibilities does it cause? It's an unfinished spec for group chats, which, to my knowledge is barely implemented anywhere.
Just for the record I'm using both XMPP and Matrix daily and both have issues :/
This is false.
"this is false" is a terribly glib statement with literally no backing and can only be said if a person has either zero knowledge of what they're talking about or they've tied themselves to a single implementation of XMPP everywhere, which is essentially standardising a bunch of XEPs.
Camera and microphone are not a mandatory feature of Matrix either (;
It's level of centralisation is comparable to that of email (and email is very well federated in my opinion).
MUCs like the XEP you mentioned are handled by a different XEP.
- The verification is a mess (in the article; By the way: Once your account is set up, the verification failures don't go away). It has frequent verification popups and overlays; when I attempt to follow them, various errors occur, and it fails. So, the client nags you to verify, but the verification process is broken.
- The read notification system is broken; most chat groups will show as having unread messages, when there are none. This is possibly related to the thread system, but my results here are inconclusive in regards to the exact nature of the problem, nor the solution.
- Message posting and syncing is unreliable, especially after edits. Some messages will show on the PC program, but not the mobile, and vice versa. Sometimes edits I or someone makes will show up on one client, but not the other.
Still, I run Matrix servers since inception of the project (10 years now \o/), and for an experienced system administrator this is not something difficult to do.
If you think running a Matrix server is difficult, you are probably not the intended audience: running an IRC server, an email server, or some other server, is mostly similarly difficult.
Matrix is a communication protocol, and it is not intended to be touched by end-users. If your goal is to just communicate on the matrix network as an enduser, stay away from matrix. I haven't seen an email enduser who browsers to https://www.rfc-editor.org/rfc/rfc5321.html, to figure out how to sign up for hotmail.....
Element on the other hand, IS intended to be userfriendly, and there is obviously a lot of room for improvement. But through the years I experienced that users who want to use Element to stay in touch with their loved once, have no problem with that.
Lastly I think comparing an open source project like Matrix/Element to Publicly traded corporations like Slack or Meta, is not fair. They operate with totally different business models. If you'd compare the quality of Matrix/Element to Slack in relation to annual budget, Slacks ROI would be depressing.
If we want to "win" (reach similar/higher adoption), we need to at least come close. It's not easy work, but not doing it and leaving the product that so much good work has ready gone into unusable for a vast number of people would be a bummer.
That kind of users aren't worth the hassle if they have no money.
I personally have better relationships with people that enjoy learning something new, and coming up with solutions for issues themselves, eventually contributing to the ecosystem.
Then we should add deliberate errors in the signup process and encourage the community not to talk about them so there's a definite right of passage.
> I personally have better relationships with people that enjoy learning something new,
Here's another perspective. I love learning new things. But this is making me learn the internal product releases of a chat app rather than, say, what the different lions represent in the dance I watched on Chinese new year.
Or worse, you're making me learn what the split is between matrix the spec, matrix the hosted server, the matrix foundation, element the business, element the hosted service, element the app and the other element the app - rather than pretend to be an imaginary creature called a meep with my daughter.
But it's still important not to make people waste their time. End users should be sent to an end-user friendly place, and developers should be quickly sent off to usable development documentation.
It doesn't help anyone to confuse people and have them figure out the details of the internal organization and convoluted relationships between various pieces before they can even start doing work.
So what is "intended to be touched by end users"? I can't figure that out either from the article or the comments here.
Assume I can (and actually have) run an irc server, but I haven't set up Matrix for the last 10 years.
Oh wait, they say "An open network for secure, decentralised communication" instead.
Running an IRC server is absolutely not as difficult as running a Matrix server.
There is no state, so you can literally build a tiny Docker image with the config baked in, run it on a VM with the specs of a cheap computer from the 1990s, and then forget about it for years. If it gets hacked (which I think isn't super likely as it's a small codebase that's been out there for decades), you build a new image with a more recent version of ircd.
I started creating a similar post for matrix/element/server installs - a while back,
Screenshots and saving putty sessions.. (wondering if I should find a tool that records ssh input/output or just use the save sessions built in)..
I've succeeded with a matrix server install 2 out of 6 tries.
I am about to try again with a new install since I don't have faith in succeeding a multi-version upgrade.
I wish there was an easy way to export user names and email addys to port to a new install, as I worry that making a new install could allow for some nefarious people to come in and create accounts with another old user's name.
I love matrix and element and other clients, it's the best for what many need - although there are many rough spots in using it both server side and as an end user.
Moderation usability is a major issue for us, maybe with a new install I will jump into that rabbit hole of how to set things up for that and see if it's easier these days.
I hope the vucuum DB and such is better with the newer versions.
Looking forward to scouring the web for tutorials on all the basic things debian and perhaps logging the journey, maybe just screenshots will be fine, we'll see.
BTW, on the moderation front: Draupnir is the most actively maintained tool in that space and I recommend checking it out. Separately, the Foundation is currently investing in developing better tooling to complement moderation bots like Draupnir. We don't have a planned release date, but what we're making will be FOSS and available to all to use.
We're also looking to involve more technical writers to help us better support new users and homeserver admins – for sure, it's a rough road right now.
Josh, Managing Director of the Matrix.org Foundation
Matrix/Element is so close to a great alternative to Slack, but in it's current state it's totally unusable.
This is a years-old issue with Element, which never happened to me with other sending clients such as FluffyChat. It's unbelievable that it's unfixed given it's a dealbreaker as it results in permanently unreadable messages on your end (the "waiting" in "waiting for this message" is a lie). And since this needs to be fixed on the sending side, you NEED to use another messenger to fix the conversation (if at all, as this requires reading extremely long issues on github with buried suggestions many won't do).
After getting it a few times most users would just dump Element and blame matrix as a failure to never touch it again. The excuse "we're working on this on the next client iteration" is actually ensuring a growing list of users will hit this (as it's bound to happen) and avoid matrix in the future.
UI/onboarding issues are minor compared to the fact that the conversation can be randomly broken.
If FluffyChat is not having this issue, it is probably overly eager to share encryption keys instead of allowing the user fine-grained access to control keys, which is successfully hiding the complexity of the ratchet encryption but potentially exposing the user to attacks to force the sharing of keys.
Edit: I was looking around. While Matrix is well documented, Element's documentation is poor because they expect you to figure things out from popups in the UI -- fair enough, unfortunately most apps are like this, and Element's popups have gotten a lot clearer. But I did find these two pages from a university that seem to serve well as "Element's missing manual". Worth a read if you are trying Matrix for the first time, because it discusses some things that can look like bugs but are really user error.
This is compounded by the fact that there seems no mechanism to recover for the receiver. The receiving client is just oblivious, it will _never_ be able to decrypt the messages and thus also never be able to backup the session keys if none of the clients associated with the account ever received the keys.
The suggested work-around is forcing the sending client to rotate the session keys earlier and thus fix the _following_ messages only.
I've been in situations where two element clients (both sending and receiving) failed to decrypt each other's messages.
This is a pretty damning issue for a client that enables encryption by default.
In my experience, this is generally resolved automatically in the background. It occurs when the device that's supposed to share the necessary keys isn't online while any of your devices are online, and the moment enough devices are connected again, the messages will pop into your timeline. I'd like a "retry" button, but if the error shows up, manually clicking "retry" wouldn't really do much.
As for it being a Slack competitor: just don't enable encryption and you'll skip over a lot of problems, and come a lot closer to Slack in terms of usability.
The threads UX is a bit weird, but it does show you that there are unread messages hidden in threads through a little indicator by the threads icon. Not the greatest UX, I agree, but I wouldn't call it "unusable".
If Matrix does ever take off, this will be an extremely valuable distinction to have.
Element is the same team as the Matrix.org foundation, with the same objectives. I understand why they maintain a separation of concerns at the institutional level, but for someone to say "Matrix offers hosted servers" and to act confused like "What do you mean, who's 'they'? Matrix doesn't do that! Only Element, the organization run by the exact same people, who's only goal is to further the adoption of the Matrix.org spec. I can't possibly fathom what you think the connection is." is the very definition of being disingenuous.
If you dig a bit, I'm sure you'll find this is true for quite a bit of the people either in Element or in The Foundation.
https://matrix.org/about/ has a list of names for the "guardians" of the foundation (whatever that may mean exactly) which consist of 40% Element, 60% external parties. The core spec team at the bottom links to Github profiles, from which I believe 8 out of 10 people work for Element (though I'm not 100% sure if the last person in the list still works for them based on his Github profile tag).
Thib isn't part of the foundation, he's just part of the business side, and quite a public part at that. I think his role is a good example of the distinction between Matrix and Element.
They're mostly the same people (80% of the core spec team works for Element), but not exactly the same people. The Element people that maintain Matrix certainly have a vested interest in Element, but that doesn't make Matrix exclusively Element-oriented.
While you and I understand the distinction, I think it's important to make it clear to other readers here that Element and Matrix are not the same organisation. Because of Matrix's history, and the interlinking between matrix.org and Element, one might assume them to be, and if the opening post shows anything, it's that the Matrix ecosystem can benefit from some additional clarity.
Disclaimer: I'm one of etke.cc developers
It's ok. Most bugs concern threads. But it's one of the only chat apps that enable threads, so I'm ok with that, threads are absolutely needed in my opinion. Signal conversations can become such a mess because of that.
ElementX lacks threads, but apart from that is refreshing. Looks more like a chat app than an enterprise messaging app.
Still your article is very important. The UX should be improved.
The workaround is to create new groups, even if that's with the same set of people. I even have groups with just another person and myself, e.g. for specific projects. In my experience that works well enough, also because if something is longer-lived, I'll put it in a shared doc instead.
That's what I just did with a friend : share 10 messages about a video.
We're 4 in the group. 2 of them might never be interested by the talk about that video. It's completely unpractical to create a new group to just talk about that.
Then you need to either close or leave the group. No problems with threads, it's created with a click and finishes by lack of new messages.
It's just what happens in real life : people move around 2 meters when they want to talk about something in particular, and other people can either ignore, either join the ephemeral group.
I can definitely see the problem if you try to use Signal like you use IRC, with big channels with 100+ people and very different topics, not all of them relevant and with people you care about, and I still use Matrix / forums for that.
> It's just what happens in real life : people move around 2 meters when they want to talk about something in particular, and other people can either ignore, either join the ephemeral group.
It really depends on the setting, that's only if you're standing and even then, if you're having a meal sitting at a table, I'd be surprised to see this.
Cyber furz
In English:
Cyber fart
Every day is a school day!
The protocol is from what I can tell pretty cleverly designed/usable as a casual chat app (even if it leans heavily towards IRC esque design), but actually figuring out how to use it is somewhere between "wisdom of the ancients" and actually impossible. A lot of very relevant information is stored in old documentation that is currently marked as outdated on the site but has no updated equivalent.
The bad apps and onboarding only hamper it further.
It's still baffling to me that the best way to actually administer a selfhosted matrix homeserver (specifically, synapse, the reference homeserver) is to do a database hack to promote a user to an admin and then use an external PWA hosted on GitHub[0] so you can actually do basic moderation actions without having to resort to using curl.
We're a rather small team on the Foundation side and lack the personpower to do so.
We're in the process of listing what documentation we need and what we need to update. This will be the foundational work to apply to Google Summer of Docs and for individual tech writers to apply to grants like NLNet (who doesn't usually fund "large" organisations like us) to help us out.
I'm also adding instructions on how people can step in and contribute to the docs if they have the time and desire to do so: https://github.com/matrix-org/matrix.org/pull/2155
We're doing our best with our limited resources, but I'm confident we can improve the situation eventually!
I so wanted to love Matrix. I tried it for a year and it just had too many sharp edges.
But the Matrix UI/UX still grates me on how bad it is. Just stop pretending, copy what Discord does and be done with it.
I wish they had a built in way, & also some way to make channels line bot_commands default to muted
There is some complexity in educating due to its distributed nature, but a top notch UX is much needed to overcome it.
If not for the last point, I'd be using WhatsApp just fine. But because of it, Matrix/Element is currently the best we have. Is it great? Absolutely not, but it is the best we have at the moment, and to call it a "trashfire" without putting things in perspective is a disservice.
I can't say if this is the future, but I like it taking another direction. Taking a few steps back, this model solves a lot of problems with a very easy UX for beginners: shared calendar, shared expenses, shared notes can all happen inside your chat, which is naturally the place where you already share stuff with people, but now it can be more without any server installation or anything.
Don't get me wrong, it would be great if more people were using XMPP. Now that I am more involved in the Fediverse space I'm learning how many wheels are being reinvented and XMPP has already solved. If more people learned about https://movim.eu I'd be able to shut off Communick and move on to do something else to do with my life, but the reality is that XMPP failed to achieve critical mass because it never had someone to complete control the protocol.
iOS simply sucks here and lowering down your pants to marry yourself to the whims of these insane "platforms" if anything most likely reduces your interoperability.
You should be realistic and consider that there is no point to any "E2EE" messaging solution on iOS as _by construction_ all the metadata (at the very least) is going to be leaked to Apple (and they in turn will leak that to the authorities, as was pointed in HN quite recently), precisely by the push notifications crap you'd be forced to adopt as part of the pants lowering requiered to support iOS.
We can be here grandstanding and dismissing other people's choices or we can be pragmatic and find ways to grow the alternative networks to the point where the "mainstream" can no longer ignore it.
If you want to continue using XMPP, great. But those that are on Apple are not going to drop their beloved iDevices just because we are telling them how cool XMPP is. Your inflexibility will do nothing but keep you isolated and able to talk with a handful of other people that are stubborn as you. However, if you let yourself accept that encouraging other people to adopt Matrix will at the same time (a) bring progress to those on iOS and (b) increase the utility of your own XMPP server, as now there will be more people being able to reach you through a bridge.
I have been trying the pragmatic way for over 30 years and it. simply. doesn't. work. The mainstream will drop privacy, federation, and anything in a heartbeat just because the new network comes with a client which can do animated GIFs. There's simply no way to continuously try to match the race of ever-diminishing-usefulness features and if you even try to point that then someone calls you "dismissive and grandstanding".
The only (possible) way forward is legislation. Carrots do not work.
ICQ had animated gifs. MSN had animated gifs. Viber has animated gifs. Telegram has animated gifs.
Why shouldn't people expect animated gifs from any decent messenger? Who are we to police what people should prefer for such a crucial piece of technology?
Could you elaborate? From screenshots it looks like any other chat app and branding isn't offensive.
I'm not saying that I can do better, but I can bet that if you show it to 100 iphone users, 98% would not be interested in having it as their main messenger app.
Neither seems to provide any sort of conceptual framework to allow the user to react in a reasonable way when something goes wrong with the identity stuff...
OMEMO running over XMPP is pretty terrible for identity stuff, at least for the clients I have encountered.
Why wouldn't you scan the QR code instead of doing that?
In any case, the user won't have the faintest idea of why they have to do that, so they won't, which in a sense makes this moot.
If you're not in the same location, you can long press the code in Signal and "compare to clipboard".
> In any case, the user won't have the faintest idea of why they have to do that, so they won't, which in a sense makes this moot.
I think that's a generic remark about this though, that applies to all messengers AFAIK. Whether that's a 4-digit code and 60.
My point is that users should have the chance to know what they are doing. There seems to be a tendency to deliberately keep them in the dark. A 4 digit code is objectively more usable than a 60 digit code.
> A 4 digit code is objectively more usable than a 60 digit code.
It's more usable, but that would assume synchronicity (like a TOTP) or something else to be secure, while the 60 digits do not AFAICT. So there's a usability tradeoff. You can't truncate a hash function and assume it's just as safe. They could add more options on top of the current one though.
Overall I think the intersection of pairs of users who:
* want to verify their safety numbers
* have very infrequent physical contacts
* would struggle to use another trusted channel to communicate their safety numbers
is small enough for this not to be a priority for Signal.
If a system is using a 4 digit number for identity verification, chances are it is something like a PAKE[2]. See OTR's (Off The Record) simplified Socialist Millionaire's Protocol for a practical example that allows the use of any string based on shared knowledge.
[1] https://sequoia-pgp.org/blog/2021/06/28/202106-hey-signal-gr...
[2] https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
If you happen to have Jitsi Meet installed you'll already have an XMPP server up and running to which you can add some configuration to make it useable for this purpose.
Source: this is what I've been doing for many years
I'm not being facetious. Try that, and then try doing it with Matrix/Element. Tell me which one do you end up with.
Element (then called riot.im) managed to do text, audio and video calls. The app had some bugs, but nothing that would block me from calling each other. The UX can still be confusing and I have occasional conversations where my father complains he can not hear me, most of them caused by my father not knowing that kept the video call but switched to the internal phone speaker instead of the external one.
I heard about Siskin some months ago. Honestly, I haven't tried it yet. It might be that is fully functional, but the UI is so bare that there is no way that I'll be able to convince my father to switch to it. He still complains that he'd rather use WhatsApp like everyone else, so whatever XMPP brings now will be a case of "too little, too late".
Maybe you can give your father a non-iOS phone if that is what is keeping your experiment from succeeding? We're all on Android here, anything from stock Samsung like my mother uses to self-built LineageOS like I use and we have no problems like you describe. I video-chat daily with my mother without problems, we're using Jitsi Meet (hosted on the same server) for larger video meetings, we've used Nextcloud Talk (also hosted on that server-under-the-stairs) as well but now mostly use Conversations. Telegram also works well for video chat but that is neither self-hosted nor end-to-end encrypted so it is not a real comparison to Matrix or XMPP with OMEMO.
That's a non-starter. He already had Android phones before, never liked them. O have to pick my battles, and getting him to call me Matrix instead of WhatsApp was already enough to call it success.
Besides, my point was less about the specific individual but the systemic issue. iOS is too large of a market segment to ignore, and I can not go around telling everyone "hey, why don't you just drop your shit Apple device and switch to something more open?"
"WhatsApp works fine, I talk to you on there already" (in reality, via a Matrix-WhatsApp bridge)
"Who am i going to talk to on there?" (Me?)
"I don't want to install another app" (but installing ad-laden Viber is fine...)
"I cannot share pictures to Element so I sent it to you through [iOS] Messages" (well, Element removed share capabilities in iOS due to a rare bug)
Simply ignoring messages (their iMessage and calls rings from all connected devices, but Element just notifies once)
I have tried Matrix/Element (self-hosted, of course, like everything else I use) and found it lacking compared to XMPP. It just seems to add needless complexity and does not offer anything worthwhile to compensate for it. I tried some Matrix bridges as well but found these lacking for my purposes.
So the answer to your question is 'I ended up with XMPP'.
With Matrix, I don't need to convince them.
Nice, I'd like to be friends with you. But do you realize that maybe, just maybe, you are facing a bit of availability bias?
- Install Conversations on Android - In a prompt, there's a "create an account", I create one (it's with conversations.im) - I have an account - At this point there's a slight confusion between "what discussions are happening" and "what discussions do you know about", but I manage to find a room to a discussion I'm interested in - Get in, see the messages
The experience is definitely 100x nicer
I don't really recall much about the sign-up process at all, which I guess I would've if it was anywhere near as difficult as this guy claims...
I'm on android tho, while he uses iPhone, maybe that's the issue?
Compare "The IRC trashfire" (an article about the infelicities of Mirc)
I tried to get Matrix working to have a conversation. Many worthy people I know use it
But I failed in a similar way
Do many people actually use it?
When it is so easy to use Signal or (Dog help us, WhatsApp)
We're moving quickly to address the feedback in the blog post and will be investing more in docs and UX to address the friction.
Please don't hesitate to share your own experiences if you run into trouble! Stuff like that is a real gift. We're always looking to learn and improve.
Josh, Managing Director of the Matrix.org Foundation
I think Matrix has a lot of problems. E2E encryption is too much for most laymen users to work with and it being so damn resource heavy being the too biggest ones. But come on.
It's like when you use one of those Linux phones and your reaction all along is "ew". Do developers not notice how bad this is? No, they don't. Some of them haven't used a good UI ever. They can't fathom it could be better. They really think they are doing a good job.
Why did Discord win? Oh, it must be dark patterns, regulatory capture, moat, etc. It can't possibly be because the UI makes sense!
I don't know but the Discord UI doesn't makes much sense to me, this is a huge mess.
Signing up might be better though with the caveat that I never had any problem signing up with Element (not Element X for which I have 0 experience).
I would argue that as the one developing a system (frontend or backend) you can not perform something like that. The reason being that you already know all the small little bits, tricks, and band-aids. The only way to get proper feedback, is by putting someone completely fresh in front of the system.
I mean, when I hear "clickbait", I think "the headline makes me think there's something interesting that isn't really backed up by the content". But here? The headline says "Matrix Trashfire", the content delivers exactly that.
There are plenty of problems with Element and Matrix (I say that as someone who has been trying to migrate off Slack for 1+ year) but this comes off as the author just not doing basic reading.
Element sent them to matrix.org
MacOS app store only had element X, and also how is a user supposed to know to use the old one? Matrix.org tells me element X supports more stuff! The author says it's in beta but I can't see any indication that clearly tells me that and I'm looking for it.
> just gone to the Element home page
The app doesn't take you there.
But OK let's do that.
element.io
There's a big getting started button.
Now there's a form asking for my work email address and phone number and what challenges I'm looking to overcome.
> Setup a self-hosted or cloud deployment, with powerful enterprise capabilities.
To get started I need to not go to "get started" I need to go to sign in, which I can't do, then register.
The user should fall into the “pit of success” — no matter where/how they first enter the pages of matrix or element … it should be natural that they end up at the correct getting started for them.
Sure, the author could have prevented some of their problems by reading the documentation, but Matrix is trying to become a solution everyone can use. And noone wants to read a manifest only to send some messages.
But as as user, if you're even a little technical, downloading Element, registering and messaging your friends is really not the difficult bit.
Perhaps a technology will not have success if its users need to do basic reading.
Jokes aside, I don't think matrix/element, at this stage, are trying to overthrow telegram or whatsapp.
It seems their main approach is somewhat aimed at the people who use(d) IRC on the general audience side and institutional clients who they work with to create ad hoc solutions for employees, in which case which client to download is slightly less problematic since it's going to be a custom one anyway
It just so happens that right now it's easier to land with folks who are patient with sharp edges and already believe in the value of FOSS, E2EE, and decentralization. Gotta start somewhere, right? :)
IDK if you caught it, but the project lead, Matthew Hodgson, gave a main stage talk at FOSDEM a couple weeks ago and offered an update on the project and, in particular, on how we're taking advantage of the push that regulators are making for interoperability. WhatsApp, in particular, gets mentioned in this context and the writers at WIRED and Tech Crunch seemed to pick up on that!
It is ok that matrix the protocol and matrix the server software have a different name than element. But the official server instance used by element should not be matrix.org but element.io because that is where you have to sign up and log in if you want to use the default official instance. Otherwise you redirect clueless end users to protocol papers and server administration docs.
Do we need to test and simplify our onboarding? No, it's the confused users who are wrong!