Signal does not ban third party clients. I use a private fork of Signal Desktop every day and it works fine.
I know several others who operate Signal bots using API clients (in Java, IIRC).
They don't like it, but the ToS doesn't prohibit it.
We would consider it ridiculous if Google updated their ToS to say you must use Chrome to access google.com. I consider HTTP APIs of which I am a legitimate user to be the same; I will use whatever client I wish.
Well, they threatened LibreSignal with legal action, both for accessing their service and for using the Signal name, demanding that any third party client runs their own entire separate server network. Sounds pretty much like a ban.
That's a trademark (or perhaps trade dress) issue because it had "Signal" in the name.
They (the forkers) were stupid to induce brand confusion like that.
Signal is GPL free software; you can fork it and release it with any API URLs you like in the source or binary. It is perfectly legal to fork Signal and remove the user-hostile expiration timer, the image scaling enshittifier that happens on upload, and leave the signal.org API URLs completely unchanged. You just can't call it Signal (or LibreSignal, or BetterSignal, or ExtraSignal, or whatever) when distributing it.
The API ToS is what applies to end users who connect to the API. It says nothing about what software you are allowed to use to do so.
Signal would prefer to pretend that they get to choose what tools their users get to use to consume their service. Unfortunately for them (but good for us), they don't. It's the web and such a restriction would be insane.
Don't confuse software and services. They aren't the same.
This is so wrong. Signal is absolutely against third-party clients. Here's a quote from Moxie himself:
I understand that federation and defined protocols that third parties can develop clients for are great and important ideas, but unfortunately they no longer have a place in the modern world. Even less of a place for an organization the size of ours. Everyone outside the FOSS community seems to know it, but it took actually building the service for me to come to the same understanding, so I don't expect you to believe me. [0]
This is not saying anything about being open. This is talking about federation and stable protocols.
Both absolutly do hamper fast evolution of a product because they require a LOT of coordination and consensus, both of which are incredibly expensive and time consuming.
With a non-federated and unstable protocol, they are free to update and deprecated whatever they like and on a fast timescale. That is impossible with a federated stable protocol.
This has nothing to do with FOSS.
XMPP is a good example of a protocol that got fragmented to death by many many different and incompatible extensions, ultimately making it too fragmented and too slow to adopt to new requirements.
> Signal would prefer to pretend that they get to choose what tools their users get to use to consume their service. Unfortunately for them (but good for us), they don't. It's the web and such a restriction would be insane.
I know several others who operate Signal bots using API clients (in Java, IIRC).
They don't like it, but the ToS doesn't prohibit it.
We would consider it ridiculous if Google updated their ToS to say you must use Chrome to access google.com. I consider HTTP APIs of which I am a legitimate user to be the same; I will use whatever client I wish.