Moxie has already given me secure communications and free text, media and voice messaging the world over so I can't complain too much.
I'm far more held back by not being able to get friends to switch from just chatting with Facebook app / Kik / Whatsapp etc than it being a browser app. I know I'm the outlier here. :)
So I think this is a big thing.
Haven't tested it yet and probably won't get time to today, but I'm really excited to see if it lives up to expectations.
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
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.
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?
Thus you should be able to make a native client just as well.
Do consider writing it in Qt 5.
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.
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.
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.
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.
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.
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).