[whispersystems] non-Chrome desktop support

[Walter Lapchynski]

Last month, someone [mentioned why][1] entreaties regarding Firefox are
largely being dismissed. It's not really about market share, but that
it's not a platform that will really support extensive plugins. In other
words, it's wasted effort.

That said, I'm wondering if we can't get a standalone desktop client. Or
is that something I haven't noticed?

[1]:
https://lists.riseup.net/www/arc/whispersystems/2017-03/msg00019.html

[Shankar Kulumani]

I think ows is looking for a JavaScript developer to help continue
development on the chrome app.

Soon chrome is also deprecating the apps so ows already seems to be
planning another framework for the app.

There are a few Twitter comments and responses on GitHub that highlight
this as well.

Post by Walter Lapchynski
Last month, someone [mentioned why][1] entreaties regarding Firefox are
largely being dismissed. It's not really about market share, but that
it's not a platform that will really support extensive plugins. In other
words, it's wasted effort.
That said, I'm wondering if we can't get a standalone desktop client. Or
is that something I haven't noticed?
https://lists.riseup.net/www/arc/whispersystems/2017-03/msg00019.html
--
@wxl | polka.bike
C563 CAC5 8BE1 2F22 A49D
68F6 8B57 A48B C4F2 051A

[rikki]

there have been discussions on here around this in the past, and on github

using electron to make it into a standalone desktop app would make this
a moot issue! from what I gather, when this project began, electron was
still under heavy development, and node-webkit was stable but limiting.
The chrome.extensions API was pretty nice to work with in my experience,
so it makes sense it started this way!

The popularity and stability/ecosystem around electron is possibly a
reason chrome apps are being abandoned at this point.

From a quick glance, much of what signal-desktop utilizes from the
chrome API seems to be quite portable to any browser-driven runtime,
such as electron.

Of course, I could be overlooking some glaring critical dependency on
chrome.

There are some features that are native to chrome apps - storage,
notifications, etc that would need to be reworked, but otherwise it
could be kept simple.

A while ago on github I chimed in on a suggestion to move to both React
and Electron - however just moving to electron is whats most relevant
and realistic.

Eventually, we could exploit other features of electron - multiple
windows, more nuanced background processes, other advantages of using
node.js directly.

Any other electron/javascript devs wanna jump in on this? I could
probably put in a weekend or two on this! I've heard one of the original
core devs is really awesome!

Post by Shankar Kulumani
I think ows is looking for a JavaScript developer to help continue
development on the chrome app.
Soon chrome is also deprecating the apps so ows already seems to be
planning another framework for the app.
There are a few Twitter comments and responses on GitHub that
highlight this as well.
Last month, someone [mentioned why][1] entreaties regarding Firefox are
largely being dismissed. It's not really about market share, but that
it's not a platform that will really support extensive plugins. In other
words, it's wasted effort.
That said, I'm wondering if we can't get a standalone desktop client. Or
is that something I haven't noticed?
https://lists.riseup.net/www/arc/whispersystems/2017-03/msg00019.html
--
@wxl | polka.bike
C563 CAC5 8BE1 2F22 A49D
68F6 8B57 A48B C4F2 051A

[Sam Lanning]

I think currently, the biggest problem wrt: electron (or some other
browser-based application platform) is updates. Chrome is very good at
updating itself, if you use electron, you need to create your own update
infrastructure and logic etc...

This is demonstrated / highlighted by a recent twitter thread:
https://twitter.com/bcrypt/status/852316922683076608

For context, yan (bcrypt) works on the brave browser, which uses electron
(well, more specifically, brave have forked electron and were providing
upstream patches, not sure if they still do that).

So I'm not sure what the current situation is with auto-updating electron
apps, but as i understand it this has been the biggest sticking point for a
while...

Cheers,
Sam.

Post by rikki
there have been discussions on here around this in the past, and on github
using electron to make it into a standalone desktop app would make this a
moot issue! from what I gather, when this project began, electron was still
under heavy development, and node-webkit was stable but limiting. The
chrome.extensions API was pretty nice to work with in my experience, so it
makes sense it started this way!
The popularity and stability/ecosystem around electron is possibly a
reason chrome apps are being abandoned at this point.
From a quick glance, much of what signal-desktop utilizes from the chrome
API seems to be quite portable to any browser-driven runtime, such as
electron.
Of course, I could be overlooking some glaring critical dependency on
chrome.
There are some features that are native to chrome apps - storage,
notifications, etc that would need to be reworked, but otherwise it could
be kept simple.
A while ago on github I chimed in on a suggestion to move to both React
and Electron - however just moving to electron is whats most relevant and
realistic.
Eventually, we could exploit other features of electron - multiple
windows, more nuanced background processes, other advantages of using
node.js directly.
Any other electron/javascript devs wanna jump in on this? I could probably
put in a weekend or two on this! I've heard one of the original core devs
is really awesome!
I think ows is looking for a JavaScript developer to help continue
development on the chrome app.
Soon chrome is also deprecating the apps so ows already seems to be
planning another framework for the app.
There are a few Twitter comments and responses on GitHub that highlight
this as well.

