I agree. Telegram's UX is unparalleled.

Coming to Matrix, the Element Web/Desktop app is ugly and has bad UI/UX. Its unintuitive to use. Fortunately, you have tons of choices with Matrix. Cinny on desktop has a very neat and clean UX.

On Android, the Element app is good enough, but if not Fluffychat feels just like WhatsApp.

Matrix is an open protocol and anyone's welcome to build a front-end, inspired by Telegram, that your mother would be happy using.

Perhaps you meant the Element client?

I'd wager you cannot build a Telegram-tier frontend using Matrix technology. Element is evidence of that.

Clearly there's an axis with security on one side and convenience on the other. Tilting fully to either side results in a terrible experience. For me, Telegram strikes the perfect balance. Secure chats have fantastic privacy, while the UX isn't totally garbage. The trade-off is that chats are non-E2EE by default.

Signal's has the axis tilted all the way to the "security" end, so that the product is unusable if you aren't a technical expert already.

Could your mother figure out how to encrypt an email message using GnuPG? Absolutely not a chance.

Could she figure out how to send a message on ProtonMail that encrypts it client-side for her? Probably.

Signal is GnuPG. Telegram is ProtonMail.

> Signal's has the axis tilted all the way to the "security" end, so that the product is unusable if you aren't a technical expert already.

Wow, I really disagree with this statement.

> Could your mother figure out how to encrypt an email message using GnuPG? Absolutely not a chance. [...] Signal is GnuPG.

My parents are not technical people, yet they can use Signal. My siblings as well. I think the UX is approximately on par with WhatsApp (when I was using it).

They have done a great job when it comes to UX. Ultimately I would like to push them towards Matrix, but the UX is not here yet for most clients. Fluffychat comes close to it, unfortunately I'm experiencing issues logging in with my account (timeouts), so I can't recommend it yet.

> Signal's has the axis tilted all the way to the "security" end, so that the product is unusable if you aren't a technical expert already.

Sorry, just to confirm: are you saying Signal has worse UX than Element?

> Signal's has the axis tilted all the way to the "security" end, so that the product is unusable if you aren't a technical expert already.

How so?

What's wrong with Element's UX? It's improved an awful lot lately.

It's slow, very resource intensive on desktop, practically unusable on mobile, you sometimes can't join rooms and the client tells you some weird obscure Matrix error, you sometimes can't leave rooms, the moderations tools are quite poor, etc. etc. etc.

This is the kind of gotcha that is not a real argument, just a way to say that the mediocrity of the Matrix (or Element, or Potato, whatever you wanna call it) is okay so no progress is ever made.

Matrix is not a protocol, it's a product. Its openness is more like a public API to a product developed by one organization.

Disclosure: I work with real open protocols.

Could you define "real open protocol" vs "public API"?

If the former entails an adopted RFC, isn't it common practice to prove need via a product before proposing a standard?

Asking because I'm at work on a safer, decentralized protocol for email, TMTP.

Real open protocols are ones not coming from a single vendor / not controlled by a single entity. XMPP and email are open protocols, Matrix, Mattermost and RocketChat are not.

Didn't XMPP originate with a single vendor? And JMAP? Didn't SMTP also originate in the field?

Are you saying that the Matrix authors won't submit an RFC?

Speaking as Matrix project lead: we'd love to submit an RFC (or W3C proposal) once Matrix has sufficiently stabilised. Right now it's moving very fast though (e.g. we're about to totally change the sync API so that it's O(1) rather than O(N) with number of conversations).

In terms of contributions to the Matrix spec; from a quick eyeball at https://spec.matrix.org/unstable/proposals/, there are 95 different authors, of which 31 work for Element (the company formed by the original team who created Matrix). Or to slice it another way, there are 498 spec change proposals there, of which 358 were written by folks at Element (so 70%). Meanwhile the protocol itself is defined by the independent and neutral Matrix.org Foundation non-profit (https://matrix.org/foundation).

In other words, accusations that Matrix is entirely defined or controlled by Element are untrue - by the time we created Element there was already significant contribution from the wider community, and these days there are loads of other individuals and companies like Beeper, Famedly and even Ericsson contributing to the spec.

Edit: oh, and Rocket.chat is adopting Matrix too, which refutes the GP comment even more...

We all know that 'independent matrix foundation' will never oppose the will of the leading vendor. Don't tell me about how you agree to everything in your wonderful community, tell me how you resolve conflicts?

You and your company has all the leverage and no sane independent developer will invest in your protocol because he'll always have to play the catch up game.

An example of resolving conflicts is something like MSC2962 (https://github.com/matrix-org/matrix-doc/pull/2962) and MSC3216 (https://github.com/matrix-org/matrix-doc/pull/3216). Two proposals to solve the same problem, different ways. The first one was written by me; the second one was written by joepie91, who's a completely independent community member. Doesn't get much more of a direct conflict than this.

So, to resolve it, the spec core team (which is a mix of element employees and community members) went through the two proposals to compare them and concluded that joepie91's approach is better. So we're about to kill off MSC2962 and merge MSC3216 into the spec instead.

Please stop with all the disinformation - it'd be way more constructive to invest your energy into improving XMPP than trying to make Matrix out to be evil.

What you cite is not a conflict. It is a mild disagreement about the development of new features. A real conflict is when you have different entities with different implementations, and diverging views on how to develop the protocol, and the stake for the losing party is to abandon their investment in their existing implementation and starting over from scratch.

However, I already have the answer on how you plan to deal with such conflicts, you've said it yourself [1]. I'll quote:

> The idea on Matrix is that you say "Hi, I talk Matrix CS API 0.4" and be done with it - and you end up with much more social pressure to keep up to date with the current latest spec, because otherwise you are simply falling behind

If we say it in a less courteous manner, "Once we introduce changes, your independent implementation will be cut off from our network, and if you'll need several more months to implement changes, well, tough luck".

You see, I'm not saying Matrix is evil. It's a rather developed product, just like Mattermost or Flock. But a federated protocol it is not. Please stop advertising as such, and I'll have nothing to say about it.

[1]: https://news.ycombinator.com/item?id=19421978

Have you told this to the German Army and the French Police?

Because they seem to like it and, based on my experience with the military being able to run it independently is a major consideration for them even for smaller systems.

So what? Selling to such organizations tells more about the salesmen skills than actual merits of a product. For example, a lot of bigger and even more important organizations use Slack or Microsoft Teams, because a product they are sold works and does what they need.

On-premise software is nothing new. But the fact that some software can run on-premise and can interoperate between instances does not mean that it is a protocol. Mattermost can do that, is it a federated protocol too?