[oddvar]

There is another option - matrix.org is a new open standard for real-time communication (with encryption) in an open, federated ecosystem.

That means you can run your own server and encrypt your own data, and the encrypted data can still be sent to other servers in the federation.

To your point about open source, if something like this can take off it needs to be fully open and transparent, without fees or central data ownership - which is why matrix.org is a non-profit organisation and the standard open source.

(disclaimer: I'm involved with matrix.org)

[derf_]

From the homepage: > Send and receive extensible messages with optional end-to-end encryption

Why would encryption ever be "optional"?

[ara4n]

Because we don't want client implementers to be forced to have to jump through end-to-end crypto hoops if they don't want to. The simplest way to send a message in matrix is:

curl -XPOST -d '{"msgtype":"m.text", "body":"hello world"}' "https://matrix.wherever.com/_matrix/client/api/v1/rooms/$roo...

...and we'd like to keep it that way. But you can always insist on only ever communicating with folks who are on E2E crypto clients if you so desire.

[derf_]

Is that the same way I can always insist on only ever receiving PGP-encrypted e-mail?

[Arathorn]

Not quite - as PGP is a pita to use, and not a formal part of the SMTP spec. So refusing to read non-PGP would be suicide. But if it was considered table stakes to implement the crypto option of the spec, and all the decent Matrix clients out there did so and sent end-to-end encrypted by default, then it'd naturally become the default. In other words, if you gracefully upgrade chats between capable clients to be end-to-end by default, everybody wins.

[derf_]

If you really believe that, then I feel sorry for your users. Privacy is a public health issue: https://www.theguardian.com/technology/2013/may/21/privacy-p...

In the absence of some forcing function, the trend is for it to get worse, not better.

[moheeb]

Back in the day it was often optional due to the additional processing that it required.

[derf_]

That was indeed a thing in the days before AES-NI or simply having 1.4 billion transistors on a chip.

But in my day we've been spending years fighting this sort of short-sightedness: https://www.ietf.org/mail-archive/web/rtcweb/current/msg0274...