… and I can’t even continue the chat from my phone.
Well dooh, you installed Chrome with it. Add to that their application and there you have it.
even the phone app is larger than telegram and whatsapp
Harddrives start at 16€/TB, so 500MB would be 0.008€. SSDs start at 50€/TB, so it would be 0.025€ or two-and-a-half cents
yes but think about how much money writing 500MB worth of code would cost.
I realize it’s not all code, and some of it is already written, but please, muse me, and do the math for it.
Writing less code costs more money. The programm is large because they slapped some existing stuff together instead of writing everything from scratch
Me putting a 4 TB 3.5" HDD in my phone
Why are you installing Signal Desktop on your phone?
You got me there
I don’t think people are worried about storing hundreds of Signal instances, this isn’t a photo backup.
The concerns are bloat, optimisation, and memory usage.Also, HDDs can go from $7.5/TB
That’s the point. The storage is a bad metric. While it might indicate poor performance, it’s not a direct indication of poor performance. The bloat and optimization comes from the usage of Electron. And people use Electron because it’s far easier to make cross-platform deployments for Web and desktop using a framework like Electron. Show me the QT/JavaFX app that mimics Signal and we can compare the cost to develop it. Electron isn’t the best choice for memory usage and reducing bloat, but it’s the best choice for quick development (in my opinion but also proven out by the market share it has)
While I’m on the subject, Signal’s phone UI is not great. Most screens severely lack contrasting colors and borders. Font size and spacing is inconsistant. It is hard and unpleasant to read - that’s kind of unfortunate for an app focused on reading and writing text.
Signal is Electron (Chromium + NodeJS) + Signal app code and assets. So not suprised that it’s bigger than Chromium.
Source: https://github.com/signalapp/Signal-Desktop/blob/main/package.json#L294
Debian Linux installation ISO is only 336 MB, FFS. And that’s a whole operating system with user land!
No, that’s a tarball of a kernel, basic command line tools, apt and a network stack that lets you download most of the operating system.
Um, no? The 336 megabyte usb installation media contains everything you need to install base Debian. Most people will want a desktop environment and other packages, they can connect to the network to download those additional packages.
Even the how-to says the network is optional.
https://www.debian.org/releases/stable/amd64/ch02s04.en.html#idm368
Given that they have a native, non-Electron iOS version, it’s a shame that they haven’t built a desktop macOS version using mostly the same code. (To make it look like a proper Mac app, they’d need different UI code, though even without that, they could build a version that looks like the iPad version with no changes, and it would look no worse than the Electron web-app UI and run an order of magnitude more efficiently.)
They don’t even need to built a separate app if they have an iPad app. they just need to not „not allow“ the execution on macOS.
Is it possible to run the android app on Linux somehow? Hmm…
Waydroid! No idea if Signal works with it though, worth to try it
Like I know native apps are always better, but why doesn’t electron ship an installable runtime so we don’t have to have a shitload of inert chromium installs on one machine?
You don’t understand. This way if some app crashes it will not cause others to crash too.
This is how google introduced the “multiprocess architecture” of Chrome.
You can still have separate processes and everything else with a shared runtime, you just save having all this wasted storage with every application bringing its own bundled runtime.
.net or Java applications work in a similar way, one Java app crashing won’t take out another just because they’re sharing the same runtime
I’d rather not have frameworks based on web browsers. Programming is not that difficult.
Well obviously it is, or we wouldn’t have electron in the first place.
We have it only because some devs are lazy.
For most uses of electron I’d agree, but if some engineers are going to use it anyway, I’d prefer the approach I’ve described.
Programming is not that difficult.
Learning how to do something in a new language and framework isn’t that tough, I agree, but no one is going to become an expert in something overnight. I don’t reckon many desktop native engineers are choosing electron unless they actually need it, so if you imagine the case of an expert web engineer building a desktop UI, they’re going to do a much better job with their main skillset than something they have just learned.
but no one is going to become an expert in something overnight
It’s not like they need to become experts. But also that’s actually possible (at least the effects of that), especially with all the AI around.
It’s not like they need to become experts
I mean if they would produce a better UI by using their expertise, how would not becoming an expert in the new thing be better? The reality is that the people paying the engineer are going to want the better UX over the benefits of not using electron in most cases.
But also that’s actually possible
Respectfully, no it’s not, not with software engineering unless you’re talking about learning a simple library or something.
If someone can genuinely master something in a day it wasn’t much of a skill to begin with.
I’ve been in this industry for about 20 years now, I would find it very hard to believe an engineer who says they’ve gone from no knowledge to expert in a new framework/language in any short period of time. I would either assume they’re trying to pull a fast one or more charitably just in the “naively confident” phase of learning:
especially with all the AI around.
AI can assist you if you more-or-less know what you’re doing, but a novice replacing proper learning with ChatGPT pairing is going to write some shitty code. I use AI in my role semi-regularly, and in my experience, no model has consistently produced me anything (non-boilerplate) longer than a couple of lines that didn’t need some kind of refactor for it to actually be up to our code quality standards. Sometimes you see them spit out some ancient way of doing things that have been outright replaced by a more modern approach, if you don’t have the experience, you’ll not know any better.
This is why I moved to Telegram. Idk if it’s actually native, but often feels much more so, and less phone-centric than Signal which requires weird auth rituals involving the phone.
its a QT+Webview project. So C++ and JS together. Cpp doing heavy tasks while JS doing cute animatons.
friendly reminder
https://www.tomsguide.com/news/signal-vs-telegram
If you care about security, stop using telegram.
People want a chat app. If your secure chat app sucks as a chat app, it doesn’t matter how secure it is. It failed the primary use case it was meant to be developed for.
But keep in mind, Signal’s nature is no excuse to have shitty app implementations. In particular to have desktop apps as second-class citizens (and tablets as exterminated not-citizens). You can be a secure chat app. Signal got the secure part done, they’re just struggling with the chat app part.
Signal is not an alternative to telegram and vice versa. Telegram has too many public communication features that people often use. The nature of signal will prevent it from having similar features.
Personally, I’m a big fan of XMPP, due to the inherent resiliency in being decentralized/federated, and due to the security provided by OMEMO (based on signal’s algorithm). Don’t have to worry about third-parties messing with my data if it stays on my server that’s in my house.
The telegram desktop app is wonderful
Such is the state of Electron.
I’m slowly stopping to care about web apps, however the amount of shit Electron causes is through the roof. Discord, Element, Signal, even Steam is full of it, so you just end up having 8 different “programs” running with every single one using at least around 400MB of RAM.
Can’t wait to see something using Rust and Tauri. Graphite wink winkCan’t wait to see something using Rust and Tauri.
What about sciter?
Steam is close but actually not electron, they use CEF - Chromium Embedded Framework which is something Electron uses too under the hood (afair)
Steam used an embedded browser long before it was cool.
Thanks for the correction, appreciate it. Not sure it changes much though.
Electron doesn’t use CEF, they directly bundle Chromium.
Of the apps you mentioned, I can use Discord and Element in my browser. WhatsApp even installs as a PWA. And Steam games can be launched through Lutris afaik?
There is no such option with Signal though.
Using an E2E chat app in your browser necessarily makes the keys and decrypted messages available to your browser. They would have the ability to read messages, impersonate users, alter messages, etc. It would defeat the purpose of a secure messaging platform.
I don’t get it. Who is “they”? Why can’t you fetch the encrypted message from the server and then decrypt it client side?
I think the encrypted messages are not saved in the server. You probably have to backup from phone and restore it on pc. “They” is the other programs running on browser
“They” is the browser/browser maker. The browser, acting as the client, would have access to the keys and data. The browser maker could do whatever they want with it.
To be clear, I’m not saying they would, only that it defeats the purpose of an E2E chat, where your goal is to minimize/eliminate the possibility of snooping.
You realize that your kernel which loads keys into memory can also access all this right? So can anything which shares memory space on the platform.
The bigger risk is browser exploits, not just who develops it. There’s more attack surface and more ways to exfiltrate data
With Discord in browser, you lose Krisp, RPC ipc socket support (aRPC might work, no clue), and from what I remember screensharing only worked with browser tab capture.
Element will eat your RAM no matter where it’s running. You could add it as a Nextcloud app to triple your RAM usage! Woo
And you can’t run Steam games without the Steam client running. That’s how their DRM works. (Unless you use the goldberg steam emulator, which is a whole another thing to talk about)
I don’t know how other Linux distros do it, but Manjaro (and seemingly Arch) seem to carry
#packages separately from apps like Signal. Unfortunately, Element requires electron29 and Bitwarden electron28 so I still have two copies of Electron. BTRFS’ deduplication helps reduce the real world size a bit, but it’s still unfortunate, especially since electron31 is already out.Signal runs some security code natively so you can’t run it in the browser, even though most of the UI is done through a copy of Chrome. At least the reusable packages make it so that only one copy of Chrome will be loaded for all Electron applications!
RE: the RAM: a lot of that is space allocated for JIT. Most of it is filled with zeroes, so if you run a modern OS (recent Linux, Windows, macOS) that RAM will end up being compressed+CoW’d to the point of barely making a dent.
Plenty of optimisations to be done, but it’s not as bad as task manager may make it seem. I’ve personally replaced a bunch of web apps with Element by bridging everything through Matrix (Matrix alternatives such as XMPP can also do that with an even smaller footprint).
I use a whole bunch of Linux distros at work (CentOS, alpine, ubuntu, debian, opensuse) and a bunch on my devices at home (mint, fedora, nobara, and manjaro), and so far the only distro I’ve seen ship decoupled shared electron libs like you described is Manjaro (and presumably Arch).
I really want to see the zygote approach worked out for electron. It’s working really well for android but with electron there are just too many different versions used by the different programs for that to make sense.
I wouldn’t mind so much if they all just used the same bundle of stuff, and you could install that once, and then the apps were all like 2MB each.
But no, big fucking bundle of shit, every single time.
Eh, that’s not the joy you think it is.
That’s how software used to be distributed and that’s where the terms DLL / Dependency Hell come from and why programs used to not uninstall cleanly and break other programs, etc.
It’s more efficient, but it’s also brittler and a lot more complex to manage. Conversely, bundling everything together with all its dependencies is a lot easier to manage, and a lot more robust overall, but comes at the expense of storage capacity and network bandwidth.
Yeah, I’ve been having a lot of issues with Electron which is basically a browser emulator. It has gotten huge, so applications using it have gotten out of control in size. I get that it’s a quick way to build a cross platform application, but there really needs to either be a better way to distribute it that is more modular, or people need to start building on better cross platform front-end systems.
i am doing a full system upgrade and something wants to build chromium from source. i let it run in the background and cloning the repository alone has downloaded 33GB wtf 😭
Yeah, I had to move away from Arch Linux because lots of apps you have to build and Electron was one of the biggest culprits for using tons of disk space and time because it builds Chromium in its entirety from source. Electron is a great way to shift the cost of cross platform development from you to your customers.
and it also runs like shit too.
the solution could be deduplication, not sure if microsoft store has it, or windows supports it, this help with the size, bot not ram usage
Windows doesn’t support deduplication itself (though ntfs does support hardlinks if someone wanted to do it). It actually won’t help here because every electron app bundles different versions in practice.
Back in the day Signal was a Qt app, did that change?
Maybe you are thinking of Telegram?
I’m not sure of its past, this repo goes back 4 years, but Signal is electron https://github.com/signalapp/Signal-Desktop/tree/main
Haha, WeChat is even more outrageous than this. All your forwarded files will be automatically stored again. Your chat records will always be stored on the disk, but WeChat will tell you that the chat records have expired. In addition, it has recently been discovered that every Once you log in to WeChat, your avatar will be saved more than ten times
You can actually delete the data for good in both the android and windows software through the interface, and it works. But yeah the amount of data is staggering.
I’ve got a reminder in my calendar to delete the data on the first day of a new quarter, so this here is accumulated since April 1st:
“android is good” mfers when they have to manually set a calendar task to notify themselves to manually delete the bloated information for an app that they have installed.
no shade to you specifically, but it pisses me off how much android users circle jerk over it being better than IOS, even though it’s like, moderately less annoying.
Calm down children, they both suck. Now put the rulers away.
they both suck.
this is literally just what i said, but ok.
I can automatically clean up space, or restrict space used, but then I don’t get to choose who’s data to keep or.
gotta love when they implement half of the functionality, instead of just implementing all of the functionality, because it would take like, ten more seconds.
iphone mfs when they have to read the word android
insert weird rambling about superiority while feeling superior themselves
For the most part, I don’t care about App Size. Storage is cheap. What I miss with the Signal Desktop App is the option to save everything in an encrypted container.
Wouldn’t having full disk encryption achieve most of the benefits of that? In case of someone having access to your unlocked machine what is stopping them from launching the app and looking though it?
Yes, full disk encryption helps against intruders with device access, but not against the files being indexed by other application. My phone is encrypted, but I still use a signal client that is encrypted again.
Am encrypted container doesn’t help if the directory is mounted and accessible or if the key is in plaintext. Also doesn’t help if the process isn’t isolated. You need a bunch of extra measures like using the OS keystore set to only allow the correct program to retrieve the key, keeping secrets only in process memory, etc.
Tldr it’s a lot of work to do it right. If you do it the simple way like throwing it all in SQLite with encryption active you still leak metadata.
I have never worked on a properly hardened desktop app, so I don’t have much of a perspective on that, and can definitely see that it might not be worthwhile for the signal team.
I would appreciate some level of encryption, thinking that it might help with less targeted attacks. I’d also appreciate a Web client, like Threema’s with none permanent sessions. But all that’s, as you’d say in German, “Meckern auf hohem Niveau”, especially since I’m not currently contributing to Signal.
Hm, but wouldn’t such an application be malicious by default? Having protection against attackers on your device seems of out scope for a messaging application, at that point I would consider something like Tails. Though this may be a rare case when moving to an appimage could help matters.
Yes and no. I personally would like to be asked permission for such behaviour, but a gallery application, for example, could have legitimate reasons to index all photos on your system. I personally prefer to manually set the folders it is supposed to index, but that doesn’t seem to be a generally accepted paradigm.
In general, I see why you need to trust that a system your app runs on is uncompromised to a a certain degree, but measures to potentially limit harm in case it is still seem sensible, especially for an app with a focus on privacy and security.
We set the threshold of sensible protections provided by the app (signal) itself differently.
On desktop having a gallery app, as you say, or running an application like windirstat for example I expect the user to understand that anything stored on device can be “seen” by the app and that, if they dont trust it, having sensitive files deleted or sandboxed might be prudent. Messages are stored at least somewhat encrypted (albeit with the key in a config file) so a random (non targeted/malicious) scan would gt blobs there.
On mobile due to how opaque the os is I am thankful for the extra encyption and I would consider it a much more critical flaw. On desktop less so. Still I appreciate your point of view and a passkey to encrypt at least messages on the desktop app would be a welcome addition.
Same. I’ve seen the alternative called dependency hell too often… Yes, you can.share stuff between apps, but then, versioning is a nightmare.
