Settings page: add UI controls for common settings from config file

[lidel]

I had an opportunity to talk with enthusiastic non-technical person and she asked interesting question: "sounds cool, but after I install it, how can I control how much disk space IPFS can use?".

AFAIK right now one can set StorageMax via commandline or by editing JSON at http://127.0.0.1:5001/webui/#/config:

I think we can agree that editing JSON by hand is.. not the best UX :) There is a real need for simplified and intuitive UI for setting selected configuration keys, StorageMax being the most obvious one, Gateway port being another one. Less is more. It is ok to have UI only with a few settings, leaving the rest to commandline or "Advanced Mode".

Open Questions

• Which configuration keys should have UI for setting them? What is most likely changed after installation?

• Should we leave option to edit full config in JSON format? Perhaps it could be initially hidden under a button saying "Advanced Mode" or something like that.

[hacdias]

This is a great point!

Just throwing an idea to the air: what if we developed some kind of system that transformed a JSON into a form so we could have every option in a more "usable" way?

Although, I recognize that that idea may not be the best because the form could get really complicated due to the nesting level we can find on the configuration.

Should we leave option to edit full config in JSON format?

I think so, and just like you said, it could be hidden under a button saying "Advanced Mode" or even "More Configuration". The user could even enable that mode by default checking a checkbox for example.

[lidel]

I was thinking about "Advanced Mode" and I realized that personally, I would rather edit raw JSON than edit a huuge nested form. For some reason raw JSON feels like a less of a cognitive load to me, but maybe I just can't imagine a good HTML form for this :)

I am not saying this can't be done "right" at some point in future, but I feel we should focus on "Basic Mode" first, which will be displayed by default.

Some related thoughts:

• Perhaps we could simply improve "Advanced Mode" (raw config JSON editor) by introducing syntax highlighting? I feel it will be a good compromise for now.
• Naming: "Advanced Mode"/"More Configuration"/ "Full Configuration" – all sound good to be honest, we'll pick something that looks natural in UI mocks.
• We should compile a list of things that should have UI elements in "Basic Mode"
  • StorageMax in gigabytes (as input type number?) (We don't have API for this, but it would be extra cool if we knew how much space is left on a partition used for IPFS storage and made it impossible to set more than that, or even display a resizable bar like in partitioning software)
  • Gateway and Api as URL fields (probably similar to UI we have in IPFS Companion)
  • not possible yet, but will be in future:
  • a checkbox for limiting bandwidth usage (after things like --routing=dhtclient get out of the experimental stage and are transitioned into a config options). This is quite important feature for people who want to run on a laptop or phone with a limited data plan.
  • (please comment if something else should be promoted to "Basic Mode")

[olizilla]

https://hjson.org/ has been mentioned as a lib for letting humans edit a friendlier json-like thing.

[olizilla]

WebUI allows you to modify the IPFS node config.

Desktop and Companion have to deal with app specific settings and also let the user modify the IPFS node config as well.

We need to think about how that comes across to the user. We can keep app settings and node config separate, but we should aim to present them as sections of the same page in the UI.

Companion calls it "Open preferences", while Desktop calls it "Settings". WebUI referes to the Node Config. We should agree the naming, and review the settings that each provide.

[hacdias]

I think Desktop and Companion could simply link to WebUI's page to edit the settings. And yes, we should define a name.

[lidel]

I'm leaning towards naming it "Settings" screen (a subset of entire "Configuration").

While we can delegate a lot, each app will always have a small set of app-specific settings that do not belong to WebUI. For example: control if Desktop autostarts with system, customize default public gateway used by Companion etc.

At the end of "Settings" screen, after app-specific things there should be button to "Open IPFS Node Settings". It could just link to WebUI screen that enables user to change selected node settings via dedicated UI (or just let user to edit raw Config directly, like it does now).

This way there is no duplication of Settings, there is always one place to change specific setting.

ps. here is a flowchart from old Android Design Guidelines on what becomes a setting and what doesn’t:

[akrych]

@lidel I love this flowchart. I have to keep it for future! <3

I think Desktop and Companion could simply link to WebUI's page to edit the settings. And yes, we should define a name.

I think that every application should have its own settings. Some small settings can be specific only for this application :)

Companion calls it "Open preferences", while Desktop calls it "Settings". WebUI referes to the Node Config. We should agree the naming, and review the settings that each provide.

About the name - "Settings" will be the best and the least confusing.

Perhaps we could simply improve "Advanced Mode" (raw config JSON editor) by introducing syntax highlighting? I feel it will be a good compromise for now.

Strongly agree, it will be good for the start and name "Advanced Mode" in my opinion will be the most recognizable by users.

At the end of "Settings" screen, after app-specific things there should be button to "Open IPFS Node Settings". It could just link to WebUI screen that enables user to change selected node settings via dedicated UI (or just let user to edit raw Config directly, like it does now).

Like it! 👍

