It looks like Signal isn't as open source as you thought it was anymore

It's practically a principle of the Signal project to discourage third-party clients. Signal's security work is done, for obvious reasons, mostly clientside. If you have a diversity of clients, you're stuck with the lowest common denominator of mainstream clients. Without them, you can roll out any feature you want to.

>If you have a diversity of clients, you're stuck with the lowest common denominator of mainstream clients. Without them, you can roll out any feature you want to.

This only matters if you cared about backward-compatibility. Otherwise you can just push breaking protocol changes without regard for third party clients.

And the users of those clients will say “Signal is always breaking” and switch to another platform.

While I can understand not wanting a diversity of clients for the support headache that could rapidly become, I don't fully agree that a diversity of clients forces them to be stuck at a lowest common denominator. What prevents them from making the breaking changes necessary for security and features, and letting the devs of 3rd party clients successfully conform or not?

I see it as something like mandating minimum version of TLS or cipher suite. The security flaws of TLS version <1.2 have been documented for some time now. I've had to tell customers more than once we are disallowing use of older insecure protocols to access my employer's services.

Or am I misunderstanding you and actually happen to be agreeing?

You can't just have security features not implemented on some clients; you have to actively break them. The simplest thing you can do there, versioning the protocol to indicate compliance, is easy for developers to work around. Users will stick with the client that has their preferred UX (really, in practice, they're going to stick with whatever the first client they got working is, because users hate installing stuff). It's a total mess.

I can't blame the Signal project for wanting to avoid it entirely. You can of course disagree!

> What prevents them from making the breaking changes necessary for security and features, and letting the devs of 3rd party clients successfully conform or not?

This _is_ the support headache, not a workaround for some other straw man support headache.

The scarier outcome is that they continue to use clients that lack security controls because the client continues to work well enough for them. Look how popular Telegram is.

So why doesn't Telegram have the same issue? Just like Signal, the client is fully open source and most of the secure bits are client-side, but unlike Signal they make no pretenses about being "fully" open source as they've never published any server sources, nor they make hostile moves towards blocking third-party client interoperability.

The problem is you can never make protocol breaking changes or add mandatory features. You might think "well just do it anyway and ignore people who complain about third party clients breaking" but in reality you can't ignore them. You end up with lowest common denominator. You end up with IRC basically.

Look at what happened when that Python crypto package added Rust support and broke some obscure platforms that nobody uses and were never supported. Geek outrage!

In comparison, Telegram offers APIs and libraries that allow you to create clients for any platform [0].

[0] https://core.telegram.org/tdlib

Because Telegram is not secure at all and the only content that is not stored on server unencrypted are so-called secret chats, used by approximately 0% of audience. So they have zero need to be paranoid about data privacy.

You also need to give your developer keys to Telegram if you want your client to receive push notifications.

Push notifications are pretty standard, though - this is an issue with the app store model, if anything.

> It's practically a principle of the Signal project to discourage third-party clients

It depends on what you call "client". At the protocol level sure, you're supposed to behave just like any official client. But to do that you just have to use their client library[0] and implement whatever you want on top of this, like signal-cli[1] has been doing successfully for quite some time now.

Some forks exist here and there (from memory, there's one with WhatsApp import, another with UI features), there's just no interest for a completely new client. There's only so much space for innovation for what is mostly a messaging app.

To be fair, the absence of an API (which Telegram has) also limits possibilities.

[0]: https://github.com/signalapp/libsignal-client [1]: https://github.com/AsamK/signal-cli

The last time I looked, Telegram didn't even have E2E-secure group messaging. It's easier to use and more pleasant to code to, but then, if that's all you're optimizing for, that's not a high bar to clear.

Then you get something analogous to the PGP problem, where you have so many options that it only takes one misunderstanding to compromise your communications.

They threatened to block a fork before. It just removed Google dependencies as far as I know.

[0] says use outside Signal is unsupported. And it's only for Java, Swift, and TypeScript.