What are we fighting about again? Who’s right and who’s wrong? Whose views are the absurdest? Who’s got the better arguments? Who’s better at misinterpreting the posts if the other?
How does that answer or help the OP? How does that contribute any valuable information, help gaining new insights on the matter?
All questions originally asked (why no official Signal client) have been answered. Stop throwing sand at each other, please.
Well, matrix is federated which is a completely different kettle of fish. AND matrix uses some of marlinspikes algos (albeit OLM and co. are derivative, they are derivative!).
I’m not sure if or how the fediverse will ever get a foothold, but then, the world wide web was once ‘boundless’ 
And you’re right about the FUD. Even if you don’t trust Moxie (never trust a sailor, dude, oh irony!) it’s all happening in the open.
OH, maybe I’m out of sync. I’m working on a matrix deployment (and mattermost, sigh) and am running into other problems (matrix clients rarely implementing end to end crypto properly). And at the end of the day, the people I service ALL use signal.
We do, however also have XMPP with OTR which is quite good. The problem is that I cant’ (even with QT > 5.12) support all clients (mac os, anyone!!!). Does anyone know of a slack like interface that rests on XMPP???
This is a plea!? I’m running a bunch of parallel infra and am starting to believe I’m simply going to fail to improve users lives (workflows). The mainstream will simply run teams/slack/mattermost and ROLL over us.
It’s kind of sad. I’ve been doing messaging support (among many other things) for 20 years and we’re not really any further … personally being fine with XMPP (or irc) doesn’t cut it with the amount of staff I have to support.
???
E.g., federation would make it impossible to “ban” client apps, to threaten people etc.
But “Yes”, in un-federated networks, there is way too much power at a single point: the central node.
Federation can be dangerous vis. privacy. The journalists I work with i keep away from federated systems for certain communication streams because federation opens up attack vectors. And leaks information.
In one context it’s a leak. In another, it’s a connection. At small enough scale, centralized means free. C’est la vie!
@poetaster, this is an interesting statement:
“[…] federation opens up attack vectors. And leaks information.”
I would have ignored it, if it would not be from somebody with profound technical knowledge.
Can you please point out the fundamental mechanisms which make “federated systems automatically resulting in attack vectors and information leaks, which centralised systems do not have.” in your opinion.
I would then try to map these arguments to XMPP with OMEMO (and / or Matrix), to see if they apply.
With any federated system, like XMPP or matrix you have, in addition to client to server communication, server to server communication. As with mail systems that may at different times support different levels of encryption (or none at all) connecting these is always a hazard.
That alone is one large attack vector.
For some periods of time systems may be out of sync (one matrix server, written in GO is ahead of one on a newer kernel while another matrix server implemented in python is running on an older kernel …).
Sometimes, to permit people to communicate, you have to drop the level of encryption you support for certain server 2 server connections. I’ve been forced to do this with XMPP in the past although it’s thankfully happening less and less.
With mail it’s still a crapshoot. Right NOW I’m not allowing any non-encrypted communication on one of my mail servers. That’s an exception.
With XMPP clients we have had an end to end encryption mechanism in ORT (off the record) for some years that could be used on all operating systems (well, not sure about SFOS?!). The attack surface against ORT, however, is a lot more open when you federate XMPP (or matrix for that matter) simply because an attacker can begin with probes that would not be possile if the XMPP server was only a central service for a limited group of clients.
Federation also requires a larger code base. Server 2 server functionality adds complexity increases the risks…
yada, yada, yada 
But, I honestly don’t know how far matrix has come with libolm and their take on the signal crypto 
Fair point, as federation by definition means that you are open to connections other than authenticated clients as well. Still, I have more problems with centralized services which handle all communication. You don’t have an option to choose a provider in a more trustworthy location, or host it yourself with extra hardening / firewalls if you like.
I don’t know enough about the matter if a centralized service is a pro or a con for intelligence services. If you’re on a small provider on a federated network, there’s less “noise” on the line. At the same time, it might be easier to fly under the radar in a federated network. Matrix uses default https, and afaik only https.
Regarding intelligence services: just a week or two ago, both Dutch general and military intelligence services were slapped on the wrist again by the oversight committee for overreach of their methods. That oversight committee is only there because of a referendum on a law which extended the allowed methods used by the intelligence services - the outcome of the referendum was against the law, after which the law was slightly modified to include a oversight committee. (After that referendum, the government passed a law ending the right of referendum. 
) My point: even in functioning democracies, intelligence services seem to ignore the law as they please.
Of course, I’m talking about a scenario where you have a choice of provider. Actually, I’m talking about being responsible for the infrastructure.
For me this thread has been helpful since I only realized while testing and communicating here that the federation identity requirement was ‘now’ optional. When I first ran tests for our staff, this was not the case (2 years ago).
So, I would definately say matrix as a server / protocol is a great way to go. The only problem at the moment is clients.
We will not use the electron clients (the browser based ones) since those are a nightmare to audit.
In sfos I’m only (thanks rubdos!) using signal since none of the matrix clients do the crypto. Oh, and I’m using xmpp (but only for non essential dialog).
Although I doubt I’ll find the time if I keep this (ahem) up, I’d like to port https://github.com/mirukana/mirage for SFOS … it’s really nicely designed and does proper end2end …
And of course the BND here in Germany (and all the other services) when not igoring the law are being empowered by the so-called ‘chrisitan’ democrats. It’s a bit odd at the moment. Luckily, the services are understaffed and tend to use hired guns. And those are all well know quantities!
Oh, I see, this is all historic “yada, yada, yada”. ;\
Side note: XMPP-OTR is not really usable, outdated, and also has non-optimal security properties.
It only makes sense to compare modern protocols, providing E2E-encryption based on the “double ratchet” cryptographic scheme, i.e. XMPP-OMEMO (about 10 years old) and the Matrix protocol (newer, but fundamentally the same).
Some protocols of centralised services also use the “double ratchet” cryptographic scheme, e.g. Signal.
Yes, the metadata of communications is still distributed over many servers.
But that is the case for the centralised services too, as they only appear to be a single (logical) server (address): All bigger players distribute their servers geographically for load-balancing and fail-safety.
P.S.: If you are looking for a trustworthy, modern chat system with multiple, well working, FLOSS client and server implementations (plural for both!), there is only one: XMPP (“Jabber”).
You might want to take a look at the XMPP-clients Conversations (Android), Dino (GTK, Unix/Linux), Gajim (Windows, MacOS, Linux), etc. and the XMPP-servers ejabberd and prosody. For sure there are many more, but most of them are not in a production-ready state (as you already experienced with the Matrix client and server).
Plus there is a lot of documentation, many running servers to host one’s account, a large community and the biggest user base of all non-centralised chat-solutions.
The way you wrote this makes it sound like Signal is just doing what everyone else is doing, whereas what is really going on is that everyone else is adapting Signal’s cryptography to their own specific needs.
Bingo. I tried to make that point but you did so more elegantly!