Why are reproducible builds only on one platform (Android)? Desktop version could have a built-in backdoor and data would be transferred not from the phone, but from the PC)
Probably because the electron/js stack sucks massive hairy monkey balls
I’ve seen a lot of native applications run way worse compared to their electron alternatives. The problem is most devs don’t give a shit about code optimization.
It’s not that the devs don’t care, it’s that they’re not given the time to do it properly. Developer time is expensive, that’s why most companies ship the very first rough draft that kinda works. If the shittyness affects profits then they will invest the absolute minimum in one specific area affecting business and nothing more.
Yes, I also realised that a while after posting my comment. Corporativism is a plague that turns everything into a shittier version of itself.
deleted by creator
Linux users aren’t a very interesting target audience for any business intending to make money because they’re not used to paying for software
Steam, JetBrains and many more would disagree
JetBrains isn’t exactly a product for the general audience like Signal is. Even then they’re using the Electron approach (by building their IDE on Java, and Java doesn’t use the native OS UI in any way). They do support some Linux elements (shortcut schemes and such) but in practice they’re no different from any Electron app. If anything, Jetbrains’ success on Linux shows that Linux users don’t care about native apps as much as you may think.
Steam is successful on Linux (though it’s also mostly Chromium-based, except their Chromium is even more out of date). They’ve invested heavily into their Linux ecosystem for Intel/AMD GPU PC’s for their failed Steam Machines and successful Steam Deck (Steam is quite laggy and shit on Nvidia+Linux but that’s Nvidia for you). However, most games sold aren’t built for Linux. Linux gamers buy Windows games and run compatibility software, so the games companies are still targeting Windows. I would give you an example from my sizeable Steam library, but the checkbox to disable listing Proton-based games is broken (just doesn’t turn off lol).
Jetbrains and Steam are excellent examples of “don’t develop for Linux, develop for other platforms and port to Linux while you’re at it”. Valve tries its hardest but most of their income still comes from the Windows products they sell.
they’re using the Electron approach
Java isn’t the massive pile of shit that the JS ecosystem is. If you think these two are comlarable it is obvious you don’t know what you’re talking about. The landscape is a tiny bit more complex thn “C++ and then not C++”
deleted by creator
Electron isn't all that bad honestly. The bad part is people slap the same pile of massive and bloated node modules and framework in it that's the same cause as to why the modern web is so horrible.
A well written web app in Electron can feel quite good and snappy. It's just that the companies that own most of those apps don't care and won't give the developers time to build an optimized app, because that doesn't bring in money, but new features do.
Especially if you share the system electron runtime between apps, even the memory overhead isn't all that bad even compared to modern toolkits like GTK4 and Qt5/6.
But then you load like 5MB of poorly written CSS and a 10MB JS bundle plus all the assets and full screen background image and yeah, it'll chew through resources fast.
Sometimes when I have to debug a modern website, I'm amazed at the amount of crap it's there. Just checking the inspector in the browser, half the elements have hundreds of overriden CSS rules and hacks to make it display correctly instead of writing the CSS proper. Boatload of unnecessary divs and whatnot everywhere. That strains any layout engine.
The profiler in the browser console? Yeah nobody uses it, or even knows it exists and how to use it. I wow'd a lot of people just making a quick flamegraph and speeding up the code 10x like it's nothing.
We have the tools, but not the will to optimize.
massive hairy monkey balls
i’m stealing this lmao
Just because an application is written using Electron does not give it the right not to support reproducible builds. One has nothing to do with the other.
Yeah it does. The whole toolchain sucks ass. Knowing JS and its ecosystem running the same build command directly one after another on the same machine will probably yield different hashes. It’s just shit heaped upon mountains of garbage.
NPM has version pins and every tool I know of is, or can be, deterministic. Code obfuscators often introduce randomness but an open source app like this has no reason to be obfuscated in the first place.
I’ve worked with JS for years and it’s not like reproducible builds are impossible. They’re not often done, because who even develops JS and cares about this type of thing, but it’s not like there’s an inherent limitation here.
The only problem I can think of is transpilers inserting different line endings depending on the platform they’re run on, but if you use a Docker container for the build then there’s no good reason why that should be an issue.
I’ve worked with JS for years
My condolences
And I mean that too. The Reproducible Android build was done via Docker, so I think absolutely the same thing could be done here.
More like guesswork/assumptions than reality. I agree that Electron is meh. But I think it could still be done, f.e. with docker container as it is on Android.
More like guesswork/assumptions than reality
Sorry to be blunt, but you’re not a developer and it shows. Android’s build system was purpose made to be reproducible. Electron was not.
There is so much going on in an Electron build, most of which is out of Signal’s control unless they maintain an entire fork of the Electron build stack. That is an enormous engineering effort for basically zero benefit.
It probably is functionally reproducible, apart from checksums differing due to build dates baked into the artifacts somewhere. It’s not as easy as you think.
If you think it’s as easy as “building it in a Docker container,” then by all means, try.
I will not enter into disputes because… not too tech savvy. But I’m still sure that it could be realized. They just decided not to bother.
For the same reason its not on F-droid. They say “open source” but want to keep the source code to themselves. They are hostile to anyone who wants to fork it or create alternatives
they’re hostile to anyone who forks and creates alternatives using their servers. you’re more than welcome making a fork on your own infrastructure.
Since it’s not federated like XMPP this is completely pointless when all the users are on their server.
it’s more about solutions for workplaces, for example.
Molly still exists. They are against those forks that have Signal in their name. But in general, yes, the software development/delivery process is more similar to corporate than open source
How can you be hostile to someone creating forks? If the code is there you can fork it. Do you mean they are hostile to people using alternative clients to connect to their servers?
Moxie always did keep rigid control of Signal’s development and operations, often running contrary to users’ concerns and needs. I don’t think that has changed since he left.
He has argued at length against decentralized messaging. Requiring phone numbers is another example. Being bound to Google services is yet another: Signal dragged their feet on that issue for years, and when they finally did offer a non-google build, they hid it away on an unlinked page of their site and placed it below a “Danger” warning.
For all their talk of security and their contribution to the field of data privacy, some of their choices seem very strange, and the reasoning they offer is often dubious. I am not convinced that their motivations are aligned with my best interests. Their actions are certainly not.
They do still have the most reliable secure messager.
This comment doesn’t make sense. They can’t be hostile toward people forking code that they already open sourced.
Matrix (Synapse+Element) with Signal Bridge. It’s reproducible, so that’s what I run.
This is the answer.
Matrix needs to make it easier to expire or delete messages from the server, but other than that it’s doing a lot of the stuff Signal should’ve been doing years ago. Easy to use multiple devices, easy to get messages on multiple devices, keep chat history in sync, no reliance on phone numbers for identity or single identity servers, good working federation / ability to set up private hosted groups, etc.
Im a simple dude. I see matrix i hit like.
Smart move 🤟
Doesnt matter if everyone else is using Signal?
I mean lets be real. The signal gang comes out in full force online whenever this questions are asked but everyone is using whatsapp, facebook messenger, or telegram or something.
Depends on the country.
Nope. Matrix works with bridges (connections to other services). So via Element (the app for Matrix), I send/receive my messages for Signal, IRC, Discord, WhatsApp, and of course native Matrix users all from one place.
My matrix server is private, but it’s built for federated chat, much like Lemmy.
Yes I know but your messages end up on their phones with Signal or the other messengers on them. Awesome server, no idea how to do that, but in the end your messages end up on thede messengers, so it protects you from using that spyware, and gives the messengers weird data they dont know, but in the end they would need to switch to Matrix
I’d rather use XMPP. Synapse is bloated AF (to the point I am probably unable to run it at all on my remaining 0.5 gig RAM). There are alternative ones, but I find Prosody much less hassle. It eats 25 MB with two users and is easier to manage.
Wait, are you on HN? I feel like I’ve read this before haha.
No, I never comment there, I mostly dwell on IRC) It just seems to be a rather popular opinion. And experience seems to confirm this.
Sorry if this is a dumb question but what does reproducible mean in this context? I’m a little confused by the discussion here.
Meaning you can take the public source code and build (compile using your own tools) the whole package to run locally. From context, I’m assuming the public source is missing something to help you build it properly. (Maybe a dependency or a make file.)
In this context it actually means that you can take the source code, and get the exact same binary artifact as another build. It means that you can verify (or have someone else verify) that the released binary is actually built from the source code it says it is, by comparing their hashes. You can “reproduce” a bit for bit copy of the released binaries.
Ah gotcha, thanks!
Anyone else having the flatpak app crash when you click on a notification?
Yup, had the problem with Cinnamon. On Plasma it works fine.
Signal doesn’t trust messages server side. And the official flatpak made by the signal foundation are verified. So as long as you use the flatpak its safe.
Just a note that the flatpak is not made by the Signal Foundation, it is maintained unofficially by the community. See the last sentence on the app description on Flathub:
This flatpak is maintained by the Flathub community, and is not necessarily endorsed or officially maintained by the upstream developers.
There’s a discussion about the community flatpak’s trustworthiness on their repo here and here, a feature request for the Signal Foundation to have an official distro-agnostic release here, but for now the only official Linux release of Signal is for Debian-based distributions.
Fair point but why does signal have a position available for signal desktop on there web page? That’s rather odd to have it community maintained.
The Signal Foundation does work on Signal Desktop - but they only release binaries for Mac, Windows, and Debian-based Linux distros. Those are the downloads available on their website, there is no link to the Flatpak on their website.
The community turns that official Debian release into an unofficial Flatpak release. This means that you need to trust the community packagers to be doing the right thing, along with trusting the Signal Foundation. It’s an additional layer of trust that you wouldn’t need for an official release.
An alternative option would be building the app yourself - there’s documentation here and the repo is here, but then you’re responsible for keeping up and rebuilding when they have updates. I definitely hope the Signal Foundation releases an official Flatpak, it’s not a great position to be in if you’re not on a Debian-based distro.
These aren’t good reasons
Signal doesn’t trust messages server side.
What does this have to do with their ability to support reproducible builds?
this :)
deleted by creator
Signal is a company. Not a volunteer organization.
Incorrect. It is an US 501c3 nonprofit.
But still a company with employees and such. Just not allowed to make a profit over a fiscal year. Assuming it means the same in the us.
Which is a form of company. You tried to “acktually” me but you failed. Congratulations, you just look stupir.
I don’t think so. From wikipedia
A 501©(3) organization is a United States corporation, trust, unincorporated association or other type of organization exempt from federal income tax under section 501©(3) of Title 26 of the United States Code.
Notice how it doesn’t say “company”
Non-profits still have paid employees. More or less. Volunteers can volunteer for a nonprofit, but typically there are paid employees
I think you might want to do a reality check
Responses like these are what gives FOSS and Linux a bad name. Please stop being a giant douche.
😵🫡