Post by Walter Lapchynski
Last month, someone [mentioned why][1] entreaties regarding Firefox are
largely being dismissed. It's not really about market share, but that
it's not a platform that will really support extensive plugins. In other
words, it's wasted effort.
That said, I'm wondering if we can't get a standalone desktop client. Or
is that something I haven't noticed?
https://lists.riseup.net/www/arc/whispersystems/2017-03/msg00019.html
--
@wxl | polka.bike
C563 CAC5 8BE1 2F22 A49D
68F6 8B57 A48B C4F2 051A

[Joseph Szymborski]

I'm pretty sure one of the main selling points of Electron is that it
has auto-update features baked in. See:
https://electron.atom.io/docs/api/auto-updater/

I think the yan thread you link was mostly in regard to apps that
haven't bothered enable updates, and even worse, have manually disabled
the chromium sandboxing.

Disclaimer: I hardly touch Electron in my day-to-day, and I don't
pretend to understand the inner workings of yan's beautiful mind ;)

Post by Sam Lanning
I think currently, the biggest problem wrt: electron (or some other
browser-based application platform) is updates. Chrome is very good at
updating itself, if you use electron, you need to create your own
update infrastructure and logic etc...
https://twitter.com/bcrypt/status/852316922683076608
For context, yan (bcrypt) works on the brave browser, which uses
electron (well, more specifically, brave have forked electron and were
providing upstream patches, not sure if they still do that).
So I'm not sure what the current situation is with auto-updating
electron apps, but as i understand it this has been the biggest
sticking point for a while...
Cheers,
Sam.
there have been discussions on here around this in the past, and on github
using electron to make it into a standalone desktop app would make
this a moot issue! from what I gather, when this project began,
electron was still under heavy development, and node-webkit was
stable but limiting. The chrome.extensions API was pretty nice to
work with in my experience, so it makes sense it started this way!
The popularity and stability/ecosystem around electron is possibly
a reason chrome apps are being abandoned at this point.
From a quick glance, much of what signal-desktop utilizes from the
chrome API seems to be quite portable to any browser-driven
runtime, such as electron.
Of course, I could be overlooking some glaring critical dependency
on chrome.
There are some features that are native to chrome apps - storage,
notifications, etc that would need to be reworked, but otherwise
it could be kept simple.
A while ago on github I chimed in on a suggestion to move to both
React and Electron - however just moving to electron is whats most
relevant and realistic.
Eventually, we could exploit other features of electron - multiple
windows, more nuanced background processes, other advantages of
using node.js directly.
Any other electron/javascript devs wanna jump in on this? I could
probably put in a weekend or two on this! I've heard one of the
original core devs is really awesome!

Post by Shankar Kulumani
I think ows is looking for a JavaScript developer to help
continue development on the chrome app.
Soon chrome is also deprecating the apps so ows already seems to
be planning another framework for the app.
There are a few Twitter comments and responses on GitHub that
highlight this as well.
Last month, someone [mentioned why][1] entreaties regarding Firefox are
largely being dismissed. It's not really about market share, but that
it's not a platform that will really support extensive plugins. In other
words, it's wasted effort.
That said, I'm wondering if we can't get a standalone desktop client. Or
is that something I haven't noticed?
https://lists.riseup.net/www/arc/whispersystems/2017-03/msg00019.html
<https://lists.riseup.net/www/arc/whispersystems/2017-03/msg00019.html>
--
@wxl | polka.bike
C563 CAC5 8BE1 2F22 A49D
68F6 8B57 A48B C4F2 051A

[Sam Lanning]

Oh sweet okay!

