Live data from Hacker News

Standalone Signal Desktop

signal.org

211–220 of 320 posts

Re: Standalone Signal Desktop

#211
post #208

Earlier quoted context omitted.

C++ is not the only option to write native applications. Electron is an hybrid codebase to start with.

All the options you listed require two or more programming languages. Electron apps can be written entirely in JavaScript, requiring zero context switching between multiple programming languages, as well as sharing code on the backend and frontend. Hence the popularity.

Then we are back to HTML 5 APIs, which any browser can already do.

If they need to interact with the host OS, someone needs to write those native plugins, and that won't be in JavaScript, as the Github repository for Electron clearly proves.

In the end is all about using an hammer for everything.

Re: Standalone Signal Desktop

#212

I so wish more people discovered Matrix or https://riot.im . To me it's simpler and works better than Signal while being decentralized and federated. It has excellent clients for all platforms (and these keep measages in sync with each other) and does not require a phone number.

Matrix is fantastic. However, riot desktop sucks in my opinion. Yet again, an electron app. You say that matrix "has excellent clients for all platforms". That is simply not true at this time. For linux, there's pretty much only 1 client that's currently usable, and that is riot (electron app).

There's a fantastic one in the works, qmatrixclient (quaternion: https://github.com/QMatrixClient/Quaternion), but it doesn't support E2EE yet.

Re: Standalone Signal Desktop

#213
post #211

Earlier quoted context omitted.

All the options you listed require two or more programming languages. Electron apps can be written entirely in JavaScript, requiring zero context switching between multiple programming languages, as well as sharing code on the backend and frontend. Hence the popularity.

Then we are back to HTML 5 APIs, which any browser can already do. If they need to interact with the host OS, someone needs to write those native plugins, and that won't be in JavaScript, as the Github repository for Electron clearly proves. In the end is all about using an hammer for everything.

No, that isn't the case. The Node.js APIs bundled with Electron expose considerably more functionality to JavaScript than the HTML5 APIs that Chromium exposes. And the Electron framework exposes even more native OS APIs that Chromium and Node.js don't provide.

Look, you can call it "using a hammer for everything" pejoratively if you want, but it's popular for a reason, and that reason isn't the moral decay of society. It offers real utility that reasonable people find valuable for rational reasons.

Re: Standalone Signal Desktop

#215
post #174

Other than the memory usage - these are problems I've encountered thus far: - It said it was 'Importing contacts and messages' when I signed in without first prompting me if that was OK. - Importing contacts and messages failed. - Manually importing contacts fails. - Conversations show up, but each message just shows as an error. - Deleting a conversation doesn't delete it, it just makes it as read. - Messages marked…

Not a single of those happened to me. Are you sure there is nothing wrong with your PC? It uses 130MB RAM here (Win). How much is it on your side?

Howdy, glad to hear it’s less for you, that’s a much more reasonable amount of memory to use but are you sure you’re including all active memory from each of its processes / worker threads?

Re: Standalone Signal Desktop

#216
post #211

Earlier quoted context omitted.

Then we are back to HTML 5 APIs, which any browser can already do. If they need to interact with the host OS, someone needs to write those native plugins, and that won't be in JavaScript, as the Github repository for Electron clearly proves. In the end is all about using an hammer for everything.

No, that isn't the case. The Node.js APIs bundled with Electron expose considerably more functionality to JavaScript than the HTML5 APIs that Chromium exposes. And the Electron framework exposes even more native OS APIs that Chromium and Node.js don't provide. Look, you can call it "using a hammer for everything" pejoratively if you want, but it's popular for a reason, and that reason isn't the moral decay of society…

> The Node.js APIs bundled with Electron expose considerably more functionality to JavaScript

Which happen to be written in native OS languages.

Re: Standalone Signal Desktop

#217

Earlier quoted context omitted.

I can't help shake that DLL and similar is a symptom of a culture of lax backwards compatibility upstream.

Microsoft tried to be backwards compatible with msvcrt.dll . It’s just too much inertia. Also you need to be bug for bug compatible or you may break some old app. Apps may even depend upon behaviour you didn’t know was there.

Yes there is a point of diminishing return. But all too often these days it feels like projects are not ever trying.

Re: Standalone Signal Desktop

#218
post #174

Other than the memory usage - these are problems I've encountered thus far: - It said it was 'Importing contacts and messages' when I signed in without first prompting me if that was OK. - Importing contacts and messages failed. - Manually importing contacts fails. - Conversations show up, but each message just shows as an error. - Deleting a conversation doesn't delete it, it just makes it as read. - Messages marked…

Not a single of those happened to me. Are you sure there is nothing wrong with your PC? It uses 130MB RAM here (Win). How much is it on your side?

Call me old, but how can a messaging app like this use 130MB RAM? I am exasperated that Skype on my machine is using 109MB with only one conversation window open.

We seemed to get by with MSN Messenger with far less RAM, and the features were pretty much identical.

It boggles the mind how memory-intensive some of the modern apps are. It's insane.

Re: Standalone Signal Desktop

#219
post #52

Earlier quoted context omitted.

Moxie strictly disagrees with that, and has previously tried to shut down every third-party build of Signal, even in repos for distros or F-Droid. He only wants users to get Signal builds from himself, and no one else.

Oh come on kuschku, stop it with the deliberate misinformation about Signal! You bring nonsense like this up in just about every thread on Signal and it's becoming harder and harder to assume that you operate in good faith. Moxie is most decidedly not against building the code yourself. He doesn't want anyone distributing forks or other clients using the official servers because a) that creates a giant hassle when up…

How the fuck is this misinformation?

Moxie has publicly stated that he is against anyone publishing a third-party build of Signal.

He has openly and loudly ranted against F-Droid. Of course he's not against users building it for themselves, but he's publicly stated he won't allow F-Droid, or distributions, or anyone else, to build and publish the client, under the name Signal, so that it can connect to his servers.

Read the Signal-Android issues https://github.com/WhisperSystems/Signal-Android/issues/53 https://github.com/WhisperSystems/Signal-Android/issues/127 https://github.com/WhisperSystems/Signal-Android/issues/281 and https://github.com/WhisperSystems/Signal-Android/issues/6292, where moxie publicly states that he will not accept or allow any public distribution of third-party builds of Signal to connect to his servers.

He actually directly reached out to F-Droid, and demanded they take it down: https://web.archive.org/web/20160410152543/https://f-droid.o...

So, how the fuck is what I'm saying misleading?

EDIT: Oh, right, some of the linked issues were purged by him later on. Here's an archive.org link: https://web.archive.org/web/20160410153027/https://github.co...

EDIT2: The real question is why you continue to lie to defend Signal.

Re: Standalone Signal Desktop

#220
post #101

Using Electron is a bad idea: it's not secure. Electron has many security vulnerabilities. The latest version is still based on old Chromium (58 & 59) so it inherits many of the security vulnerabilities published in Chromium 60, 61 and 62

what do you suggest they should they use instead

Write native code without Electron, Chrome, other random attack vectors?
Post reply on HN