5 ms·

Also Signal has a history of shutting down third party clients, e.g. there was an effort making Signal completely FOSS and publishing it on F-Droid and Moxie sh

Also Signal has a history of shutting down third party clients, e.g. there was an effort making Signal completely FOSS and publishing it on F-Droid and Moxie shut them down for using the official servers, as well as the name: https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165 https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

nousermane 5y ago
For people longing for a phonenumber-based messenger with a good selection of officially-supported free/open-source clients, have a look at: https://quicksy.im/ https://quicksy.im/
- sneak 5y ago
  It would appear that encryption is optional in this tool. That's a 50 caliber footgun (on par with Telegram) if I ever saw one; I won't be using this software.
  - m4lvin 5y ago
    OMEMO is optional because not all of the 37283749 XMPP clients support it. But it is enabled by default if all involved parties are using Quicksy, Conversations or another reasonably new client.
    - sneak 5y ago
      I won't touch a messenger that ever lets me send a mix of encrypted or unencrypted communications. That's an accident waiting to happen.
      - h4waii 5y ago
        For what it's worth, Signal on Android allows sending of unencrypted messages over SMS.
        slenk 5y ago
        But that's a different protocol than the signal protocol. And Signal encrypts your SMS at rest should you choose to use their app to do so.
sneak 5y ago
You're totally allowed to publish client software that has the URLs of the official servers in the code, including that forked from the official client. Believing otherwise is a common (and false) misconception that I wish people would stop repeating. (However, if you do fork the program, pick a new name! "Signal" is trademarked, don't use it in your name.) The ToS for the signal service API applies to end users who connect to that API. The ToS of the API does not apply to software - the AGPL license applies to that, and the AGPL permits anyone to make forks (including ones that are configured to talk to the official servers). EDIT: Disregard the following paragraph. See below. There is a little bit of an issue, though, because contributions to Signal's upstream are not accepted unless the contributors sign the CLA, which allows Signal to relicense future versions more restrictively as they wish. They could relicense and then introduce intentional incompatibilities in the protocol if they really wanted to harm forks, but that would make them non-free, non-open-source software. EDIT: Turns out I'm wrong in the above - the Signal CLA, to their immense credit, only permits relicensing under OSI-approved free software licenses. Fork away! Moral of the story: don't listen to bluster, stick to what the license says (and the AGPL says you can fork), and never sign a CLA. You don't have to sign a CLA to contribute to the Linux kernel, and you shouldn't ever sign one to contribute to any other open source project. I also wonder if it's even possible to enforce an "official clients only" restriction in the ToS for the service API. This would be a little bit like Google claiming that you aren't authorized to use Firefox to access google.com (i.e. insanity). Technologically if you tracked upstream closely enough, they probably wouldn't even be able to tell if a given 3p client user is running your fork or the official one. (This whole comment is a paraphrase of a blog post[1] I published just a few hours ago that tries to dispel this whole "but you can't fork Signal and use the official servers" false meme.) [1]: https://news.ycombinator.com/item?id=26940342 https://news.ycombinator.com/item?id=26940342
- diegoperini 5y ago
  Thanks for letting us witness your research.
- jeltz 5y ago
  They probably do not have a leg to stand on legally but what should I do if they ban me? Sue them?

nousermane 5y ago

For people longing for a phonenumber-based messenger with a good selection of officially-supported free/open-source clients, have a look at: https://quicksy.im/ https://quicksy.im/

sneak 5y ago
It would appear that encryption is optional in this tool. That's a 50 caliber footgun (on par with Telegram) if I ever saw one; I won't be using this software.
- m4lvin 5y ago
  OMEMO is optional because not all of the 37283749 XMPP clients support it. But it is enabled by default if all involved parties are using Quicksy, Conversations or another reasonably new client.
  - sneak 5y ago
    I won't touch a messenger that ever lets me send a mix of encrypted or unencrypted communications. That's an accident waiting to happen.
    - h4waii 5y ago
      For what it's worth, Signal on Android allows sending of unencrypted messages over SMS.
      - slenk 5y ago
        But that's a different protocol than the signal protocol. And Signal encrypts your SMS at rest should you choose to use their app to do so.

sneak 5y ago

You're totally allowed to publish client software that has the URLs of the official servers in the code, including that forked from the official client. Believing otherwise is a common (and false) misconception that I wish people would stop repeating. (However, if you do fork the program, pick a new name! "Signal" is trademarked, don't use it in your name.) The ToS for the signal service API applies to end users who connect to that API. The ToS of the API does not apply to software - the AGPL license applies to that, and the AGPL permits anyone to make forks (including ones that are configured to talk to the official servers). EDIT: Disregard the following paragraph. See below. There is a little bit of an issue, though, because contributions to Signal's upstream are not accepted unless the contributors sign the CLA, which allows Signal to relicense future versions more restrictively as they wish. They could relicense and then introduce intentional incompatibilities in the protocol if they really wanted to harm forks, but that would make them non-free, non-open-source software. EDIT: Turns out I'm wrong in the above - the Signal CLA, to their immense credit, only permits relicensing under OSI-approved free software licenses. Fork away! Moral of the story: don't listen to bluster, stick to what the license says (and the AGPL says you can fork), and never sign a CLA. You don't have to sign a CLA to contribute to the Linux kernel, and you shouldn't ever sign one to contribute to any other open source project. I also wonder if it's even possible to enforce an "official clients only" restriction in the ToS for the service API. This would be a little bit like Google claiming that you aren't authorized to use Firefox to access google.com (i.e. insanity). Technologically if you tracked upstream closely enough, they probably wouldn't even be able to tell if a given 3p client user is running your fork or the official one. (This whole comment is a paraphrase of a blog post[1] I published just a few hours ago that tries to dispel this whole "but you can't fork Signal and use the official servers" false meme.) [1]: https://news.ycombinator.com/item?id=26940342 https://news.ycombinator.com/item?id=26940342

diegoperini 5y ago
Thanks for letting us witness your research.
jeltz 5y ago
They probably do not have a leg to stand on legally but what should I do if they ban me? Sue them?