I'm pretty sure one of the main selling points of Electron is that it has
auto-update features baked in. See: https://electron.atom.io/docs/
api/auto-updater/
I think the yan thread you link was mostly in regard to apps that haven't
bothered enable updates, and even worse, have manually disabled the
chromium sandboxing.
Disclaimer: I hardly touch Electron in my day-to-day, and I don't pretend
to understand the inner workings of yan's beautiful mind ;)
I think currently, the biggest problem wrt: electron (or some other
browser-based application platform) is updates. Chrome is very good at
updating itself, if you use electron, you need to create your own update
infrastructure and logic etc...
https://twitter.com/bcrypt/status/852316922683076608
For context, yan (bcrypt) works on the brave browser, which uses electron
(well, more specifically, brave have forked electron and were providing
upstream patches, not sure if they still do that).
So I'm not sure what the current situation is with auto-updating electron
apps, but as i understand it this has been the biggest sticking point for a
while...
Cheers,
Sam.

Post by rikki
there have been discussions on here around this in the past, and on github
using electron to make it into a standalone desktop app would make this a
moot issue! from what I gather, when this project began, electron was still
under heavy development, and node-webkit was stable but limiting. The
chrome.extensions API was pretty nice to work with in my experience, so it
makes sense it started this way!
The popularity and stability/ecosystem around electron is possibly a
reason chrome apps are being abandoned at this point.
From a quick glance, much of what signal-desktop utilizes from the chrome
API seems to be quite portable to any browser-driven runtime, such as
electron.
Of course, I could be overlooking some glaring critical dependency on
chrome.
There are some features that are native to chrome apps - storage,
notifications, etc that would need to be reworked, but otherwise it could
be kept simple.
A while ago on github I chimed in on a suggestion to move to both React
and Electron - however just moving to electron is whats most relevant and
realistic.
Eventually, we could exploit other features of electron - multiple
windows, more nuanced background processes, other advantages of using
node.js directly.
Any other electron/javascript devs wanna jump in on this? I could
probably put in a weekend or two on this! I've heard one of the original
core devs is really awesome!
I think ows is looking for a JavaScript developer to help continue
development on the chrome app.
Soon chrome is also deprecating the apps so ows already seems to be
planning another framework for the app.
There are a few Twitter comments and responses on GitHub that highlight
this as well.

Post by Walter Lapchynski
Last month, someone [mentioned why][1] entreaties regarding Firefox are
largely being dismissed. It's not really about market share, but that
it's not a platform that will really support extensive plugins. In other
words, it's wasted effort.
That said, I'm wondering if we can't get a standalone desktop client. Or
is that something I haven't noticed?
https://lists.riseup.net/www/arc/whispersystems/2017-03/msg00019.html
--
@wxl | polka.bike
C563 CAC5 8BE1 2F22 A49D
68F6 8B57 A48B C4F2 051A

[rikki]

Thanks for bringing this up - I can't believe I forgot about lifecycle!
haha. this is the biggest question with something like electron.

In the past, electron was behind on this and it has been a reason why in
other projects we went with a normal browser application.

While Squirrel is baked-in to electron's auto-updater now, it will still
add more effort to releases, and comes with some caveats:

A) It requires running an update server
B) Squirrel is not supported for linux, so you'll have to just ask linux
users to download a new deb/rpm to wholesale replace it. As I recall,
there *should* be ways to ensure local persistence with this strategy.
C) Squirrel on OSX /i think/ necessitates distribution through the app
store - which could add its own set of issues

One workaround I've seen implemented is to just avoid updates altogether
- to just do a version check on starting the application, and provide a
CTA to encourage users to download the latest version of the app
wholesale (with a link). The release strategy then would be just a
travis build and to deploy the new release version to github, with the
installers attached to each release. Persistence is still in question
here, but i'm sure theres some solid examples in the wild.

Another solution is to leverage electron-updater from the
electron-builder toolchain:
https://github.com/electron-userland/electron-builder/tree/master/packages

Though it still uses the native updater behind the scenes on OSX, it
would eliminate the need for a dedicated release server.

Would anyone be into collaborating on a document evaluating the risks &
advantages of migrating to electron?

Post by Joseph Szymborski
I'm pretty sure one of the main selling points of Electron is that it
https://electron.atom.io/docs/api/auto-updater/
I think the yan thread you link was mostly in regard to apps that
haven't bothered enable updates, and even worse, have manually
disabled the chromium sandboxing.
Disclaimer: I hardly touch Electron in my day-to-day, and I don't
pretend to understand the inner workings of yan's beautiful mind ;)

