Figure out how to securely serve Lisk Nano as a web app

[slaweet]

I still believe that it's possible to have a web-based version of Lisk Nano with the same level of security and decentralisation as desktop Lisk Nano.
While I understand that current web-based Lisk client login.lisk.io has some drawbacks, the UX of not having to install something is better.
Note that Lisk Nano as a web app is basically just one html and one js file. If necessary they can be merged into just one file and that file to be served from the same infrastructure as desktop version,
So the web version would be:
https://downloads.lisk.io/lisk-nano/0.1.2/lisk-nano-0.1.2.html
Similar to current Mac version:
https://downloads.lisk.io/lisk-nano/0.1.2/lisk-nano-0.1.2.dmg

Then I would work on making the web version a progressive web app, which uses service workers [0] in order to cache the page. So after the first launch of the web app it caches it and on any further access the cached version gets served, so it behaves the same as the desktop version, e.g. runs even if downloads.lisk.io is under DDOS or something. Moreover, the service worker checks and downloads if there is a newer version.

I understand that our hardcode users prefer to run the desktop version, but for most of the new users I expect a web app to be their first choice, due to it’s lower entrance barier.

Probably there are some additional issues with serving a web app I’m not aware of at the moment, but if we want to offer the best UX, we should put some effort to figuring out how to overcome those.

[0] https://developers.google.com/web/fundamentals/getting-started/primers/service-workers

[karmacoma]

The main issue of hosting lisk-nano on a SSL enabled resource is that connected peers also need to be SSL enabled. Additionally, the peers API runs on http while the public API optionally runs on https. Both APIs are used by lisk-nano.

In the forthcoming 1.0.0 core release. Clients such as lisk-nano will be able to use only the public API, i.e. optionally SSL enabled. The peers transport will instead be served using a persistent websocket and used exclusively for p2p communications, creating a separation of concerns.

Then we have the problem of reliably detecting SSL enabled nodes to connect with in a decentralized way. Here we can add a flag to peers header to indicate node is configured as such.

Both of the mentioned issues concerning peer discovery and available connection protocol will be handled by upstream changes in the lisk and lisk-js projects.

Currently, lisk-nano is configured to connect to a fixed number of nodes, i.e. node01 to node08, where a node is user/randomly selected and API calls are then made against the chosen peer. In the short term, we can enable SSL for these nodes. This would also us to serve lisk-nano securely in it's present state.

With regard, to your idea of using service-workers. We will keep in mind. However, won't it imo solve our immediate problem as I've described.