Follow

Is anyone interested in starting a new adaptive GTK Rust client for Signal for Linux smartphones and desktops? I wrote a post on the @PINE64 forum about my reasoning for this technical approach:

forum.pine64.org/showthread.ph

Please boost.

*Do not respond to this with criticism of Signal*. If you're annoying about that, I'll block you.

@be i wouldn't mind... tired of this electron apps thingy (and wanna excuse to start doing Rust) @PINE64

@r3pek @PINE64 Other approaches could be a Qt application with Kirigami using a QObject wrapper around the Rust libraries to communicate with a QAbstractItemModel. Alternatively, the C FFI of the Rust libraries could be used in Chatty without going through libpurple.

@be @r3pek @PINE64 @chiraag there is already a Qt + Rust app (whishperfish) which is built for Sailfish OS, and Axolotl which is Go + HTML which runs fine one Mobian / Ubuntu Touch

@fla @r3pek @PINE64 @chiraag The Plasma Mobile developers mentioned Whisperfish but it's made with Jolla's proprietary QML libraries so that's a nonstarter. I think it would be more work to port that away from those libraries than start a new application from scratch.

@fla @r3pek @PINE64 @chiraag Whisperfish also isn't using the new upstream Rust libraries and like Axolotl is struggling to implement support for the version 2 groups.

@fla @r3pek @PINE64 @chiraag I think any approach that isn't using the Signal Foundation's Rust libraries is quixotic to maintain.

@fla @r3pek @PINE64 @chiraag I'm personally drawn towards the Kirigami & cxx approach because I'm familiar with Qt and have been wanting to learn QML. Learning how to get Rust and Qt to work together will also teach me valuable skills that I can reuse for Mixxx.

@fla @r3pek @PINE64 @chiraag For push notifications, I think the best approach would be implementing a Linux daemon for receiving Firebase Cloud Messaging with a dbus API to communicate with applications. This would not require the Signal Foundation to do any extra work on their end. Plus it could be used for other applications like WhatsApp, Facebook Messenger, Slack, Zulip, and other Android applications.

@fla @r3pek @PINE64 @chiraag Any suggestions for a name for a new application? "Noise" and "Silence" have both been used before for forks of Signal.

@fla @r3pek @PINE64 @chiraag I've initialized a repository called Flare on @kde's GitLab server for a native mobile Linux Signal client with Qt Quick. Please contribute and boost!
invent.kde.org/being/flare

@fla @r3pek @PINE64 @chiraag @kde If you're interested in getting involved, join the :kde.org Matrix room.

FYI @be, there already exists a RPG engine named #Flare (Free/Libre Action Roleplaying Engine), whose executable is flare (in Debian there's a metapackage named flare as well but that's something solvable): flarerpg.org

Flare is the first and only RPG I've ever finished (four times, counting one for the alpha campaign) and its gameplay is my absolute favorite, even compared to that of AAA games. Written on SDL2, it works just fine on the #PinePhone and touch input is WIP.

@mcsinyx I don't know if there's any common English word that isn't already used for *some* application...

@mcsinyx It's still early enough to change the name if necessary. Do you have any suggestions?

Unfortunately no, @be, sorry. I don't use Signal to understand it and think of a pun for it to keep our tradition, and I suspect all related names are already taken.

The Reddit thread reminds me of Giara, @be. If you're into recursive ancronyms, any four-letter word ending with either -isc (is a Signal client) or -isa (is a Signal app) might be a good idea.

@fla @r3pek @PINE64 @chiraag @kde Update: After reaching out to the Whisperfish developers, I've decided the best path forward for a native mobile Linux Signal client is to help Whisperfish decouple from Sailfish OS and implement a new Plasma Mobile GUI with Kirigami: gitlab.com/rubdos/whisperfish/

@fla @r3pek @PINE64 @chiraag @kde If you want to get involved, join us on Matrix at :rubdos.be

@be @fla @r3pek @PINE64 @chiraag @kde Sure, but I have seen other people faced with similarly difficult projects coming to different conclusions lately, so this makes me happy. 😊

@be @linmob @fla @r3pek @PINE64 @chiraag @kde Would be great to help, but I'm afraid my ability to help is rather limited. I'm just an enthusiastic geophysicist with fairly simple scientific programming skills (python mostly). 😕 I'll make sure to cheer!

@magnargj @linmob @fla @r3pek @PINE64 @chiraag @kde It's too early to ask for testers, but we'll need that eventually.