Post by Sam Lanning
I think currently, the biggest problem wrt: electron (or some other
browser-based application platform) is updates. Chrome is very good
at updating itself, if you use electron, you need to create your own
update infrastructure and logic etc...
This is demonstrated / highlighted by a recent twitter
thread: https://twitter.com/bcrypt/status/852316922683076608
For context, yan (bcrypt) works on the brave browser, which uses
electron (well, more specifically, brave have forked electron and
were providing upstream patches, not sure if they still do that).
So I'm not sure what the current situation is with auto-updating
electron apps, but as i understand it this has been the biggest
sticking point for a while...
Cheers,
Sam.
there have been discussions on here around this in the past, and on github
using electron to make it into a standalone desktop app would
make this a moot issue! from what I gather, when this project
began, electron was still under heavy development, and
node-webkit was stable but limiting. The chrome.extensions API
was pretty nice to work with in my experience, so it makes sense
it started this way!
The popularity and stability/ecosystem around electron is
possibly a reason chrome apps are being abandoned at this point.
From a quick glance, much of what signal-desktop utilizes from
the chrome API seems to be quite portable to any browser-driven
runtime, such as electron.
Of course, I could be overlooking some glaring critical
dependency on chrome.
There are some features that are native to chrome apps - storage,
notifications, etc that would need to be reworked, but otherwise
it could be kept simple.
A while ago on github I chimed in on a suggestion to move to both
React and Electron - however just moving to electron is whats
most relevant and realistic.
Eventually, we could exploit other features of electron -
multiple windows, more nuanced background processes, other
advantages of using node.js directly.
Any other electron/javascript devs wanna jump in on this? I could
probably put in a weekend or two on this! I've heard one of the
original core devs is really awesome!

Post by Shankar Kulumani
I think ows is looking for a JavaScript developer to help
continue development on the chrome app.
Soon chrome is also deprecating the apps so ows already seems to
be planning another framework for the app.
There are a few Twitter comments and responses on GitHub that
highlight this as well.
Last month, someone [mentioned why][1] entreaties regarding Firefox are
largely being dismissed. It's not really about market share, but that
it's not a platform that will really support extensive
plugins. In other
words, it's wasted effort.
That said, I'm wondering if we can't get a standalone
desktop client. Or
is that something I haven't noticed?
https://lists.riseup.net/www/arc/whispersystems/2017-03/msg00019.html
<https://lists.riseup.net/www/arc/whispersystems/2017-03/msg00019.html>
--
@wxl | polka.bike
C563 CAC5 8BE1 2F22 A49D
68F6 8B57 A48B C4F2 051A

[Heinz Repp]

While Squirrel is baked-in to electron's auto-updater now, it will still add
A) It requires running an update server
B) Squirrel is not supported for linux, so you'll have to just ask linux users
to download a new deb/rpm to wholesale replace it. As I recall, there *should*
be ways to ensure local persistence with this strategy.
C) Squirrel on OSX /i think/ necessitates distribution through the app store -
which could add its own set of issues
https://github.com/megahertz/electron-simple-updater

It uses the built-in autoUpdater and needs no release server (just
http(s) file storage), works on all platforms, and implementation looks
pretty easy.

Heinz

[rikki]

Hey so, I was looking into this and... guess what!

There's an electron branch going for signal-desktop:

https://github.com/WhisperSystems/Signal-Desktop/tree/electron

Dive in if you want browser-agnostic support!

Post by Heinz Repp

While Squirrel is baked-in to electron's auto-updater now, it will still add
A) It requires running an update server
B) Squirrel is not supported for linux, so you'll have to just ask linux users
to download a new deb/rpm to wholesale replace it. As I recall, there *should*
be ways to ensure local persistence with this strategy.
C) Squirrel on OSX /i think/ necessitates distribution through the app store -
which could add its own set of issues
https://github.com/megahertz/electron-simple-updater

It uses the built-in autoUpdater and needs no release server (just
http(s) file storage), works on all platforms, and implementation looks
pretty easy.
Heinz

[Walter Lapchynski]

Post by rikki
https://github.com/WhisperSystems/Signal-Desktop/tree/electron
Dive in if you want browser-agnostic support!

Sorry for circling back around to this so late but I had some other
priorities going on.

Anyways after getting a new node, installing bower & electron with npm,
a simple git clone, npm install, bower install away and I had an app
running.

Of course, that doesn't really work for production use, so that doesn't
totally solve my initial concern, but it's encouraging to see the branch
being actively developed.

That said, is there a roadmap available for electron development? It
doesn't seem that documents specific to that branch exist. Not only
would it be beneficial to know how soon something might actually be
really released, but it would be nice to figure out where I can help
move things along :)

Thanks!