We should compile a list of things that should have UI elements in "Basic Mode" StorageMax in gigabytes (as input type number?) (We don't have API for this, but it would be extra cool if we knew how much space is left on a partition used for IPFS storage and made it impossible to set more than that, or even display a resizable bar like in partitioning software)

StorageMax in gigabytes - In my opinion an intuitive interface for this is our "must-have". This option is the first that I will be searching after open application. I would also add a reference to this on the node info page where the Repo Size will be shown. (small icon (i) or sth.)

[alanshaw]

For app specific "settings" most apps I have installed on my macOS have gone with "Preferences"

I suspect there will be app specific settings to the WebUI as well. We could add a hook to allow wrappers like desktop/companion to add their app specific settings below/above WebUI settings?

I suggest that "Node Configuration" is one of the items on our WebUI settings page.

Following the lead of Atom/Sublime etc. I'm in favour of pulling out common/beginner friendly node config options into easy to update and validate HTML form elements and having a button that opens up "advanced mode" edit-the-JSON for pros.

In addition to @lidel's list of options to expose we should consider checkboxes for enabling the experiments.

[olizilla]

@akrych I think what we want is

Simple controls for:

• Set repo size quota in MB.
• MDNS Discovery (Find peers on your local network)
• Enable experiments (these aren't simple ideas, but we want them to be easy to try out)
  • pubsub
  • sharding
  • dht

And then:

• Edit node config directly using an https://hjson.org/ aware editor. Validate before writing, and giving useable error messages that the user can fix.

... right now Set repo size quota in MB is difficult, as it's only a hint to ipfs, and if garbage collection is disabled, the repo (i believe) will grow beyond that value. Also I'm not aware of any web api to get the users total available disk space, so we can't offer any sensible max value for that control, until we can get the ipfs api to tell us.

@lidel is that about right? We should think about

Gateway and Api as URL fields (probably similar to UI we have in IPFS Companion)

I think we want webui to be something we can point at different ipfs instances, so we need to think about the different use cases "i want to point my webui at that remote ipfs node" and "i want to update the api and gateway config of the ipfs node I'm currently using" as the latter would need special handling... changing the API address when the webui is using the API.

[lidel]

Some additional thoughts on what is currently technically possible:

• Config options provided by go-ipfs and js-ipfs As a reference, an up to date list and some docs can be found in go-ipfs/config.md, go-ipfs/experimental-features.md and js-ipfs/README.md

• Set repo size quota in MB We don't have means of checking actual disk space (yet) so we can't make this a slider, as we don't know the "max" value. We may look into feasibility of requesting missing API, but for now this will be effectively just a "checkbox" (to make it active by enabling GC) and "input" field (which will take a value in MB or GB).

• MDNS Discovery I am still trying to wrap my head around the level of complexity we want to expose in Basic UI. This one is a good test case. Yes, we can have this as a checkbox, but it is meaningless for less technical person (to be useful it needs at least a paragraph explaining what it does). Alternatively, instead of exposing low level settings like this one we could can hide them behind one of profiles (see below).

• Providing user with a list of predefined Profiles go-ipfs has something called "profiles". These are effectively configuration presets that set configuration keys to optimize for specific use cases, such as server, desktop, lowpower etc (list here). While we can't actually fetch these profiles via API, we can re-implement the most useful ones in WebUI (eg. default, server and laptop) and when user picks one up we apply changes to the config field-by-field.

• Changing API port I agree this one introduces need for additional orchestration. Not sure if this is something we want to provide quick&easy UI for. Perhaps we should not introduce UI for changing it other than editing config directly. Providing UI for changing Gateway port should be safe tho.

• Enable experiments This one is fine and useful, as long we have them under Experiments section (like in Companion). Not every experiment has a config setting, but those that do should be available.

[olizilla]

MDNS Discovery

If we phrase this as "Find IPFS peers on your local network" then it'd be more comprehensible

Providing user with a list of predefined Profiles

Good idea. I think the profiles available right now are pretty niche interest. It'd rad to figure out some profiles for the travelling laptop based dev, and the low spec local library desktop.

[lidel]

There is a discussion about controlling content reproviding setting via browser extension. See https://github.com/ipfs-shipyard/ipfs-companion/issues/507 for context and sample use cases.

I feel uses raised there are important enough to provide this as one of Simple Controls in WebUI as well.

[olizilla]

See also:

• api to restart a node: https://github.com/ipfs/interface-ipfs-core/issues/366
• api to reset node config: https://github.com/ipfs/interface-ipfs-core/issues/366

[olizilla]

Settings page design proposal (pulled from https://projects.invisionapp.com/share/AVGRKKJ75KT#/screens/302169242_Settings_screen

[bleonard252]

I was working on a script to map a checkbox to a JSON element, but I'm not finished yet. I'll publish it on Gist when I'm finished.

Jump down

[bleonard252]

Settings page design proposal (pulled from https://projects.invisionapp.com/share/AVGRKKJ75KT#/screens/302169242_Settings_screen

The one problem I have with this is the "What is IPFS?" box. You could instead fit a second column of settings.

[bleonard252]

Current state of my script: https://gist.github.com/bleonard252/528acbc7f954603c192f8745c5e5abda

The demo saves to local storage, but for some reason no updates are made (testing on Firefox). In this situation you would configure the "January" attribute to the configuration element. If there are problems with my script, please let me know in its comments.

[jessicaschilling]

Proposing we wake this discussion up and make it real ...