@fla @r3pek @PINE64 @chiraag @kde @marcozehe I see you commented on an old issue about accessibility with the Electron Signal client. If you're interested in helping us make the new Kirigami GUI accessible, that would be much appreciated! There's quite a bit of preliminary work to do before we'd be ready to test that.

@be @fla @r3pek @PINE64 @chiraag @kde Eew, I don't even know if I could use the operating system you're targeting. Last time I checked, SailfishOS was not at all accessible. And I am not aware that that's changed recently. Or what operating systems do you want that client to run under?

@r3pek @be @fla @PINE64 @chiraag @kde Aha. What toolkit do you wanna use? KDE has mixed accessibility, only slowly getting there on Linux, QT seems to work somewhat OK on Windows, I think, and I don't even know the Mac story of QT a11y, e.g. their support of the NSAccessibility protocol of AppKit, which is an absolute requirement for Mac. If you plan to use GTK, Linux will be the only platform this will be accessible AFAIK.

@marcozehe WisperFish is gonna be adapted to not depend on SailfishOS, so QT 😉 @be @fla @PINE64 @chiraag @kde

@marcozehe @r3pek @fla @PINE64 @chiraag @kde The plan is to adapt Whisperfish to use KDE's Qt libraries. Currently it only runs on Sailfish with Jolla's proprietary Qt libraries. Once we have it working on Linux, I think it wouldn't be too hard to build it on Windows and macOS too, but our priority is getting it working on Linux.

@fla @r3pek @chiraag @be @PINE64 @kde good luck! However I currently see myself being involved, sorry.

@be @fla @r3pek @PINE64 @chiraag @kde Besides, with tthat recent stance by Signal with that UK Bitcoin thing, I am actually not sure I could get behind anything supporting Signal any more. Also with regards to the fact that their server code seems to no longer be open source in its current form, only in a very outdated version.

@fla @r3pek @PINE64 @chiraag @kde @anarcat Are you interested in helping with this? I see your name quite a bit looking through the old LibreSignal repository on GitHub.

@be @fla @r3pek @PINE64 @chiraag @kde That’s awesome. I need to get my Pine reflashed and try this out. I’m currently using signald + matrix bridge/synapse + element. Having a native Qt5 app would be neat for sure.

@djsumdog @PINE64 @chiraag @r3pek @fla @kde To be clear, at this point we're just gathering interested developers and figuring out a roadmap. If you want to test it on your PinePhone, for now you'd need to use Sailfish OS.

@be @PINE64 Be sure Signal won't shut it down via a lawsuit.

@lig @be @PINE64 They have no legal basis like many times before so the worse they can do is API changes that break the app from now and then (the way YT, FB and other big tech companies fight alternative interfaces)

@gamey @be @PINE64 They cannot prevent one from making a client but they can deny usage of their name and/or service.

@lig @be @PINE64 If Fuckbook, Google, Shitter and co. can't sue alternative frontends I doubt Signal can. There is just no law and no example case that I am aware of to back that up 🤷‍♀️

@gamey @be The question is: do they want to do it? In most cases alternative clients/fronts provide enhanced experience for use cases that aren't interesting enough for an original service to support. Thus, that could decrease churn rate for the service. However, in case they decide an alternative is unwanted they basically are in charge of their service and free to pursue blocking an alternative in any way including a legal one.

@lig @gamey If they shut down this project and make their own client that works for mobile Linux, I'd be fine with that. But they're not going to care enough to do that without this project. It took LibreSignal to get them to make the Android client usable without Google Play.

@lig @be As long as the alternative frontend uses there existing APIs and gives no reason to suspect abuse I am not sure how they could take the legal way. They can however do stuff like API changes and IP blocking which can ruin alternative frontends.

@lig To add a big example case to the mix Oracle just lost the about a decate old fight against Google. I assume you know the case but in short Oracle claimed ownership of the Java API Google implemented to Android and asked for money because of that. There even is the Java trademark in that code but that currently doesn't seem to be enough to claim ownership (At least in the US)

@gamey That's different. No one can stop you from using the same APIs as Signal uses. However, that doesn't mean you can use their service in whatever way you like.

@lig Yea exactly but that means they would have to proof API abuse by the client to go against it legally.

@lig @be @PINE64 If you put Signal in the name they have a legal basis obviously but making a own frontend alone doesn't give them any attack survace

Sign in to participate in the conversation
Fosstodon

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.