Replies, reactions, delete for everyone, read receipts and typing indicators
One-to-one voice calls, with earpiece, speaker and mute
Start chats from the phone’s contacts
Notifications and incoming calls while the app is closed
Registration lock PIN
At the moment the main issue is that I can not get the captcha to work when done through the L5. You have to do the captcha on another device (such as a laptop). You can use your L5 number and you don’t need another mobile device, this isn’t a ported version of the desktop client.
The issue (as far as I can tell) is that the hCaptcha score is to low when done through the L5, the whole registration process works as intended (without needing a laptop) when using Signals staging endpoint. What this means is you essentially use a laptop once to get the captcha completed and then just use the app like a native signal client. You do not need to go through Waydroid or anything like that.
Large portions of the code in this app were generated by AI.
Are you worried about Signal taking you down for TOS violations, since obviously your client is a TOS violation? I assume now that you’re advertising your app they’ll see it and consider planning accordingly to kill it, although maybe the captcha is enough.
Also, knowing the others in the past basically didn’t work by the time I tried to adopt them because these Signal TOS violation projects are always an arms race against Signal trying to fight you, not a one time creative work… what’s your level of commitment to future updates?
I think the way it went for Flare was that the primary dev of the project was able to keep themselves on it but Signal updated to where they would ban you from all of Signal servers for 7 days if you tried to switch to Flare from a normal Signal account. That way the dev doesn’t really see why because their own account works but you get low adoption of Flare by new people, since they’re scared of losing access to friends & family for the sake of an idea like L5.
I mean a huge part is that Flare is written in Rust and using a whole reimplementation of the Signal protocol written in Rust that has caused issues in terms of compatibility with the official implementation in the past.
Linal just seems to wrap the signal-cli application inside a graphical user interface written in Python. The CLI builds on top of a patched version from the official libsignal, extracted from the Android source code of the official application. So that should have less compatibility issues in general, I assume (depends a bit on changes necessary from Android to Java in this case).
I would argue that both clients are not ideal since in an ideal world we could have the official Signal desktop application support arm64 with the feature to act as main device build-in. But since we don’t get that, the differences are mainly in performance and reliability.
So regarding the TOS violation (I am not a lawyer) I am hopeful that since this is simply a wrapper around the signal-cli which has been around for a lot longer, is a lot more well known and hasn’t been taken down this will be fine as long as the signal-cli is fine.
For how long I will support this, I will keep it updated as long as the signal-cli is supported and I have no legal troubles.
I also agree a official app would be ideal but it’s also unlikely Signal will make one anytime soon considering the number of people that use L5s.
I mean technically porting the Signal desktop app for Linux to aarch64 would help a lot others too. We definitely had people in the past adjusting the flatpak to make it work with some minor issues, depending on the display protocol. But it was usable for the most part as second client.
In general supporting the architecture would benefit people with arm64 laptops or desktops too and a few other Linux phones that exist, I assume. If I would need to guess, I’d say Signal is not really trying to get people away from Android or iOS… maybe they think running through waydroid or similar is good enough? idk