That would be the case if they’d standardize the signal protocol. Letting third parties connect has nothing to do with that. Signal can still change their API any time they want.
I replied in another comment, but letting third parties connect widens the surface area of the potential attacks. If that bug happened in a third party, from a security pov you must block them from accessing the service, at which point you need to decide if you want to police every single possible client or focus on one and make it widespread.
And Microsoft could in principle choose to do a hard break with all backwards compatibility in the next version of Windows. But they won't. Eventually, the third-party base may be so large and varied, that it becomes quite painful to actually make such a change even if the letter of the law says you can.
Microsoft's Windows APIs are, in some sense, an "open platform".
They don't accept third party contributions, but they are thoroughly documented and their whole purpose is to support third party developers.
Because that's their goal, they won't ever break that backwards compatibility.
That, I think, is what the GP was getting at - the Signal team does not want to wind up being constrained in the ways that MS is by supporting third-party developers.
Making their protocol an open standard would have that effect, because they could no longer unilaterally change the protocol as they see fit. They would be constrained by the need to support and think about all the other stakeholders who rely on the standard.
If you control the client, the server, and the internal-only standard, in really bad situations, you can just push out an update that fixes the apocalypse in a backwards-incompatible way and drop support for all previous clients.
This is not hypothetical - see the KRACK attack from 2017 for an example where an open standard was found to have a security flaw (https://www.krackattacks.com/).
We all got very lucky that the flaw could be mitigated in a backwards-compatible way.
Yes, this is about right. I was struggling to express the idea. Thank you.
Win32 is an open API in a certain sense. Of course it's not open as in open source as in consensus and cooperative standards as in FLOSS, at all. But. It's well documented. Anyone can target it. It's stable.
Textbooks on Windows Vista programming 15 years ago are almost completely applicable to Windows 10 development. Even software that was targeted at a reasonable subset of the Windows 95 API, whether binary or source, is still going to run on Windows 11 without change in many cases. You get notice of what parts of the API they're gonna break in the next version (usually) too.
In the olden days this was an "open platform" meant, usually. It's what the open in OpenWindows, OpenUnix, OpenStep was about. An open API. As opposed to a possibly undocumented, unstable API you only used under special contract and arrangement with the supplier. Often there was no actual prohibition (legal or technical) but there'd be no support. And it'd break randomly without notice.
As you say, it's a potentially enormous commitment, and organizational issue, to provide that sort of long-term API stability. And you can box yourself in regarding development and design choices.
