@Fla
as i am using Signal on mobile only, my first priority would be a native Sailfish [insert OS of choice] app - but I see the problems here too.
Anbox looks like a FOSS alternative to the android virtual machine (Alien Dalvik) now running on Sailfish - I think this would be the smoothest way to go (and I don’t expect objections from OWS to that solution).
Electron relies on chromium? Do we have Google and Microsoft (via Github) on board that way?
My two cents - maybe not really helpful on the topic - but nevertheless: Signal has been just the lesser of many evils for me. I really don’t like to use walled garden solutions and I would be glad if instead more developers worked on xmpp, activitypub or other federated protocols/networks/solutions.
I don’t know if “fund my app” is the right way to donate to the signal app, but that’s what I have done. I gave 100$ but would be willing to pay more if it was spent directly on signal.
I think the right way to go is to use the Unix philosophy of writing a cli tool and a UI that uses it. That will be the easiest thing to port and maintain. It also gives power-users cli control.
I agree that a more open e2e encrypted app would be a better alternative. I like the ease of using signal and I have gotten most of my friends to use it a few years ago. At that time it was the only option for normal users. I’ll get my friends to switch again if a better system comes forth.
Thanks for the tip . I am currently running the earlier version of whisperfish on my device as the fork by rubdos is still under development (as I am pleased to see ). But the app gets more notchy with every new upstream change. I don’t know whether the fork will be covering this, as it is still only Ruben working on it I think.
Are you running this on the Librem 5? If not, do you have any idea on how difficult it would be to port it? But the best would maybe be to port it to chatty!
No, on my Jolla/SailfishOS. I am not a programmer, I don’t know anything about porting, but I think it is specifically written for Sailfish and using part of the UI.
They are currently holding an Ask Me Anything on Reddit and said they are coming to check back the questions tomorrow. So I asked them. Please everybody upvote that comment so we can have an answer
After the huge rush of users from Whatsapp to Signal (40 millions +), a Linux responsive client becomes more and more necessary.
I hope it will be integrate in Chats soon or later.
Adding Signal support to Chatty via the new upstream libsignal-client Rust library with C bindings may be the best way forward long term. It already integrates with ModemManager for SMS so it could automatically handle the Signal registration verification SMS message and provide the same seamless registration experience that the Android client does. Having Signal and SMS in the same application like the Signal Android client would also be great. Plus Chatty already exists as a functional messaging application, so much of the GUI is already done. If Purism decides to put resources into this, that would be great. I posted more thoughts on the GitLab issue.
Regarding push notifications, maybe OpenPush could help if upstream is amenable to merging an implementation into their server code? Based on this old comment, they very well may.
signal-cli is based on textsecure which is the library we develop for Axolotl (the Ubuntu Touch Signal client). It isn’t a viable solution: upstream is changing things too fast. We still didn’t implement groups v2, it represents weeks of work, and they already deprecated endpoints for contacts discovery, we have days of work to do to re-implement that, and during that time adding new contacts is broken for all clients based on this… textsecure isn’t the future. The good news is, OpenWhishperSystem is now providing a Rust lib to handle the signal protocol. But that also means a lot of work to integrate it…
Basically, in my opinion, the best solution at the moment would be to fork the desktop client and replace electron to run it on phones. That would give us all the logic, protocol and UI part (that we need to make responsive).
I agree that reimplementing the network protocol is impractical to maintain.
Unless upstream changes their stance about making the Electron client have feature parity with the Android and iOS clients, I don’t think this will be a great solution. I think it would be better to use the libsignal-client library for a native client, which I suspect would be easier to integrate with the rest of the system (contacts, notifications, color scheme). Who knows, maybe when it’s feature complete upstream would be happy to drop support for Linux in the Electron client.
. I am currently running the earlier version of whisperfish on my device as the fork by rubdos is still under development (as I am pleased to see 
). But the app gets more notchy with every new upstream change. I don’t know whether the fork will be covering this, as it is still only Ruben working on it I think.
