> Encryption is still opt-in and beta

This is the part that concerns me.

https://whispersystems.org/blog/the-ecosystem-is-moving/

Moxie lays out a challenge to federation enthusiasts to prove him wrong that federated chat can be secure and have good usability. I would respectfully note that Matrix seems to be responding to the challenge with a chat client that is neither. Instead they seem to be doubling down on federation and integrations. Usability can be fixed, but the federation and multiple clients makes it a challenge. Security on the other hand is, again, concerning because it feels tacked on. It's not on by default because, again, it makes it complicated when you have multiple clients. Last time I tried, you could put in your password on the web client (browser encryption!) and join an existing conversation, and see all future posts by the people in the conversation, because suddenly they've accepted your new public key. I had to dig a little bit in the configs to find the current public keys for the clients in the conversation. Either they have to make a UX-friendly way of warning everybody that there's a new client, or accept that stealing an account password will let you snoop on conversations. I really appreciate their enthusiasm, and I hope someone gets federation right, but it just seemed like a mess.

By contrast, I think that Signal recognized that you can work around the security vs usability tradeoff by trading off on a third vector: feature set. I think that we won't get a federated system until someone heeds Moxie's warnings and does some careful, creative thinking.

> It's not on by default because, again, it makes it complicated when you have multiple clients

This is simply not true. The reason it's not on by default is because we're still developing it and it's in beta. It's not tacked on; we've designed in E2E from the outset - but implementing it well in a decentralised manner is a huge amount of work; probably 5-6x more than in a centralised system like Signal. We're not going to enable it by default until we are 99.999% sure that it won't cause regressions over the non-e2e client.

> Either they have to make a UX-friendly way of warning everybody that there's a new client

I think you must have tried it a (very long) while ago - we've had the UnknownDeviceDialog since February. It looks like this (https://matrix.org/_matrix/media/v1/download/matrix.org/mOOj...), and warns you every time a new device is added to the room, and gives you the option of blacklisting it from receiving your messages if you don't trust it.

Now, totally agreed that this UX is ugly and needs work, but this is NOTHING to do with the decentralised or federated nature of the protocol. It's simply that we currently are very resource constrained currently for working on web front-end issues.

That said, if your ONLY priority is security, then Moxie's "the ecosystem is moving" probably has a point. After all, in an open ecosystem like Matrix, it's possible someone will fire up a buggy/malicious client and inadvertently compromise a room. However, if you value freedom as well as privacy, Matrix or OMEMO are basically your only choices.

> This is simply not true.

Alright, you make a convincing case that it's not tacked on and I'll give you the benefit of the doubt here. Unencrypted basically is just "dev mode".

Very glad to hear you patched up the hole with the unknown clients. Perhaps I'll try again down the line.

> Now, totally agreed that this UX is ugly and needs work, but this is NOTHING to do with the decentralised or federated nature of the protocol.

Well you have to design that dialogue that tells you new devices came on, right? And you have to deal with cases where some people accept a new client and some don't. And you have to explain to lay people what the heck an IRC bridge is. And so on. My point is just that you have a lot more things to explain to users, so you have a lot of UX work ahead that you wouldn't otherwise have. So I don't think it's unrelated. (Aside from the issue of explaining things, it's not particularly ugly actually, from what I remember).

> it's possible someone will fire up a buggy/malicious client and inadvertently compromise a room

I appreciate that you acknowledge that. It signals that you have things in perspective.

I actually think some people do consider freedom to be a security issue. They don't want Signal servers to go down, or get into malicious hands.

Also: Nothing strictly stops people from using rogue Signal clients either. There's just social pressure deterring it. By that same token, perhaps you could use social pressure to deter developers from lying about what client they are, and then have a vetting process for secure clients. And then warn users when an insecure one comes on. (And perhaps count web as "not recommended for especially sensitive discussions")

Anyway, thank you for addressing my points and accepting critique. I do hope to see you succeed.

> After all, in an open ecosystem like Matrix, it's possible someone will fire up a buggy/malicious client and inadvertently compromise a room.

Isn't this a case for building in some kind of system whereby clients can be signed and have their signatures revoked by their creators or, for lack of a better word, ostracized by the wider community? Sort of like a web of trust model, but for clients, not just users, to make it more clear when somebody is joining with an untrusted client and perhaps allow moderator control over whether to allow untrusted clients to join.

Possibly, but this is heading into seriously DRM territory. one would need to be running the app in some kind of secure enclave that could attest to the authenticity of the app (e.g. via SGX on Intel). There's something a bit unsavoury about saying that "only truly official signed apps are allowed to participate in this open network", and it gives a huge amount of power to those responsible for the secure enclave/trusted computing stuff. (There's also the approach that djb mentions in https://twitter.com/hashbreaker/status/732912508089032706)

It's possible that just relying on social mechanisms may be enough to discourage people from running known evil apps (similar to educating users not to install malware today, or do trusted operations with cybercafe computers, or whatever). Effectively, the verification process when going and explicitly trusting a new device needs to explicitly prompt the user to consider where on earth this app came from, and if it should be trusted.

The only alternative is really DRM, which just feels wrong.

>There's something a bit unsavoury about saying that "only truly official signed apps are allowed to participate in this open network", and it gives a huge amount of power to those responsible for the secure enclave/trusted computing stuff.

Maybe it's a bit naive, but isn't that what federation is supposed to solve? People who are more security-paranoid can forbid clients which don't have the highest security certification, and operators who aren't so diligent will be fine with signed clients being run on untrusted hardware.

I mean... is there any open-source software being developed today which enforces key security in secure hardware enclaves? Verifying the GPG signatures on binary packages is "good-enough" for most operators. Build reproduceability will help to further reduce trust of unverified hardware.

It seems to me the job of the protocol, and baseline/recommended UI/UX, is merely to help users make informed decisions. Security is a spectrum, and if signed clients improve security (while not fraudulently representing itself as perfect or near-perfect security, if it were running on trusted hardware), then that's a net benefit to the open network.

I may be missing something, but how do you prove that an app is running a trusted codebase? I know of no PGP clients for instance that sign messages to try to prove that they were sent from a trusted app (as opposed to a trusted user). The only way I know of to do this would be to hook into a trusted execution environment of some flavour like Intel's SGX or Apple's Secure Enclave, to let effectively the chip vendor sign off that you are running an official app installed by official means. You /could/ do this, but you are putting a lot of trust in the secure enclave implementation and those controlling it, and essentially putting all your eggs in one basket. It might also lure users into a false sense of security: just because a user is using an appstore signed copy of an app doesn't mean that app is actually trustworthy or bug free. And it would also artificially discriminate against legitimate apps which aren't part of a trusted execution environment, which seems dangerous - and effectively promoting DRM at the expense of FOSS.

This certainly needs more thought :)

