Configuration - Web UI

[darkdrgn2k]

Look into Building a web ui to configure things.

Depended on #319

To decide

• Nginx or something else?
• Backend programming language
• Authentication mechanism
  • Login
  • Logout
  • Recovery Instruction
• Web UI
• Module interactions - how does a module plug into the ui
• File placed to a folder then read by ui?
• What happens if ui is not installed
• Separate DEB ie yggdrasill-gui

[makew0rld]

Looking at the Web Interface section of our HackMD may be helpful, it's where I've put pretty much all my ideas. To paste a copy of it in here:

---

Web Interface

Similar to how consumer routers have a settings page today, a Toronto Mesh node should have its own interface.

Follow this issue on the prototype repo for development.

Landing page

• Attractive overview of the node!
• Some nice simple stats
  • Uptime, # of clients & peers, CPU, software version, stuff like that
• Documents services on the node
  • 1,2 sentence description
  • Link to homepage
  • Status of the service - Running / Not running, Enabled / Disabled
• Links to local documentation
• Links to Admin UI
• Links to tomesh website, chat, etc
• Graphic node visualization?

Documentation

• Locally hosted
• Browser accessible
• From docs/ in the repo
• Convert MD files to HTML?
  • With Pelican maybe
• Should feature some troubleshooting tips
• Links to repo(s) and tomesh chat

Admin Panel

• A browser-accessible web interface for managing the whole node
• Similar to what routers might have
• Settings, stats, etc
• List of clients
  • MAC address to determine device type
• List of peers
• Install, uninstall, update
• Module configuration
  • Some IPFS config, etc
• Reboot, shutdown
• Restart services, enable and disable
• Possibly just another tab of the Landing Page
• Managing firewall
• Domains example from PeerDNS

---

Obviously this is a lot, too much, but it should help give some direction maybe.

[Ikata89]

It, would be nice if there is a option to install and configure usb wifi as AP or just a node.

[Shrinks99]

Is it a separate DEB (ie yggdrasill-gui or something)?

I would very much like the web UI to be installed on every main node in a home user scenario. It is not required for other devices that may connect to the main node in a user's home (the network topology as @darkdrgn2k outlined in the chat) and seeing as we want to keep these packages re-usable and keep things as lean & modularized as possible for future use case scenarios I would say a separate "management" package that just interfaces with the configuration outlined in #319 would be a good call.

[makew0rld]

@Ikata89

It, would be nice if there is a option to install and configure usb wifi as AP or just a node.

This is going to happen, check out #317.

@Shrinks99 I agree, all graphical things should be separate I think @darkdrgn2k, as it is foreseeable that someone won't want that overhead, especially on intermediate routing nodes or nodes that extend an AP.

[darkdrgn2k]

I would very much like the web UI to be installed on every main node in a home user scenario.

I think that the "DEB" solution should have individual packages that can be installed ad hoc. IE i dont want to "force" a ui for the CJDNS package if i just want to install CJDNS on my server. This is why a GUI package for CJDNS would work better.

I think its important to distinguish the DEB pacakge and the future of "prototype" which could be a easy-to-use builder of a node that draws upon these pacakages.

So like apt-get install basic-node would install cjdns, gui-code and cjdns-gui or something similar. but apt-get install cjdns would not install the gui

that way you have the choice to do your own solution, or to build a "user friendly" node

It, would be nice if there is a option to install and configure usb wifi as AP or just a node.

The core of this is going to be partly in #319 as a place to create a dynamic configuration.

However a bigger problem is outlined in #323

ISSUE: How do you identify what device is doing what in the config.

The Plug And Play nature of the wireless usb modules, broken drivers that randomly assign mac addresses on initialization, or report the wrong drivers and a few other things make it hard to try to idetify which device does what. Brain storming wanted

[makew0rld]

@darkdrgn2k I think we're all in agreement about what should happen with GUI packages. I also really like what you said of the future of this repo, where it becomes a builder for nodes, maybe having different profiles or scripts to install various deb pkgs and set up nodes.

[Shrinks99]

I guess we'll need to have two different types of GUI packages, one that is the base default and one that contains per-module features. Both will read and edit the config files mentioned in #319 and will have to interact with each-other somehow.

