I never really liked AppImages. Until I got one recently that asked if it was allowed to be in my menu... Game changer!
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.)
You could always just rig up a couple Bash aliases and change where your menu works. Say for example appimg() { chmod +x $1; mv $1 ~/apps/ } and then bind a key sequence to `$(ls ~/apps/ | dmenu)`.
Not to dismiss your reply, but I've always thought that the "just open the terminal and..." kind of solution that is always brought up is holding Desktop Linux back.
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...".
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.
imho - after the insertion of flatpak, appimage, snaps, and in some cases dockerimages...
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.
Just switch to Arch. I know it's become a meme distro, but the AUR really is amazing. I don't have AppImages, snaps, Flatpak, or anything of the sort on any of my systems. Everything is either installed from the official repositories, or automatically built as proper packages and installed the same way.
This is exactly what I did. Snap's are basically docker gone wrong. Snaps are sandboxed, blocking access to NFS shares which I use extensively. Under Ubuntu, Chromium is usually broke (apt-get installs a deb that then installs a snap); You have to install either a debian .deb or use a PPA to make it work. I love that Ubuntu is directly including ZFS, but the distro has gotten so bad that I don't want to go near it anymore. Arch works, and works well.
> imho - after the insertion of flatpak, appimage, snaps, and in some cases dockerimages...
> i fail to see what problems we've solved.
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.
yes, it solves problems for devs at end-user expense.
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.
> 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.
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 ?
Static linking does not reasonably work for graphical apps on linux due to libGL, since you'd have to choose one libgl implementation at link time and basically embed the GPU driver in your program.
There are many technical arguments but I open app center (or whatever it's called, that big A), search, click and voila. I was a cli purist but I have become a pragmatist over the years. It just has to work.
If you use the KDE Discover, it's pretty smooth as well. Searched for "Signal", found the app, clicked on install, waited, then clicked on open. Signal App opened. Uses Flatpak in the Background and handles updates too.
I've used AppImageLauncher to do just that. When an AppImage is opened with AIL, it moves it to a configurable ~/app directory and creates a "start menu" entry for it.
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.
I've been a big fan of AppImage since I discovered that Firejail has AppImage support. Makes it super easy to do, for instance, bandwidth shaping for a single application, or to disallow network traffic etc.
I don't know why people insist on running this particular siloed encrypted instant messenger everywhere in every way. There are tons of these things out there. Since none of them interoperate anyway all you need to do is pick one that everyone in your group can run.
Kind of an upside to very unfortunate situation...
I find it particularly annoying that it inherits almost all of the worst features of WhatsApp which people are supposedly fleeing, such as being completely centralized and tied to your phone number.
People fleeing WhatsApp is basically fleeing from it because it is owned by Facebook. So it's usually for political reasons (especially in the USA) and/or for privacy concerns.
A minority of tech-savvy users are leaving it for the reasons you say.
Not exactly sure what you are talking about. People are fleeing from Whatsapp because it's owned by Facebook (which has one of the worst privacy reputations), because it's closed source and because facebook can replace your E2EE private key if they want so the E2EE is pretty useless. Facebook could also use the metadata if they want, which is pretty valuable.
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.
I suppose this is a matter of opinion, but for many the worst feature of WhatsApp is the fact Facebook has access to most of your stuff and its E2E encryption barely worked.
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.
Personally, I think that WhatsApp has an excellent user experience (including their encryption which is fine) and the only reason I am leaving is because of privacy concerns.
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.
I haven't really seriously looked into Matrix before. I've briefly skimmed what I could find about it, but didn't see any simple way to get something running where I could easily onboard friends/family. Correct me if I'm wrong, but this seems like the single biggest issue with Matrix.
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.
> simple way to get something running where I could easily onboard friends/family
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.
Baloney. If they're that inept, GP is going to have to do it for them anyways. He should save himself some trouble and start with something he won't have to replace in 5 years when precisely the same thing that happened at WhatsApp happens to signal.
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.
For the life of me I can't see why people use this over Matrix. But if it was because you want an AppImage for the client, then here: https://appimage.github.io/element/
Because in contrast to Matrix it looks much more accessible to the average user. Not all of my friends are in IT and want to/are able to use matrix.
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.
I find Matrix to be super abrasive to use. Weird popups asking me about encryption, missing messages, and a confusing UI. I'm a nerd, and I find it baffling. Feels like it needs a UI stripdown. Something like Telegram is way more intuitive to use, but obviously not fully free on the backend.
Fluffychat is a Matrix client with a much simpler UI. I've been testing it for a few days. It's still not to the level of Telegram, but it looks promising.
The problem is that having multiple clients for a given platform is confusing for non-technical users. Most users will give up after they have failed with the first client they found, especially if alternatives like WhatsApp etc. are easier to use.
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.
FluffyChat is promising but is missing some pretty key features such as sending files and calling. I can't wait until we have some really easy to use and fairly complete clients because I agree that Element is a bit much. Even as a power user I wish it was a bit less noisy.
The setup for Signal is basically just two steps: Open Google Play / App Store, click Install, open app and confirm SMS code (automatically handled on iOS and probably also Android). You search for other users with your existing phone contact list. How easy is the Matrix setup?
I've spent the past half hour reading up on Matrix again. What about the metadata issue? Seems like Signal goes to great lengths to ensure that the only data they have about a user is their phone number and the most recent day they connected to the network.
As a user, I love having a single executable file and not worrying about anything else like alien dependencies that will usually not work on my outdated distro.
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)
You can't call 1.) an "issue with Signal". It is not even correct description. It is an issue with any messenger app on any device or OS that installs automatic updates of anything from CCP.
> 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?
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.
> > 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?
> 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.
1. That isn't an issue with Signal or something that Signal could fix. Every messaging app will have that problem.
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.
It will also be interesting to see the p2p Matrix version, since they also use the same encryption tech as signal (it's equally private) and won't rely on centralized server.
Having an AppImage for Signal would be nice, but just yesterday I used kdocker to make it create an icon onto my system tray, which I don't think the AppImage would work with.
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.
I believe AppImage does not have an update mechanism which would make it more likely users will end up outdated versions which contain security issues. That is why I am more in favor of flatpak.
It can be possible, JetBrains Toolbox seamlessly auto updates but I'm not sure how they achieved it. On the other hand, maybe it is not so easy, I wish use the rpcs3 AppImage and have never had success with it's built-in update feature.
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.
Yeah, I was thinking this as well - the only official versions are for Debian-based repositories, feels a bit misguided to me for the "privacy and only privacy" messenger that probably has an essential userbase on Linux.
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.
No, you need an active smartphone and a phone number to sign up to Signal and register the desktop app at the moment. Maybe that'll change once they introduce usernames.
True. I think the bridge even uses it behind the scenes. I am only running the bridge because I already have my matrix server with ever IM bridged through to it. It's pretty amazing to be honest.
I've been using Signal for a few years now. Got most of my friends and actually all of my coworkers to switch.
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.
This is what surprised me most, using Telegram next to Signal in the recent months - their Windows app is fully native and super fluid + speedy. It's really a night and day difference, I hope Signal devs will reconsider some time.
Donations are kind of a funny thing IMO. Some folks who develop for open source are not motivated by money, and may not even want it.
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.
>I feel like it obligates me to work and support people
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 could yes, but at the same time, I do feel that if I got a donation and then life/work/etc. got in the way and I stopped doing anything, I still feel like I in some way let them down since they did donate to me.
I will offer that I am also in a fortunate position where I don't need the money in the first place too.
I'm not interested in donations, but I might have a go at this in a few months, if I get the time - as I'm a regular user of Signal, but I refuse to use Electron apps. Can't promise anything though.
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.
98 comments
[ 4.2 ms ] story [ 182 ms ] threadNow, 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
;)
https://snapcraft.io/signal-desktop
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?
https://github.com/moxie0
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?!
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.
[0] https://signal.org/blog/sealed-sender/
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
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...
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.
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...
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.
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.
[^1]: https://gitlab.com/signald/signald
[^2]: https://github.com/hoehermann/libpurple-signald
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.