Signal AppImage for Linux
github.com
github.com
https://flathub.org/apps/details/org.signal.Signal
I wish Signal would officially adopt the Flatpak and AppImage versions. They are pretty widely used and depend on third-party build pipelines right now, which is a risk.
The other messengers with the same amount of funding can do it and it's not a great amount of work, with the community being able to contribute to build scripts.
Snaps, yes definitely, but mostly when there is a UI involved.
I tend to prefer Flatpaks for apps with a UI.
Snaps would have been good for CLI apps if Canonical would just give it a rest already, and allow them to be decentralized and stop pushing them so hard as if that would make us use them.
So while I do sometimes use snap packages, I'd prefer not to.
Now, if they would just automatically move to a ~/apps folder, be executable and indeed, in the menu. My love for AppImage would grow orders of magnitude. Even more if they could self update.
Right now, snaps are the only universal packaging format that really gives me a smooth experience (install experience that is.)
There's a workaround for almost everything. Wherever there is a workaround, the problem becomes less severe. As a result, it is less likely to get fixed.
There is nothing preventing AppImages to work like app containers on Mac OS except lack of integration that comes out-of-the-box. Advocating for that integration becomes more difficult, when you can "just open the terminal and...".
I did use a terminal to install the AUR package on my system, however. ;)
It asks whether an AppImage should be integrated (with .desktop files, etc.) upon launching one and does everything automatically, even on my system running Arch+i3 where I except little to work automatically.
i fail to see what problems we've solved. it seems to me we've just duplicated the problems of competing packaging standards across distros, except now they all take up more resources and disk space than before.
it may have made a couple of devs lives easier, but the average linux desktop now is messier than a Windows XP SP1 desktop. We have apps from official repos, downloaded DEBS and/or RPMs, flatpak apps, appimages that dont' integrate into menus, snaps (if you're locked into Ubuntu), maybe a docker image or two. Nevermind half these apps are probably Electron based regardless of their crappy packaging.
Any of those can be installed on most big distros, so you only need to release one for your app. Though I would use only docker for services and only flatpak or appimage for apps. Snap is proprietary; only Canonical runs a server.
5-7 years ago, i could "apt upgrade" and upgrade, nearly, my entire box.
Now i have to manually upgrade DEBs, have separate systems or upgrade/management options for AppImages, Flatpaks, Snaps, docker images.
it's a mess and it makes keeping up with security patches an absolute nightmare.
Now, if you're lucky, apps do all their individual checking if an upgrade needs to be done and you do apps one at a time, piece meal, which requires a lot more time from end users.
I now spend more time managing my machine than using it.
so yay for devs saving some time on their end ,or something.
Speaking about AppImage only:
They've solved the problem of requiring third party middlemen to include our package in a repo, using updated versions on older "unmaintained" distros, using old versions on the latest distro, using two different versions at once, and being able to store applications on different media.
> it may have made a couple of devs lives easier, but the average linux desktop now is messier than a Windows XP SP1 desktop. We have apps from official repos, downloaded DEBS and/or RPMs, flatpak apps, appimages that dont' integrate into menus, snaps (if you're locked into Ubuntu), maybe a docker image or two. Nevermind half these apps are probably Electron based regardless of their crappy packaging
Unfortunately this seems to be the best that can be done with the Linux Desktop community's extremely fragmentary and complexity-worshiping nature. There is no agreement on what constitutes the base "Linux Desktop" platform, and very little ABI back and forward compatibility.
how do you propose to have software depending on, say, Qt 5.15 for hidpi bugfixes and ffmpeg 4.3 for codec support, available for users stuck on ubuntu 16.04 or debian jessie ?
I've never though about it but I guess it also makes them executable, since I've never had to do that myself.
It doesn't handle removing the AppImage, but you can always just delete the file from ~/apps.
https://github.com/TheAssassin/AppImageLauncher/releases
;)
The one thing that really bums me out is that the desktop app is another Electron app.
At the time of initial development and even now, there's really been no good cross platform way to build a desktop app with a team as small as Signal's, but they recently had an AMA on reddit where I asked if they had considered migrating to a Flutter based desktop app in the future. Their answer was generally positive regarding Flutter, but also a fairly firm no to future migration, so it seems we're stuck with Electron unless something changes.
I personally have been developing MMS to get it on the pinephone, and I don't think I would want anyone to donate to me. The main reason is now I feel like it obligates me to work and support people, versus now I do not feel any obligation. I get that I can ask for donations with no expectation in return, but I would still feel that way.
I would offer if that is truly what you want, perhaps taking some of the first steps to get it going may be a lot more useful than donating. If you have the first steps done, it makes the goal much easier if others want to help. That is exactly what I have found wokring through my project. A lot of people come out the woodwork to help on smaller issues that they can tackle, but there was no large scale effort until I finally rolled up my sleeves to start.
Couldn't you just make it very clear that any donations are only endorsements of the work you've already done and independent of any work you may or may not do in the future?
That way everyone is on the same page and you don't have to feel like you owe your donors support or continued development.
I will offer that I am also in a fortunate position where I don't need the money in the first place too.
Kind of an upside to very unfortunate situation...
Signal on the other hand is a nonprofit run by trusted people like Moxie Marlinspike, it's accessible to casual (non-IT) users as well (unlike XMPP) and it's fully open-source. It also minimizes metadata, like with the Sealed Sender functionality.
Just out of curiosity and not challenging: what makes Moxie trustworthy?
Signal being centralized and tied to a phone number are design choices to make things easier for users. That's a far cry from the presumed reasons WhatsApp did things. The only reason that Signal has gained what traction it has is because of those features.
Signal also has an excellent user experience (much better than I was expecting) and most of the privacy concerns are alleviated. Decentralised would be better, but I have not found Matrix to be a particularly smooth experience.
My grandmother can easily use WhatsApp or Signal.
Moving to signal is going to end up being the same problem that moving to WhatsApp was: single point of failure.
So yeah, great that it's not Facebook, but not very useful otherwise.
It is exactly the same. Download one of the clients, for example, Element. Then register. You don't even need an email address. Just make up a name, and a password.
There's even a web client that is functionally identical to the desktop and mobile clients.
It could not be simpler.
Ta da.
He's not talking about himself, he's talking about (non-IT) friends and family. Most of them probably would be barely able to find the register dialog on HN, that's at least what I would say about my non tech-savy friends. A good chunk of them doesn't even have a PC.
For those people, Signal is optimal. Its onboarding and usage is a lot easier than Matrix.
That is exactly the de-facto selling point of Signal. It does this and enough of other things better than the rest of the truly secure messengers. (Still not as good as Whatsapp is at these network effects, obviously.)
This is exactly why people insist on it. And exactly why if there was other messenger in it's place you would be asking the same thing.
You can't delete signal contacts and other potentially incriminating meta... Like wtf?!
there are reasons other than finances that are getting in the way of this moving forward, i'm afraid.
But from the developer point of view, I've seen some claiming that maintaining an AppImage is a PITA and pretty difficult / time consuming to get right: https://github.com/phw/peek/issues/502#issuecomment-58757433...
There is already a well-established convention for ~/bin.
Applications should not be installed in user profile space.
Many supported *nixes deprecate your touching system directories /bin, /usr etc and there's a well-established convention for placing added software in /opt, a filer share, removable media etc.
An advantage of AppImage is that they don't change the system package database and can be run from /opt a share or removable media.
Yes, there needs to be a mechanism for update of third-party applications. ~/apps isn't it.
Imagine in a corporation that uses Linux desktops, 1,000 users clicking to update a third-party bloated electron app to ~/apps.
Unfortunately Signal doesn't do this natively, so I have to keep the window open all the time (and my chats visible to passers-by). I'll pick kdocker for this one, I think.
The AppImage documentation mentions auto updating an electron-builder image is possible: https://docs.appimage.org/packaging-guide/optional/updates.h...
Signal is also nonprofit, fully opensource and minimizes metadata to a minimal amount (e.g. [0]), so it might not be as good as Matrix, but it's certainly not as bad as Whatsapp.
That's the first time I see this client mentioned. Maybe in a few years, the dust will have settled and there'll be a prominent Matrix client that's the obvious choice for most users. I don't think it'll reach widespread use before that.
Matrix is just not there yet. Hopefully soon, but not now.
Meanwhile, Matrix servers just ... log everything by default? https://github.com/matrix-org/synapse/issues/4565
1. Signal was used by Chinese dissidents and were whisked away by the CCP. The most likely proposed method was that the GBoard (google soft-keyboard) was "updated" with a poison update that uploaded everything typed. What defenses does Signal have against that? And will Signal warn against unverified GBoard updates that haven't been vetted?
2. Signal still demands your phone# to make an account. This by itself is unconscionable for an application that purports to be for security and privacy.
3. Signal still demands/pesters the user to share the whole phonebook with Signal. Anyone who does gets notifications when their phonebook shows up on Signal. And when you show up on Signal, everybody else is also told you're there as well. (Massive domestic abuse issues here)
If you can't trust your OS then you've lost already. This complaint is also fun considering the number of people who yell about banks doing things like refusing to run if nonstandard keyboards are installed.
> Signal still demands your phone# to make an account. This by itself is unconscionable for an application that purports to be for security and privacy.
The alternative appears to be "Signal knows which users you have communicated with", which is much worse. All sorts of interesting things can be obtained from the communication graph.
> If you can't trust your OS then you've lost already. This complaint is also fun considering the number of people who yell about banks doing things like refusing to run if nonstandard keyboards are installed.
There are also open source and 3rd party repos (F-Droid) that could provide properly vetted soft keyboards. And I'd also mention that Signal is not available on F-Droid or Guardian Project's repo.
And Signal can also run basic checks for sanity of the system, and loudly warn if things aren't as the application expects.
> > Signal still demands your phone# to make an account. This by itself is unconscionable for an application that purports to be for security and privacy.
> The alternative appears to be "Signal knows which users you have communicated with", which is much worse. All sorts of interesting things can be obtained from the communication graph.
All of the encrypted comms goes through their servers. They also prevent others from running federated Signal servers. That would lead that they have access to both who, where (ip address), how long (by length of encrypted data), and with whom.
The same metadata was/is the basis of the NSA's spy projects. Metadata is just as important as the very content.
2. That is an issue but they do have their reasons. They are working on implementing a username system that does not depend you giving them a phone number.
3. That can be solved once they implement usernames. Until then a workaround can be to use a Google Voice Number or a burner sim.