In the future I envision packages being installed using the web UI (average folks don't want to have to learn how to mess about in a command line) with some shipped as default on a pre-configured node and some that they can install on a case by case basis (P2P applications that live on the router probably). I'm personally planning to handle this with a similar UX to Atom's package management system at some point in the future but I feel like that's going to be a hell of a lot of work to make happen... At this stage of the web UI I'm only looking for working proof of concept that contains some of the features but none of the user flow or anything nice looking, that can all be done later :)

[makew0rld]

I guess we'll need to have two different types of GUI packages, one that is the base default and one that contains per-module features.

There can be one package that's the base installer GUI, and then they'll be GUIs for each package, pretty much like you said. I wouldn't call it the "base default", as anyone could install what they want, and the default should be a command-line only system. But I agree that installing packages through a Web UI is important.

I'm personally planning to handle this

I know it's far in the future but that's awesome, thanks!

[Shrinks99]

I'm personally planning to handle this

... The design & web parts anyways ;P

Solid point about CLI only, that should absolutely be the default.

As long as the GUIs for packages fit into the same website as the default GUI package is in then I’m cool with it. For things with an existing web UI like IPFS we can absolutely link to that and allow users to access it but I would really like a way to present package related settings all in one interface.

[darkdrgn2k]

there is no ipfs gui outside of the api that is accessable by localhost.

but I guess if we're behind a password wall we could bring it into the ui

[makew0rld]

As long as the GUIs for packages fit into the same website as the default GUI package

Definitely agree @Shrinks99, I think the key thing of what we're trying to do here is provide a modular system, but one that still all works together, GUI-wise, and of course at the lower levels too.

As for the IPFS GUI, we will have to look into how to do that, at the moment it can't be exposed safely, as @darkdrgn2k said. I would follow this main issue, and this smaller one to stay updated on that. I like the hack of just putting it behind a password though, if by the time we get around to this there's no proper way, we should do that.

[makew0rld]

To come back to the original issue:

I believe my comment above outlines some of the things we might want to do with the WebUI. But in @darkdrgn2k's original comment he raised some more pressing questions.

I think we should use Nginx to serve raw files if needed, and to proxy the main UI, as well as smaller application UIs. The GUI pkgs can make use of some base GUI pkg, that installs and sets up Nginx and maybe other things. Then each GUI can add things to Nginx, maybe a proxy file for example.

We need to decide on a language for the main server though. Ideally most of it can JS files written by @Shrinks99, but there still needs to be a backend to execute shell commands to do anything beyond displaying stats. One hacky way to accomplish this would be to have a localhost socket that would run commands sent to it and return output, using a simple bash service. Then the JS files could connect to that socket, and we don't need any backend language, just Nginx serving the files. That might be too hacky though, and so my other choice would be a Python server, but only because I know it. Perhaps a node.js server would be better, if @Shrinks99 can use that.

[Shrinks99]

Ah ha, a key issue: I still don’t know JavaScript :P

Happy to take on any and all JS / CSS & user experience tasks and while JavaScript is on my list of things to do it is unfortunately near the bottom at the moment.

[makew0rld]

Oh lol, that's okay. I don't either, but maybe we can both work on some of the files, because JS will be necessary. I'd say that rules out node.js though.

[darkdrgn2k]

I know its not a popular opinion but personally I'm not a fan of running a separate service as a web socket. You are basically running a SECOND web server to issue commands from the first in the odd times that the ui needs to be accessed. Additionally that model is heavily depended on java script which may or may not work on a specific browser with specific plugins installed.

I know here is a websocket method that will spin up as needed vs running all the time. i THINK it was websocketd but im not sure.

The most low-consumption stack would be to use Perl as it comes with all Debian systems, but im not that familiar with Perl.

Bash could also work but adding the web-component part of it may be cumbersome.

Lua may be an interesting option. I dont personally know it but its what is used in OpenWRT but I'm not sure how much overlap there would be.

For rapid development (at least on my side) its always been PHP.

[makew0rld]

I know its not a popular opinion but personally I'm not a fan of running a separate service as a web socket. You are basically running a SECOND web server to issue commands from the first in the odd times that the ui needs to be accessed. Additionally that model is heavily depended on java script which may or may not work on a specific browser with specific plugins installed.

It was definitely a hacky idea, I just thought it would be a simple solution to allow commands to be run. If it uses too many resources then I agree. But I don't know if being JS-free is an option really, maybe a portion of the UI, but most the interactivity will require JS.

I know here is a websocket method that will spin up as needed vs running all the time. i THINK it was websocketd but im not sure.

If you can find that, that'd be great, but I don't see how it can spin up without watching for a connection all the time.

Out of the languages you mentioned, Perl sounds good, but Bash might be difficult and a pain to write. Idk about Lua, but as ben's mentioned before, PHP is considered a "fractal of bad design", so I'm wary of continuing to use it.

You didn't mention Python, I suppose the issue with it is that it takes up space for ramdisk setups, like mesh orange? To be honest, I don't see restricted environments like that using a GUI. Thoughts?

[darkdrgn2k]

I think when your talking about what language to program it in you need not only to select the method based on ideology but also who has the skills to actually do it and/or time frame you wish to do it in.

If you want to stick with a language that we currently dont have in house talent for you have to be prepared to wait until that talent comes around.

As for "fractal of bad design" of PHP, although i would agree it has its issues, i will point out that you are comparing V5 with V7 (or 7.7 now a say) of PHP. But im more then happy not to use PHP.

[makew0rld]

@darkdrgn2k

think when your talking about what language to program it in you need not only to select the method based on ideology but also who has the skills to actually do it and/or time frame you wish to do it in.
If you want to stick with a language that we currently dont have in house talent for you have to be prepared to wait until that talent comes around.

I definitely agree. I've programmed webserver stuff in Python before and I'd be up to try with Javascript or bash if they make sense to choose, although I can't say I've done it before for those languages.

As for "fractal of bad design" of PHP, although i would agree it has its issues, i will point out that you are comparing V5 with V7 (or 7.7 now a say) of PHP. But im more then happy not to use PHP.

I wasn't really thinking about specific versions, I've just heard that comment before. It makes me wary of choosing PHP for this sub-project, and I would want to help with it, and personally I'm wary of taking the time to learn PHP because of the issues I've heard about it.

My questions for you, to try and reach a conclusion on this, are: What languages would you be comfortable doing the web programming in (client and server)? Which ones do you think are best?

[makew0rld]

Currently there is dynamic stuff like peers accessible to sites through CGI and Perl, and static info can be found in /nodeinfo.json. Recently in the chat the idea of just using client-side JS to access that data has been floated. If data needs to be updated every so often there could be a cron job that does that, but no long running systemd services.

This seems like a good solution to me, we'll have to see how it applies in future circumstances.

[darkdrgn2k]

Currently there is dynamic stuff like peers accessible to sites through CGI and Perl

Correction.

CJDNS is perl because the peer script is a modification of hamish's lightweight CJDNS client so that it does not require a node.js installation.

Yggdrasill is a bash script

CGI-BIN is not a programming language but a mechanism that allows the webserver to run an external file to receive dynamic information. This can be ANY programming language that outputs STDIO

[MichaelFBA]

If you would like some help with the JS part. I could help out.

We are just testing the mesh on raspberry pi's. So would be good to contribute.