Feature: Standard management interface

[ShishKabab]

This issue serves as preparation to implement:
https://www.notion.so/worldbrain/StorexHub-Interface-3a6024e9538e404ab4df41771302de3f

A rough first draft of the tasks involved (to be edited and estimated as the discussion evolves)

Base:

• Implement standard plugin directory living next to the binary (4 hours)
• Implement endpoint to get information about available and installed plugins (3 hours)
• Enabled/disable plugins? (3 hours)

UI:

• Build & serve the front-end from a certain URL (4 hours, requires Webpack setup, etc.)
• Start the front-end on first startup (3 hours)
• Plugin overview UI (2 days)
• Plugin settings UI (4 days)
  • Standard settings
  • Links to custom settings
• App functions (index page in Memex, get tag suggestions, etc.) (2 days)
• System tray (3+ days, very unpredictable, no good solutions)

Plugins & updates:

• Safe stopping of plugin, so new version of it can be loaded (2+ days)
• GitHub-based plugin discovery (for now only featured plugins) (4+ days)
• Checking for plugin updates (4+ days)
• Plugin reload mechanism, building on safe stopping of plugin (1 day)
• Plugin update mechanism (means downloading, overwriting, reloading.) (2 days)
• Plugin change detection and communicating this to the UI (2+ days, depends suitability of file watchers, easy of distribution of native Node.js modules.,)
• Ideal: zip-file support for plugins (2 days)

[ShishKabab]

Depending on the scope and budget, I'd say some things we can implement in a later phase are:

• Plugin discovery (required for 'Featured plugins')
• Plugin updates

Also, we'd open the web interface only on the first startup, right? If not, we need to implement a desktop/menu shortcut to enable the user to open the interface, as opposed to it starting without opening the interface on system startup.

The tray icon is going to take work, since there is no optimal solution yet. NW.js has crappy packaging, whereas Electron consumes way too much memory. Maybe something non-JS needs to be used here.

[blackforestboi]

Also, we'd open the web interface only on the first startup, right?

Yes and every time they would open it via the icon on desktop (not tray)

Plugin discovery (required for 'Featured plugins')

Plugin discovery will be very important for the collab partners, so should be done relatively soon after.

Looking forward to go deeper into this list tomorrow!

[ShishKabab]

Yes and every time they would open it via the icon on desktop (not tray)

OK, that also requires us to dive into how shortcuts work to execute the binary with different arguments. Looking at this, if it works, it should be doable:
https://www.npmjs.com/package/create-desktop-shortcuts

We do need to plan the UX around this. We don't have a Windows installer for example where we can ask the user whether they actually want a desktop shortcut. On Linux it should be enough to add a .desktop entry so things show in the menu, but am not sure how standardized that is. On Mac, I have no clue how things work.

Maybe it's a good idea to look into installation experiences that fit well into the normal OS flow? Windows Installers, Linux AppImages, Mac OSX something.

[ShishKabab]

As for the systray, this looks promising:
https://www.npmjs.com/package/systray

Only consideration is how to bundle it. May be just copying another binary into the distribution.