Hacker News Reader

Comment by j1vms | Hacker News Reader

I agree. Last time I looked at why they were designing it be Chrome-only, it appeared to be due to a reliance on Google Cloud Messaging (GCM, [1]). This could be due to one or both of the following factors:

a) they wanted to re-use as easily as possible their existing back-end infrastructure which already uses GCM for the Android app.

b) they are using GCM to ensure that their desktops users are also "screened" by Google's existing authentication/security infrastructure - which ties a user down to a phone number among other things.

[1] https://developers.google.com/cloud-messaging/

Edit: clarity, typos

View on HN

We've never used GCM in conjunction with the desktop app, so I'm not sure where you were looking. Writing and maintaining three different fully native apps for Windows, OSX, and Linux is a non-starter for most organizations these days, but it's particularly true for a small open source project like us.

We developed it as a chrome packaged app because it provides the same experience as a native app (appears fully stand alone, integrates with your native OS launcher, etc), and because that's where the people are in the world we live in today.

Eventually we might consider wrapping it in electron or equivalent, but that's just a question of packaging.

Picking up on the maintenance burden here: Is there library support (or documentation) for the underlying stuff?

Say, is there a way to go to your Github page [1] and grab a project that allows me to a) build a client (I think that's possible) and b) link clients just like the browser?

Could I create the world's ugliest native client, connecting to the Signal network using my (phone's .. hrm..) identity? Is that a scenario you support (in general, not with office hours..) or would consider if it isn't possible today?

1: https://github.com/WhisperSystems/

You can get the chrome client from Github. That enabled one to circumvent the private beta until this announcement. There are no proprietary parts in the app store version.

Thus you should be able to make a native client just as well.

> Writing and maintaining three different fully native apps for Windows, OSX, and Linux is a non-starter for most organizations these days

Do consider writing it in Qt 5.

> We developed it as a chrome packaged app because it provides the same experience as a native app.

A typical native IM app can add an icon to the system tray, allows opening each conversation in a separate window and supports flashing said windows.

NW.js can run any Chrome Apps directly: http://nwjs.io

Is it possible to do multiple mobile device yet? Eg. iPad and iPhone?

Any chance of doing a website interface ala web.skype.com? If so please please support voice on linux. If not keep fighting the good fight.

Please don't go electron, ugh.

Any reason you didn't just go with Java? Java isn't my favorite, but shipping "apps" as entire web browsers under some handwaving is a dependency mess and massive bloatware. Too late now of course, but curious if there is some big advantage over the more obvious options that I'm not appreciating.

Hey, can you add some detail on why you don't like electron?

Not parent, just my own negative views on electron:

1. Massive download for a simple app. 37M is a lot of data. 2. Massive download for every simple app. It would go a long way if every electron app didn't have pull in a full 37M, and could share a set of common libraries. n*37M is a lot of data, and this is one strong reason I like this Signal Desktop release. 3. Battery unfriendliness. Even when idle, every Electron app does a lot under the hood that isn't even related to the app itself. This is the cruft of having a full web browser and an advanced JS VM, but it is a cruft regardless, and it is very disheartening when reduces a ten hour battery life to six hours.

Cool, that sounds like some legit concerns to me. It's a shame that we can't install a shared lib for electron, but then perhaps thats the browser...

A lot of runtimes are really big these days. Qt, Python, Mono are all big. Of course Java is bigger than most and comes with adware to boot.

Java comes with adware on the platform with the worst java installer. It's slow to install and forces you to actively deselect adware, but there's a Windows tool that can do that for you and there are package managers and app setup bundles. Installing Java on Linux and FreeBSD is very simple and fast.

Qt these days needs at minimum 30MB for a simple window and that's a huge overhead for basically a hello-qt app.

But Qt isn't as bloated as carrying around another browser.

Slack is a web app too, it doesn't hold it back at all.

Chat apps really don't need that much and the cross platform benefits of making a standalone webapp is numerous. Also being a chrome app means it can run on a chromebook, one of the most secure desktops out there.

And it being open source makes it you probably could make your own native clone implementation if you were really so inclined.

I _think_ (correct me) you might think of the Android app's dependency on the proprietary Google services.

As far as I'm aware, Signal doesn't run without GApps on Android by default, exactly because of the GCM dependency (but you seem to be able to dodge that with the help of the microG project).

Reply on news.ycombinator.com