We're working as hard as we can on improving Riot's UI/UX and getting crypto out of beta. As others have said, partnerships like this help fund the team to get the core stuff in place. After all, this project (assuming the campaign is successful) is 2 months away anyway.

What's the value proposition of building a whole new client? If your goal is to give people a client for your cool new protocol, why would you waste any development resources on squashing fiddly UI bugs of your own doing, rather than, say, providing a reference implementation by forking the Signal app and swapping out the pieces until it's talking Matrix instead of TextSecure?

I see this mistake constantly. The ring.cx folks did the same thing. Inevitably, everyone ends up commenting how poor the app is—some of them even saying how much they'd like to be able to use it and would if it weren't for the UI. It wouldn't be so silly if there weren't plenty of essentially ready-made solutions for the problem.

1. Signal doesn't have a native Linux app (other than Electron)

2. The hope is to piggyback on one of the existing native Matrix SDKs or clients rather than write a whole new one.

3. One of the biggest complaints we hear about Matrix is that there is no native desktop app with parity to Riot yet. So this is our chance to fix that.

> Signal doesn't have a native Linux app (other than Electron)

How is that an explanation for directing (apparently limited) resources into riot-android?

> there is no native desktop app with parity to Riot yet

Huh? The comparisons I made in my comment were to Signal and Ring, which are predominantly mobile messaging apps. The person you originally responded to was discussing Matrix on mobile. Why do you keep mentioning desktop? If there were any confusion, this is a thread about an announcement for a new smartphone.

Riot/Android doesn't run on Linux, so directing limited resources into it is fairly irrelevant. The point of this campaign is to fund us to work on a native app which can benefit desktop and handset users alike - whilst also supporting the core team so we can also work on the React, Android and iOS SDKs which power Riot. I keep mentioning desktop because this is a significant benefit of the campaign.

The idea of somehow ripping out the core of the Signal or Ring apps and trying to bolt their UI onto Matrix SDKs is an interesting one, but in practice both protocols have significant differences to Matrix, and at best this would be a pretty big impedance mismatch. Of course, someone in the community is welcome to try to do it. Meanwhile, we'll keep plugging away at trying to make Riot kick ass (via the underlying Matrix SDKs), and add a native app to the pantheon too :)

> this is a thread about an announcement for a new smartphone

The smartphone in question runs Debian.

I think the whole point is elsewhere - get the UI/UX right. People forgive many things, but bad UX is not among them.

That said, I am excited about this - I love idea about pure OSS phone with hardware kill switches for mic and camera!

Matrix is really struggling on funding so they need these kinds of partnerships to allow them to continue making the software better.

For those who are reading this and would like to help out please see the following blog post: https://matrix.org/blog/2017/07/19/status-update/

>The Riot app in my experience has a pretty unwelcoming UI/UX experience and is still insanely buggy.

I've setup my own Synapse server on a VPS and have my extended family of 12 people including an 85 year old grandmother using it on an iPad. It gets used daily for chat and picture sharing. I've come across a few minor problems on iOS, but overall I don't agree with that characterization.

I think, homeserver software is also still somewhat immature. I'm waiting for Dendrite.

I'm evaluating Synapse (as all the other servers say they're pre-alpha incomplete) for the last week or so, but one immediate issue I had is that when I had set it up, on my home low-power NAS it required more than 15 minutes (and 0.7GiB of memory out of 1GiB I've allocated to the container) at fully-saturated single CPU core to join #matrix:matrix.org. And it took no less than a minute to join a room with just 200 participants. Sure, that's just for the first time, but it still feels way too resource-heavy, compared to other chat systems.

The machine has 10-year old Atom 330 CPU - which makes it an ancient relic, but hey, it has more than enough power to run XMPP (w/various transports), mail and web servers, and it just sits on a shelf in a kitchen, with a barely audible humming.

Synapse's readme does try to spell out that it requires at least 2GB of RAM and a recent CPU. It is absolutely resource heavy, but not showstoppingly so in general. The comparison with XMPP is dubious as the protocols are completely different: it's like comparing a local filesystem with a distributed database and complaining that the DB is slower.

That said, Dendrite should improve things a lot; we should have more stats in the near future but it seems to idle around 150MB of RAM and should run much better on ancient hardware. We are not bothering optimising synapse much further in favour of focusing on finishing Dendrite. Needless to say, we expect Dendrite to be finished well in time for the Librem 5 to go live, 18 months from now!