This kind of process is extremely valuable and should be done by devs more often. Start from the start and follow whatever your application tells you to do. Note down when it doesn't tell you where to go or what to do. You'd be surprised by just how many things you do automatically while working because you know the little tricks and things to get by, and that wording doesn't necessarily match what the app requires now.
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.
QA is a massively underappreciated position. A QA person that knows when to automate, when to manually test, and how to report and file issues relevant to the project can save a significant proportion of hours on a project overall. I wish many more companies included budget for QA, it saves developers a lot of time.
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!
Good QA people are hard to find and it's a weird balance to strike.
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.
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.
Developers are artists and QA is critique. Worse, you must entertain their complaining, and pay for the privilege! The vultures. (This implicit bias would explain the treatment disparity. But it's a baseless hypothesis. It just seems like the simplest behavioral explanation.)
It’s semantics, but thinking of QA as refinements rather than criticisms goes a long way. Everyone is reasonable until their mental defenses are activated I believe. I think it’s worth making even great efforts to communicate improvements or requirements without using phrases which make someone feel bad. If the goal is to actually persuade and make a positive impact rather than just point fingers to feel superior, finding the way to say things without assigning shame is almost always the way to get things done.
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.
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.)
From manager perspective, no matter what people do you have at start of the journey, the team culture can be changed. Most people are willing to learn something new and try new processes if they see the value. In more than 20 years I have seen maybe 2 or 3 pathological cases, where a person had to leave the team rather than play by new rules. It is not easy, it may take time for the team to adapt, but that’s a manager‘s job to unlock the potential of every team member and that job is doable.
The old wisdom in the US, is that if you have "Quality" in your job title, your career is over.
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.
I always give the power to my QA team to block any release no matter what and to give higher priority to tickets than product manager. If CEO wants to override, I cover them and take the blame. This is not a guarantee that there will be no bugs in production, but it saved us a few times.
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.
I worked with NTT Docomo years ago for a short time. First time I ever got to see a CMM Level 5 organization. It was insane. No wonder Japanese cars were so much better than everyone else for so long.
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.
Do you have any insights into why desktop and mobile software from these companies is so universally horrible? I’m thinking of Canon’s remote tethering tools, Fuji’s instax and remote control apps for iOS, and Epson’s scanner software.
I don't want to get into slagging these folks, but I feel your pain. In a big way.
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.
Hi, I'm the Thib person mention in this article, and I agree that QA is super important. I can mostly talk about matrix.org, since I have little power over the Element clients. Disclaimer though: I'm technically employed by Element (to make paperwork simpler since I'm France-based, Element has an entity in France, and the Foundation is UK-based), but I'm working for the Foundation full time.
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.
Hi, hopefully things came across OK, for clarity I wasn't saying "why haven't they done this, they're bad at QA!?!?!" but just wanted to say that most of us should be doing the same kind of thing with our own products/tools/sites and give a shoutout to QA peeps.
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.
Just wanted to add that I signed up recently and wanted my wife to sign up too. I managed to figure it out, but the article is correct. Even down to trying to figure out whether I should use Element or ElementX on iOS. I also realized that my wife would never figure it all 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.
If you're trying to make a good onboarding user experience then you should do your onboarding testing with people who've never seen the product before, not devs or QA. Once people are familiar with the product (devs, QA, and anyone who has used it before) then they're "tainted". They'll remember the weird way that they had to work around an issue, and that'll just end up being "the way it is" rather than something to fix.
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.
You can go one simpler if you need, you can use something like https://www.usertesting.com/ which will do the ad side of it for you. I used to do testing for them for some beer money. You'd use something for the first time and try and achieve some task, often talking through it, and it's all either screen recorded or it used to be videoed for phones.
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).
>This kind of process is extremely valuable and should be done by devs more often.
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.
> All in all, this is a mess, and my recommendation is to avoid Matrix for at least two years.
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.
This. I use Matrix daily using nheko for my client. It's a rock solid experience (except for a bit of trouble with voice calling one of my friends). I've never been randomly told I have to reverify. If you are being asked to relogin and reverify every time you restart your client, you're doing something wrong.
Depends on how you define "Matrix", I guess. The technology is undoubtedly great, but it also needs to sell itself as a (standalone) product if it wants to catch on.
But Matrix isn't a product. There are companies building products on it, such as Element and Beeper, and as far as I can see the latter are doing a perfectly good job of selling themselves.
That may be technically correct, but reality is if Matrix wants to catch on (large scale) as a concept, it needs to act as a product in some way. Even if that just means having a good landing page guiding users on how to sign up on a server, install a client, and connect the two - and making sure that this always works.
That's a very interesting thread, because this is one of the major issues we have with Matrix. It's not directly a product but a (technical) protocol that can't be presented as such to the general public.
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.
I think that's one approach, but many other federated systems don't do this. ActivityPub does not do this really, instead Mastodon, a product using ActivityPub, markets itself. Arguably you could look at HTTP and say that HTTP doesn't have a fancy landing page pitching itself to users, browsers have landing pages pitching their experiences to users.
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.
I wouldn't read anything into a name. For a start that's very language specific, but also there are plenty of non-user facing technologies with non-technical sounding names, and vice-versa.
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.
Yeah it’s unfortunate that they picked the “cool” name for the protocol, not the product.
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.
I tried to follow along with the author by going to the same pages and seeing the difference between what he should have done and what he actually did, and it convinced me that there's no way he was doing this in good faith (unless something has changed). I still can't figure out how he managed to get to some of the pages he described, when the thing that he said he wanted was clearly right on the page he said he was viewing before.
The fact that the official Matrix Mastodon account as well as the "Matrix Director of Program Development" agree with his assessment with the Mastodon account agreeing that it is a "trashfire" makes me sceptical of your suggestion that he was manufacturing these issues.
I mean, Element and Matrix are 2 separate entities, which is kind of the key problem with all these efforts - there have been plenty of posts about how hard it was to join a Mastodon instance, or creating 2 accounts etc.
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.
> But if he'd just gone to the Element website and clicked "get started", it would have just worked.
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.
You suggested it based on your assumption that the UX would be sane but now after being told that it isn't you are backtracking. As it stands, your original comment is now objectively wrong, because you made exactly the kinds of assumptions the blog post author was making: that the UX would be reasonable at each step.
agree, the author mainly complained about UX issues in the client, but then only tried one client it seems. Article should have been titled "The Element Trashfire"
> 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.
Well, they tried to use an open source ecosystem by finding an app in a store where devs need to pay to get their apps in. Maybe not the best combination
They wouldn't even know Matrix existed, most likely. They certainly wouldn't have found "Element" on their own.
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.
If one knows about Matrix/Element, it'll of course be from hearing/reading about it somewhere. And thus if they were just told "discussion is at #foo:example.org on Element" or whatever they'll clearly go for Element (and I've seen "Element" be used for "Matrix" a couple times). Though then at least maybe they wouldn't manage to pass the blame on Matrix for what is an Element problem.
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 mean, Element and Matrix are 2 separate entities
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.
Not only are they actually very closely linked, in that Element operates matrix.org, but to a new user (told to try Matrix -- what is this Element thing?) there's no difference.
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.
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.
> But if he'd just gone to the Element website and clicked "get started", it would have just worked.
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...
I really don't like the forced end to end encryption of chats. I do not care that much about the security of my chats to justify the complications of end to end encryption -- verifying devices, constant "reset" prompts that I don't even know what they do, but they seem like they are very destructive.
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 think matrix has group voice calls. But maybe I'm wrong and they're just using Jitsi.
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 (:
tbh the best thing about Matrix is that you have a hope in hell of actually federating it.
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.
Why centralization? XMPP users are identified with their JID in format username@server.example, similar to email addresses. And server to server communication is very well documented and major XMPP servers for instant messaging (ejabberd and prosody) both allow server to server message exchange. I don't see any benefits for Matrix when it comes to federation and I wouldn't agree with you that by using XMPP you tolerare centralisation at all.
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.
Voice/Video is an optional XEP and if it's not supported what happens to the client exactly?
"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.
In Conversations if A/V is not supported, you do not get a button to call them. The people I text most use Conversations, Monal or Gajim which are all independent implementations.
It's nice to hear I'm not alone. I use Matrix/Element to chat with Rust embedded devs; I have heard about it in other contexts; generally favorably. In my experience, it is awful, and has been for years. Highlights:
- 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.
While it's never fun to receive negative feedback, it'll only help to improve the product.
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.
> Lastly I think comparing an open source project like Matrix/Element to Publicly traded corporations like Slack or Meta, is not fair.
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.
Not sure we want to "win". If endusers want apps "to just work" without "paying up", then I would recommend them to stay with Whatsapp.
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.
> 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.
I'm very sympathetic to this line of thought in general, being in a similar position with our own project.
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.
> 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.
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.
Likewise, glad for these discussions. Even if it's a bit uncomfortable to be on the receiving end, this kind of feedback is a gift. Please do share more about your experiences, we're all ears and looking to learn and improve!
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
We also tried to use it, but frequently, messages will fail to decrypt with no option to retry. Threads is a mess, where messages will show as unread, but you can't actually see what message was unread.
Matrix/Element is so close to a great alternative to Slack, but in it's current state it's totally unusable.
> We also tried to use it, but frequently, messages will fail to decrypt with no option to retry.
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.
This just sounds like a description of Matrix's key sharing mechanism? Messages are supposed to be unencryptable if you don't have the keys, and bringing online another device (or having all your keys pre-shared so you don't have to) is what provides the keys. If you want to avoid this altogether, the UI prominently advertises the optional encrypted key backup service provided by the homeserver, and various manual options for sharing keys.
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.
A bit late to respond, but this is not an user error. From the bug description it SEEMS (because there's still zero feedback from the dev's front) that it's Element itself failing to send the keys in the first place, probably due to a mishandled connection/transmit error and not attempting to retry. It's not a protocol error, unless you count the fact there isn't a mechanism in place to ack at least asynchronously that decryption is ok.
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.
> messages will fail to decrypt with no option to retry
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".
We used Matrix for a couple of years at my company, but got kicked out from their managed hosting due to the new requirement of 50+ seats. The years we've been using it has been more of tolerating its flaws than a pleasant user experience.
We migrated to Slack and was blown away of how It Just Works.
Matrix and Element are no longer the same entity. Element (New Vector Ltd) is the core behind the Matrix protocol, but they're distinct from the organisation that manages the protocol.
If Matrix does ever take off, this will be an extremely valuable distinction to have.
I understand that completely, I even considered including a "Before anyone jumps in with 'akshually that's Element', [..]" disclaimer but decided nobody would be that pedantic.
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.
The people working on Matrix also have quite a few contributions from Beeper, which has little incentive to make Element popular (after all, they'd lose customers to their own service!).
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.
And yet Thib, mentioned in the article, does say in an another comment that they are employed by Element but working for The Foundation, making it quite hard to know the difference between the two: https://news.ycombinator.com/item?id=39369239
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.
It's hardly a secret that most people working on/for Matrix are employed by Element.
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.
Another option is https://etke.cc - truly FOSS managed hosting, both on-premises and cloud, huge list of supported components, priced by complexity, not users.
I'm talking daily with friends on Element. Most of them don't work in tech, but are quite comfortable with computers.
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.
> Signal conversations can become such a mess because of that.
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.
But I won't create a new group to for example talk about a video.
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.
In practice I just skim through these 10 messages in such small groups. There's the opposite problem with threads, with which it's easy to miss messages you care about, and harder to have a single topic at a given time. Being able to reply to individual messages also makes the transition from one topic to another smoother.
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.
Fantastic writeup. I’m a little confused by the screenshot with the caption “Servers marked as vulnerable, unavailable and with profanity in their name.” In the screenshot, three things are highlighted: labels for “Vulnerable”, “Unavailable”, and the server name “cyberfurz.chat”. Is “cyberfurz” supposed to be profanity?
Note though that this is not a regular user, but an old school blogger with deep database experience and afaik programming skills, at the very least someone highly technical (and known in Germany). He is just able to put his user hat on -> regular devs can do that too.
Yeah, that's a good point. When I put my user hat on, I try to force myself to not know things (conciously ignore them if I can), but I think it's not a "natural" experience like an end user report. Still, better than automatically doing what will work.
Honestly, the matrix documentation is a total mess in general.
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.
Indeed the documentation generally needs much more love. In an ideal world, every single page of the documentation would have a person in charge of keeping it up to date.
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.
Cinny is the Matrix client that copies Discord's UI. My friends and I use it as the default web interface for our private server, no complaints (other than the fact that it makes you appreciate Discord's sometimes-annoying "join all channels by default" feature; the opposite, classic IRC approach of forcing everyone to search for and manually join all channels scales better but is an absolute disaster for discoverability on small-to-medium servers).
This bothers me just as much in Discord as it does Slack/IRC. Has any chat software figured out this problem yet? Surely there must be some middle ground, like optional channel categories or something.
The discord solution is to hide channels behind a role, put a message in the welcome page with emoji reactions, and run a not to assign the role to anyone who clicks on the emoji. Only downside is that its publicly visible and very jank.
I wish they had a built in way,
& also some way to make channels line bot_commands default to muted
A friend wanted me to switch to Matrix for our 1:1 conversations and group chat of 3 people. The onboarding and user experience have been very poor on Element for years. I'm left with the feeling it is not made to replace a 1:1 messaging app.
The protocol covers a broader use case, and the end-user apps are buggy and have a confusing user experience.
There is some complexity in educating due to its distributed nature, but a top notch UX is much needed to overcome it.
Running an XMPP server is dead simple, just install Prosody and make few simple edits to the configuration and you're set. It hardly takes any resources (32 MB resident on my server) so it can happily live on whatever server you're already using. You will want to add some records to your domain to make it all run smoothly but this is well-documented and even works fine on free DNS providers like Namecheap and Cloudflare. Once you've done that you just install Conversations (from F-Droid, of course) and something like Gajim or Dino-im on your laptops and you'll bask in the glory of evading the surveillance dragnet because you're using OMEMO encryption which works end-to-end.
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
My father is dead so I don't think I can reach him through XMPP - at least not yet. My 85 yo mother is still alive and yes, she is using Conversations on her Samsung A25 which connects to prosody on my server through which she communicates with all of us. I live in Sweden, she lives in the Netherlands, one of my daughters now studies in the Netherlands as well. We have a 'family list' (i.e. a 'multi-user chat' using the muc extension) where we share photos and anecdotes, sometimes we 'talk' one on one. Everything encrypted through OMEMO so Feind hört NICHT mitt.
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'.
The first time I did this exercise was in 2018 (when I first set up an XMPP server and Matrix Synapse for Communick) and there simply wasn't any working iOS app. Monal was the only app I found and managed to install for him. It did chat only and would crash. I do not recall to get e2ee working and the fact that it is optional made things confusing even for me - e.g, I wasn't able to switch between a desktop client and Conversations easily.
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".
The problem here is not XMPP or Conversations but the closed nature of iOS which keeps apps like Conversations from being ported there. Apple does not like competition to iMessage or to its app store revenues so it fights tooth and nail to keep its precious as is now clearly on view in Europe with their ridiculous 'core technology fees' and other shenanigans.
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.
> Maybe you can give your father a non-iOS phone if that is what is keeping your experiment from succeeding?
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?"
Having set up and administrated both an XMPP and a Matrix server, XMPP is way less a pain in the ass. I've enjoyed dealing with prosody much more than either synapse or dendrite. XMPP doesn't tank my server every time I try to join a new room and it doesn't take forever to start talking in a room after you join it. And provided you're running the server, getting people onto XMPP has not been hard in my experience. I made a basic registration page with simple instructions. I have gotten people with low technical know-how to successfully register accounts and use it without issue. They just create an account, enter their username into a client I recommend, and they're ready to go (I've never even had them complain about OMEMO).
If you go through your contact list right now, how many people are on iOS, and how many of them do you think you could successfully convince to use XMPP as the primary method to reach you?
I don't know iOS users, except one, who already used XMPP. Most people I talk to on a regular basis already use it. The ones that don't either don't bother with apps at all (my grandparents), or are not close enough / frequent enough contacts to bother with anything beyond SMS.
Oh sure, but it's still a counterexample to your statement. I can convince people to use XMPP, and almost nobody is using Matrix if you don't do the convincing.
The big usability issue with Signal is that it has a dark pattern that leads to most users using it without verifying that they are actually talking to who they think they are talking to. If you do verify a particular contact's identity it involves comparing a 60 digit decimal number. The 7 emojis seen in the linked article are arguably better but a short decimal number would have been good too and would have eliminated the issue that the emojis don't look the same.
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.
I am not sure how you would get the 60 digits from the other person in your clipboard.
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.
If verifying these digits make any sense, that means you already have a trusted channel you rely on to communicate these digits. You would use that trusted channel to transfer these digits. How do you want to communicate them?
> 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.
Typically people would compare identity numbers over a voice channel. A sort of biometrics. It's been suggested that Signal add a voice channel feature for that purpose[1].
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.
I find that XMPP interoperability (terrible as it is) is still just miles ahead of Matrix. For all intents and purposes Element controls the protocol and despite that I almost constantly find friction communicating the client for Android and the desktop Electron-based client. With 3rd party clients it is a nightmare.
When https://siskin.im/ is seriously touted as the best iOS client for XMPP, you already lost 50% of the market share in the US. And if you don't have any usable app for 50% of your users in one of the most important markets, you can not really claim "interoperability", can you?
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.
No, I don't have any problem about claiming interoperability in this context as it is completely orthogonal. You could also claim that not having animated gifs also makes it unusable for 99% of the population (an statement I might even agree with) and it would be irrelevant to interoperability.
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.
> iOS simply sucks here and lowering down your pants to marry yourself to the whims of these insane "platforms"
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.
> 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.
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.
> 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.
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?
At best it can be described as a "hacker's idea of a functional mobile app". The UI is crude, antiquated and not at all following the Apple guidelines.
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.
- 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
My goal is "let's have a communication protocol that is secure, enables applications with modern features on all major platforms and is not controlled by any single entity".
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.
Interestingly Delta Chat kind of fits the bill thanks to their investigation of webxdc, i.e. mini apps that run entirely within the chat and never connect to the outside world, only with peers in the chat: https://webxdc.org/
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.
Huh, I've been using element for a while now, and the only problem I've encountered is that quite few of my friends use it. I've joined a few communities based around common interests, and never really had any technical issues with anything.
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?
Never used Element on iOS however on Android its... Ok. Not great, not terrible. Recently it's slower in loading chats in rooms and overall responsiveness is sometimes laggy. Desktop experience is without any issues.
I have been using matrix from time to time to chat with some folks who prefer matrix over other chat systems for reasons unknown.
Matrix is an absolute trash fire indeed. Every once in a while a chat session with someone just craps itself and my client is unable to decrypt received messages (both element and element x). The issue then usually fixes itself within a couple of days. The bad UX aside, a chat system should at let me reliably send and receive messages.
The other issues I had were related to the device verification. The last time I wanted to verify a new phone the verification request simply did not arrive on my other devices. At that point I gave up on matrix.
We definitely have work to do on the onboarding experience, but I'm pleased to say that there are 115M addressable users on the open federation – so many people are having great success once they get past the initial friction. Aside from all the FOSS projects that use Matrix, it's also used by the German healthcare agency, French civil servants, NATO, a number of universities including MIT and TU Dresden, Moodle, and many others.
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
Matrix protocol with Element on my own Synapse Docker container has been working great for me for two years at this point. Not really had any issues with it, whereas maintaining other solutions like Rocket.Chat became a real time-sink prior to switching to Matrix.
Pretty poor post. It highlights some issues, sure, though the author obviously never tried to actually try. Also, they say there's profanity but I don't see any; apparently the word "cyberfurz" is profanity? The author's prejudice is showing.
Unless I read it wrong, the author chose element x because it was available on all platforms. It looked like element wasn't available in the Mac app store
This is just stereotypical ineptitude and inability to RTFM or use common sense from somebody used to the spoonfed walled garden side of tech. I do not understand how anyone with a background in technology can't know "beta means buggy and poor support and use the flagship instance if you don't know what you want". I understood this as a teenager, as most people here also should have.
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.
Developers could also do these processes. And they probably do, often. But they usually have their heads so far up their asses that they don't see how inscrutable this onboarding process is even for very technical users.
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!
Nowadays companies win because of better marketing and then network effect. The quality of the product does normally not play a big role for capturing a market
> Developers could also do these processes. And they probably do, often. But they usually have their heads so far up their asses that they don't see how inscrutable this onboarding process is even for very technical users.
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 feel the "clickbait" accusation has a tendency to be overused.
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.
"Trashfire" is absolutely clickbait. The article lays out some poor onboarding documentation for a hypothetical 100% naive user. Matrix, Element, etc work and they work pretty well. The onboarding workflow for most Federated services don't suffer fools. There's nothing exceptional here.
I mean, this is quite silly. Matrix is the open-source network infrastructure, Element is the client. Of course if you go to the Matrix web-page, it's not particularly user-friendly - if you expect to just use the thing, you should be going to Element. The ActivityPub page won't exactly help you sign up to Mastodon either.
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.
I disagree. I have been using Matrix with Element as my main IM with my own homeserver for 3 years now, and the onboarding experience is just bad. You have to read so many texts which are spread across so many pages just to get stuff to work and even then sometimes it just won't.
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.
Honestly, on this I totally agree - hosting your own Element/Matrix instance is really unnecessarily painful, with the documentation all over the place. But hey, it's free and open-source.
But as as user, if you're even a little technical, downloading Element, registering and messaging your friends is really not the difficult bit.
Things like this are technically correct but irrelevant. If the average person can't figure out the UI & flow without getting frustrated then it's game over.
I'll happily admit the Element/Element X migration they're currently on is silly and unhelpful, but the point being if they'd just gone to the Element home page, or download the actual Element app instead of the X one, it would have perfectly happily registered them to Matrix.org by default and everything would have been just fine.
> or download the actual Element app instead of the X one
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.
You’re missing the point. He’s following a reasonable user flow. If he went to the wrong place in the beginning, that confusion itself is a problem that the Matrix community needs to address.
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.
A chat platform for the illiterates might not be the best business proposition
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
As the Managing Director of the Matrix.org Foundation I can assure you I'd love nothing more than to displace centralized, proprietary communication tools.
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!
You literally just install the non-beta client and register an account and then log in. It's that simple. I'm impressed that anyone could get this wrong and then blame the program.
My grandmother could use Matrix when she was starting to develop dementia. The only thing that tripped her up was the end to end encryption and key loss. It's not a UX problem, its a PEBKAC issue.
I think the core of the problem is the naming separation between the default client and default instance.
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.
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.