Really glad to see these discussions happening. 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 succeed…
The Matrix Trashfire
211–217 of 217 posts
Re: The Matrix Trashfire
#212We 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.
If your company ever considers going back: https://communick.com/services/matrix
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.
Disclaimer: I'm one of etke.cc developers
Re: The Matrix Trashfire
#213This 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…
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…
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).
Re: The Matrix Trashfire
#214While 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…
> 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.
Re: The Matrix Trashfire
#215Pretty 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.
Furz means fart in German.
Okay. Even then I wouldn’t call it profanity
Re: The Matrix Trashfire
#216Earlier quoted context omitted.
>Good QA people are hard to find 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 i…
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.
Re: The Matrix Trashfire
#217Earlier quoted context omitted.
> 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 fix…
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 op…
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.