LibreSignal VS axolotl

>what does this mean?

Moxie (Signal's founder) has thrown fits in the past over the existence of third-party clients using their servers: https://github.com/libresignal/libresignal/issues/37#issueco...

0: https://github.com/libresignal/libresignal/issues/37

I push back when anyone recommends Signal because they are fundamentally not an open network.

OWS has historically been hostile to third party implementations outside of their clients. There are multiple unofficial options but the only one I've been looking at is the bridge with matrix, though setting up a matrix server just for this is likely overkill.

I have to say that I find him fascinating too, but there are a few things that raise my suspicion, but of course do not convict him of anything:

The way he is attacking this alternative Signal client and rules out interoperability:

https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

Signal was a word before he decided to turn it into a brand.

The signal server source code repo was not updated for a year. Communication intransparent.

https://www.androidpolice.com/2021/04/06/it-looks-like-signa...

I am not even against crypto integration, but I found the choice of MobileCoin odd. Instead of integrating an existing privacy coin or working with the community, he decided to integrate MOB and to be one of their "advisors":

https://techcrunch.com/2018/04/24/mobilecoin-moxie-marlinspi...

https://www.coingecko.com/en/coins/mobilecoin

Is that so surprising? Signal had always a hostile attitude to alternative clients. They have this weird disconnect of the new CEO saying they want to be available to as many people as possible and be a fully commited FOSS app, and then have no version on F-Droid (while Telegram has!) and actively fight alternative clients (see https://github.com/LibreSignal/LibreSignal/issues/37#issueco...)

Because of this hostility Signal is not a trustworthy organization at all.

LibreSignal existed before Moxie was like “no, don’t”: https://github.com/LibreSignal/LibreSignal

They have shut down third party clients, and resve the roght to continue that.

https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

1) You need to audit that code, which.. everyone will have to do.

2) https://signal.org/blog/reproducible-android/

> the Signal Android codebase includes some native shared libraries that we employ for voice calls (WebRTC, etc). At the time this native code was added, there was no Gradle NDK support yet, so the shared libraries aren’t compiled with the project build.

a good answer in my opinion, but it means what you run from the play store is not reproducible and thus can never really be confirmed to be what the sources actually include. There are also binary blobs needed for interacting with Google Play.

3) Signal is openly hostile to third party client implementations: https://github.com/LibreSignal/LibreSignal/issues/37

Moxie Marlinspike on May 5th 2016:

> I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal." You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.

> If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.

Moxie Marlinspike left Signal this January[2] 2022.

Whose to say whether there will be any change, but it's been interesting seeing Signal as a somewhat defended property. Although various third party clients/tools/libraries do exist already.

The claim that running servers is expensive would have been more interesting, imo, had there been any viable way to run your own. But for a long while Signal server source code wasn't being updated at all.

[1] https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

[2] https://signal.org/blog/new-year-new-ceo/

While searching around a bit more I found another unofficial Signal client for arm64 Linux optimized for mobile called Axolotl. The github page makes it look promising, but once installed I couldn't log in successfully. I intend to put more effort in there. Axolotl appears to be the most promising looking option for Signal on mobile Linux - assuming it works..

> Only a small thing, but due to Signals strict phone-desktop pairing mechanism, when registering Axolotl, both phone and regular Desktop wont work anymore.

> Also, you cant use Axolotl on Desktop together with Signal mobile.

> After deleting the Axolotl registration I had to wait a while to be able to register on Signal again, I didnt loose any backups and my codes didnt change.

> Nonetheless a warning should be displayed at the beginning, that users wanting to use regular mobile (iOS, Android) and Desktop (Windows, macOS, Flatpak or Snap), they should use a second phone number for testing.

https://github.com/nanu-c/axolotl/issues/811

>Signal also notably isn't self-hostable: there's no way to run your own signal server, and control your data. Marlinspike ruthlessly shuts down anyone attempting to build alternate clients or servers that could communicate with the main one.

That is perfectly wrong. As a maintainer of https://axolotl.chat, a third-party signal client initially built for Ubuntu Touch but which runs on almost everything now, I can tell you that our client is speaking without any problems to the official Signal servers, and also that the code of the server is available and is running fine, we used it to test our code.

Wouldn't Signal Desktop be a way to make backups?

I moved my home directory to a new computer and Signal Desktop started like if something changed. Sure you lose your messages on your phone, but you can still access them on your computer if needed.

On a rooted Android phone, you could use oandbackup to backup Signal. If you care about these things, maybe consider using a rooted Android phone?

I agree with you on the centralized platform aspect and the use of phone number (which is both a blessing (this makes it easy for new users to join) and a curse). I also agree with you on Element's UX, but it's getting better and most people can use it fine. I have a few groups on both apps.

I personally prefer Element, which seems more open than Signal and which I can actually use correctly on the PinePhone. Axolotl [1] still needs some work.

[1] https://github.com/nanu-c/axolotl

I think the best option to communicate through Signal will be Axolotl. Because the original desktop client of Signal might work as well but it's not optimized for touch input.

If you go to the git repo for Axolotl (https://github.com/nanu-c/axolotl), you will see links to the deb among other formats.

Ah well then I applaud you. :) Perhaps some ideas could come from past efforts like Axolotl, which I've had working in a basic way in the past.