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.
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!
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.
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.)
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...
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.
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.
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.
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).
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.
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.
With Matrix, I don't need to convince them.
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.
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.
- 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
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.
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.
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.
Element sent them to matrix.org
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!
Do we need to test and simplify our onboarding? No, it's the confused users who are wrong!
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.
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.
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.
> 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.
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.
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.
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...
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.
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 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.
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.
This is false.
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.
Disclaimer: I'm one of etke.cc developers
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.
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.
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.
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
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.
Cyber furz
In English:
Cyber fart
Every day is a school day!
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.
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 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
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.
- 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.
There is some complexity in educating due to its distributed nature, but a top notch UX is much needed to overcome it.
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 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.
