Station Architecture

Codebase

Reference Codebases

Design Requirements

  1. For Station, we should leverage v8, in particular w.r.t how to deploy isolated things. Look at Cloudflare workers setup.
  1. There should be a UI and brand specific to Station, while other modules can plug into that UI with their own UI.
  1. The above points (1-2) must make sense with some of the following future applications of the Station.
    1. Run a Saturn node
    1. Testing latency of retrievals from storage providers
    1. Run some computation on some data
    1. Station as a deployment target for p2p network tools
    1. General network measurement tools
    1. Deploy a program to say 1000 Stations
  1. We need to figure out the minimal thing that Saturn needs from Station so we can launch Station with just the one application, to begin with: running a Saturn node.
  1. If possible, Reach for the same architecture as the IPFS desktop as more people will understand.
  1. Reach for previous UI design systems to move quickly.

Design

We want a pluggable architecture per points 1, 2, 3d and 4f. The user installs the Station shell first, then loads extensions/plugins like the Saturn node + UI.

Let’s call those pluggable pieces station modules. (ISS consists of modules too.)

  • There will be a single station module built into the app for the initial launch - a Saturn node.
  • Later, we need to design discovery & distribution channels for station modules. We can draw inspiration from mobile app stores, the catalogue of VS Code extensions, and so on.

The station architecture must be designed with a clean interface between the station and the modules. ipfs-desktop communicating over HTTP with the IPFS node is an example of good architecture. A Go or Rust binary interface between shared libraries (.dll/.so) is an example of a solution that would be difficult to work with.

It must be possible to package station modules independently; they cannot be baked into the shell (compiled as part of a big monolith app). This rules out solutions based on Tauri with Rust backends running in the main process.

JavaScript (either Node.js or the Web platform) offers a good trade-off: a single version of a station module can support multiple versions of the station shell, as long as the shell keeps its JavaScript APIs backwards compatible.

Security model

If we allow dropping other modules into the shell, we need to carefully examine security implications. The Node.js & npm ecosystem has a history of supply chain vulnerabilities, where a malicious package stole sensitive information like private wallet keys.

Ideally, we want modules to be fully isolated from the user’s desktop environment. A module should have access to its own sandboxed filesystem space and the network. It should not have access to users’ files, environment variables, or other services running on the system.

Going forward, I will assume the UI is implemented as a thin HTML5 frofrontendnning in a web view, there is a backend providing the business logic of connecting to storage networks, and these two components are communicating by exchanging messages - as shown on the diagram above.

Frontend isolation

The frontend code of each module should be isolated from the frontends other modules. There are two reasons for this:

  1. Isolation at the coding level makes it easier to develop modules without the fear of accidentally accessing symbols/variables/HTML elements managed by other modules.
  1. For security reasons, modules must not have access to data of other modules installed in the same shell. We don’t want a rogue 3rd-party module to steal the private wallet key from the official Saturn module or spy on a user’s identity & activity.

To be investigated:

  • Can we use the isolation capabilities provided by Chromium browser tabs to isolate the frontend code of different modules? (Each module would run in its own “browser tab”.)
  • Research isolation capabilities offered by the web platform - e.g. iframe, shadow DOM.

Backend isolation & programming model

Related resources:

(1) Backend as a background process

This is the model used by IPFS Desktop. The backend is an OS-level process running in the background. The shell has to manage the lifecycle of this process - start the process at startup, keep it alive, and terminate it during the shutdown.

Benefits:

  • Flexibility. The backend can be implemented in any language that can be compiled to a single executable binary (Go, Rust, Deno), in addition to Node.js as supported by Electron.

Downsides:

  • The shell has to manage the backend process.

Security: ❌ 

  • The backend process has full control of the host system. It has the same effective permissions as the user running the shell. For example, it can read users’ private files (SSH keys, private wallet keys).

(2) Backend running in a V8 isolate with a low-level API

V8 does not provide API for accessing the network and working with files. We can use Deno, Cloudflare Workers or Node.js APIs for that.

Benefits:

  • We have full control over what the backend worker can access.

Downsides:

  • The backend must be written in a language that can run on a web platform - targeting JavaScript or WASM.
  • There is no standard web (JS or WASM) API for network communication. Saturn modules would have to be written specifically for the API we pick. It’s not possible to reuse the same code for a browser version or a native backend.
  • Limited access to system-level & advanced networking APIs.

Security: 🔶

  • It depends on how we implement networking and filesystem APIs. Cloudflare has a nice
    • ✅ Deno offers security controls out of the box.
    • ❌ Node.js worker threads have access to most APIs; they DO NOT provide any security controls.
    • ❌ Node.js VM module gives us control over available APIs, but the docs say:
      The node:vm module is not a security mechanism. Do not use it to run untrusted code.
    • ✅  Cloudfare Workers have a very restricted API surface; they allow only network communication to the public internet and the origin server. There is no filesystem access. I think this model is too restrictive for us.

(3) Custom higher-level APIs for backend

Instead of providing the full Deno/Cloudfare/Node.js APIs, is it perhaps enough to give the backend access to libp2p/ipfs/filecoin APIs only? The shell would include libp2p/ipfs/filecoin library and expose its API to the backend. Maybe we don’t need any backend in this case, and the frontend can directly communicate with libp2p/ipfs/filecoin?

Benefits:

  • Saturn shell has full control over the underlying networking & file-system stack; it can restrict what 3rd-party modules are allowed to access.
  • We control the timing of libp2p/ipfs/filecoin upgrades. A single update of the built-in library version can fix security vulnerabilities affecting several station modules.

Downsides:

  • The module would have to be written specifically for Saturn; it will be probably difficult to reuse the same code for a browser version or a native backend.
  • Modules requiring recently added libp2p/ipfs/filecoin features will have to wait until we upgrade the station shell to use the latest library version.
  • We must actively release new versions of the shell to keep the libraries up to date. (If the libraries were included in the modules, then it would be up to module maintainers to keep the library up to date as needed.)
  • If a new library version breaks some of the station modules, we will need to fix the issue in all modules before we can upgrade. This could become a bottleneck.
  • Comment by :
    nice for security, but bad for application development. see the whole dynamic linking vs static linking debate with OS packages. each module would have to manage fewer dependencies, eg libp2p, but the APIs of those dependencies would likely change rapidly and thus could break modules if updated by us underneath them

Security: ✅

  • Assuming we can configure libp2p/ipfs/filecoin, which files & network resources it can access.

(4) Backend as a web worker

Leverage the Web Worker APIs to run module backends.

Benefits:

  • The same backend can run in Saturn shell and the browser.

Downsides:

  • The backend must be written in a language that can run on a web platform - targeting JavaScript or WASM.
  • Limited access to system-level & advanced networking APIs; only Web platform APIs are available.

Security: 🔶

It depends on the isolation model of the framework we choose (Electron, Tauri).

  • Tauri also offers restrictions at the application level and a framework to intercept all IPC between the web view and the backend, but I am not sure if this applies to fetch calls too.

Other thoughts

If multiple modules use the same networking protocol (DHT, IPFS client, Filecoin client, etc.), do we want them to share some resources like the list of active peers or the local cache for retrieved data?

Decision point

Based on my research so far, I feel we need to decide which direction to pursue going forward:

Option A - privileged backends

  • Module backends will run as a standalone process with full access to the system.
  • This is a proven path used by ipfs-desktop. It allows modules to leverage Go and Rust based nodes.
  • The path to the Station v0 release should be faster, as we don’t need to invent new architecture.
  • The major downside is the security risks.

Options B - sandboxed backends

  • Module backends will run in a V8 isolate with custom networking APIs or in a Web worker with standard Web APIs.
  • This is very secure, but it limits backend options, and we have to invent & implement the new architecture. We are likely to encounter unexpected obstacles along the way (unknown unknowns).

I feel Option A is better if it’s important to get Station v0 as quickly as we can. Option B is better if we want to address security concerns and can accept the trade-off of a later release date.

A third alternative is to start with Option A to quickly get the initial release out of the door and migrate to Option B before we allow 3rd parties to contribute Station modules. The question is, how costly the migration would be?

Thoughts from Miroslav

  • Based on , the JS libraries lack important protocol & networking features we need to achieve the desired performance. While we haven’t decided on which stack to use (Go vs JS), I feel Go is a better choice given the limitations of JS libraries and our desire to get a v0 release soon.
  • I feel among all unknown unknowns, the most important ones will be related to how the Saturn network works in practice. Whether we can maintain a reliable source of information about different L1 & L2 nodes in the network, how efficiently we can route requests for content, and so on. To discover these aspects, we need to have some form of the Station up and running as soon as feasible.
  • While Tauri offers a much lower (memory) footprint compared to Electron, we don’t have any experience with the Tauri platform. Writing Station backend in Rust will take more time than in Electron (Node.js) because our team is more familiar with Node.js than Rust.

Based on the above, I am proposing to move forward with the architecture of ipfs-desktop: an Electron app for GUI, a background process written in Go for the Saturn integration. I am also proposing not to worry about the extensibility needed to support additional Station modules. Let’s delay the related architectural decisions until we start working on the second or third module. We will have a much better understanding of the problem space by then.

FIL wallet integration

Assumption:

All activities in Station will be incentivised by earning FIL. Most (if not all) Station modules will need a FIL address where to receive incentives.

While it’s possible to leave the responsibility of managing a FIL wallet up to every station module, I feel that would lead to a poor user experience and code duplication between modules.

  • Each module would need to implement a workflow for creating and importing a wallet.
  • Users can either create a new wallet for every module, in which case they will have to back up several wallet seeds. Or they can import the seed from one module into others, which is IMO confusing.

I am proposing the following design & architecture:

  1. Station Desktop app manages a single FIL wallet. It provides UX for creating a new wallet, importing a new wallet, creating new addresses, assigning addresses to individual Station modules (*), and inspecting the FIL balance of individual addresses.

    (*) Initially, we should limit the feature scope address management and automatically create one address for each Station module. For the v0 release, we will simply create one address to be used by the Saturn node and that’s all.

    This constitutes the first Station module: a FIL wallet. I am proposing to keep things simple and implement this module as a hard-coded built-in component.
  1. As part of the setup process of a new Station module, the Station app assigns the module a public FIL address. We will hardcode this step for v0, with the option to make it user-configurable via UI in the future.

Security model

For security reasons, Station Modules will only have access to the FIL address (the public key) of the wallet provided by the Station Shell. A unique address will be created for each Station module so that modules cannot spy on transactions initiated by other modules.
If the module wants to perform operations requiring the private wallet key, then such operations will be handled by the station shell, and the shell will ask the user to confirm the transaction. We don’t need this feature yet; we can defer the implementation after the v0 release.

Hardware wallets

Do we want the Station should support popular hardware wallets like Ledger and Trezor?

On the one hand, the Station wallet should be used only for collecting FIL in exchange for Station-related activities. Once a more significant amount is accumulated, the user should transfer it to a more secure wallet.

On the other hand, if the Station can ask the HW wallet to generate a new FIL address, then we can use that address for accumulating FIL rewards for station-y activities from the beginning and there is no need to remember to transfer the rewards to a more secure location.

Docs on integrating Ledger with Electron-based apps:

Node HID integration
Estimated reading time: More than 10 minutes In this section, we will guide you through the creation of a desktop electron application. This application will be connected to your Nano to display the address of your account (eg. bitcoin account, ethereum account). Before starting, make sure you have gone through the prerequisites.
https://developers.ledger.com/docs/transport/node-electron-hid/

Examples showing Trezor integration with Electron:

connect/examples/electron at develop · trezor/connect
link: A platform for easy integration of Trezor into 3rd party services - connect/examples/electron at develop · trezor/connect
https://github.com/trezor/connect/tree/develop/examples/electron

An idea for a minimal solution

Assuming the HW wallets allow the user to create a new FIL address using their own UI (e.g. the Trezor desktop app), then all we need in Station is to allow the user to give us that address and use it for the Saturn node.

Associating an existing FIL address with the Station could be a feature helpful in testing the app so that we don’t have to create/import a wallet every time we set up a new instance.

Next steps:

  • Reach a consensus about the proposed wallet integration. (Even before that, reach an agreement about the Desktop architecture for v0.)
  • Work with @Patrick Woodhead to find out who can help us create UX & UI design for the wallet.
  • Define an implementation plan, and create GitHub issues for individual tasks.
  • Start working on the implementation 💪🏻

https://www.notion.so/Filecoin-Station-60fea705ee2a426883ea2c8759399f3d

Frontend architecture

IPFS inspiration

Let’s take a look at how ipfs-desktop packages the frontend UI app:

  1. The frontend is a standalone single-page application written in React using create-react-app, see https://github.com/ipfs/ipfs-webui. This app is deployed to https://webui.ipfs.io/.
  1. The IPFS backend (go-ipfs) includes the frontend too. When your IPFS backend is running, you can open the UI in your browser: http://127.0.0.1:5001/ipfs
  1. Also IPFS Desktop includes the frontend. When you start the desktop app, it will show the bundled version of the UI.

The frontend is communicating with the IPFS daemon over HTTP. By default, the frontend connects to http://127.0.0.1:5001/. When the connection fails, the status page offers the user an option to enter a custom API address.

Proposal

I am proposing to split Station UI into two parts:

  • The Station Shell UI provides the top-level Station UI - list of modules, a status page, a configuration screen, and so on. This UI is packaged as part of the Electron application and updated via the Electron auto-updater.
  • Each Station Module ships its own UI as part of the Module distribution package. The UI is updated together with the backend (Saturn L2 node) via the module-update mechanism we want to build. In other words, this is the same mechanism as described in point 2 above.

We can implement the Wallet either as a Station Module exposing API allowing the Station to generate new FIL addresses or as a built-in part of the Station Shell. Let’s defer this decision until we start building the Wallet.

Benefits

  • Fewer integration points. The Station Shell creates <iframe> and points it to the HTTP server provided by each Module. We will use standard web platform features to compose the Shell and the Modules.
  • Modules can be running independently of the Station app. For example, it will be possible to run the Saturn L2 node on a home router or a Rasperry Pi, and access the UI from a browser running on a desktop or a mobile phone.
  • Each Module can choose the communication channel between the UI and the backend that works best for them.
  • The frontend (WebUI) and the backend (Saturn L2 node) are always in sync. We don’t need to worry about the backward & forward compatibility of their communication protocol.
  • An easy upgrade process: module upgrader downloads a single binary to update both the frontend and the backend.
  • Frontend parts of the Station Modules are updated independently of the main desktop app.
  • If needed, we have the option to release Saturn L2 Node before the Station desktop app is ready.

Trade-offs

  • The front end is split into multiple projects, there are more moving parts involved. Implications:
    • Getting and preserving a consistent look & feel between the Station and all Modules requires additional effort. Not an issue for v0, but in the longer term, we may need to create design guidelines and a shared set of assets (CSS styles, icons, images, fonts).
    • Major UI changes will require coordinated work in the Station and all Modules. Because the Station Shell and Modules can be upgraded independently, the user can still end up with inconsistent UI: new Shell UI with an old Module UI, old Shell UI with a new Module UI.
    • Debugging the entire app (Shell, Module frontend Module backend) requires multiple components to be wired up together.

    In a way, this is similar to trade-offs between Monolith vs. Microservices.

Code organization

  • Let’s create a new GitHub repository for Web UI for the Saturn L2 node, similarly to how there are ipfs-webui and go-ipfs for IPFS.
    Example repo name: filecoin-project/saturn-L2-webui
  • Let’s keep Station Shell Web UI inside the Electron app repository: https://github.com/filecoin-project/filecoin-station
    Some parts of the Shell UI will need access to Electron & Node.js APIs, they cannot run as a standalone web app. Few examples of such parts:
    • Code showing all Modules installed in the Station.
    • Code to obtain the status of a Module backend process (is it running?) and initiate start/stop/restart.
    • “App Store” part installing additional modules into the Station app.
  • The L2 node should pull the Web UI bundle from the Web UI project, include it in the Go binary and expose it via HTTP. We can replicate the setup from go-ipfs.
    Initially, we will pull the WebUI using traditional methods, e.g. downloading from GitHub releases. Later, we should fetch the WebUI over IPFS.
  • To make our life easier when making changes in all three components (Shell, Module backend, Module frontend at the same time, e.g. when troubleshooting a bug: we need to set up a dev env that links dev versions of all three components together. Ideally, the Shell running in a Dev mode should be rendering the Module frontend served by a dev-server with live reloading, so that after every change in the Module frontend we don’t have to rebuild both Module frontend & backend and restart the Module backend.

    For example, we can set up a dev proxy server to route requests to Module WebUI assets to the WebUI dev server and Module backend requests to the module backend process.

Communication channels

Station Shell ←→ Station Module

Use cases:

  1. The Shell starts the Module and needs to provide configuration options. E.g. Saturn L2 Node config: FIL address, our Region.
    → The config can be provided via ENV vars.
  1. The Shell needs to stop the Module: the app is quitting, upgrading to a new module version, the configuration like FIL address was changed, etc.
    → Can we use the standard mechanism used by the operating system to ask the app to exit? Start with a gracious signal, then force quit after a reasonable delay.
  1. A Module wants to communicate its status: starting, running, stopping. Connected to the network, booted from the network because of an old version, etc.
    → Option 1: The Module provides HTTP endpoints for status. The Shell periodically calls this endpoint.
    → Option 2: The Module prints status to stdout in a pre-agreed format. The Shell parses Module output and detects status messages.
    → I am proposing to start with Option 2.
  1. What else do we need for v0? Do we need to exchange any messages between the Shell WebUI and the Module WebUI?
  1. Authorisation for HTTP API:
    1. Lotus nodes have the concept of access tokens with read/write/admin scopes.
    1. IPFS nodes don’t implement any authorization (at least AFAICT).
    1. If we want to implement authorisation for Saturn L2 nodes, then it would be ideal to allow the Station to generate an access token and give it to the Saturn L2 node via ENV vars, so that the Station operator is already authorised to access the WebUI.

Choosing the frontend framework

There are two main contenders: vanilla React (create-react-app with react-router or vite with react-router) and Next.js

Vanilla React

  • Smaller scope. The app is a vanilla React project, and we can choose which components to use (e.g. the router).
  • ipfs-webui uses create-react-app
  • Vite offers faster build tooling and an integrated test runner Vitest

Next.js

  • An opinionated framework that provides many features on top of React, like convention-based routing using file paths.
  • It compiles code using a Rust-based alternative to Babel - this should offer much faster build times than create-react-app.
  • Many features like server-side rendering and static-site-generation are not relevant to us.

Random notes

Routing: path-based (/about) vs hash-based (/#/about).

  • The latter is used by ipfs-webui.
  • I am not sure if Next.js supports hash routing. OTOH, maybe we can rewrite URLs in the Electron layer before they reach the Module server.

Next.js is pushing a lot for static generation at build time. For content that changes often, we need to opt-out.
Quoting from https://nextjs.org/docs/basic-features/pages#when-should-i-use-static-generation

On the other hand, Static Generation is not a good idea if you cannot pre-render a page ahead of a user’s request. Maybe your page shows frequently updated data and the page content changes on every request.
(…)
Use Static Generation with Client-side Rendering: You can skip pre-rendering some parts of a page and then use client-side JavaScript to populate them. To learn more about this approach, check out the Data Fetching documentation.

Integration with Electron

There are several npm packages to simplify the integration of Next.js with Electron. Unfortunately, they are struggling to sustain the ongoing development and maintenance.

  • nextron - discussion #244 has the title that says it all: Looking for maintainers.

FWIW, the PoC frontend in filecoin-station is using nextron - see the PR filecoin-station#12

Instructions on setting up a new create-react-app + Electron project - I think many of the tweaks are applicable for Next.js too.
https://mmazzarolo.com/blog/2021-08-12-building-an-electron-application-using-create-react-app/
Another tool for setting up create-react-app for Electron: https://github.com/electron-react-boilerplate/electron-react-boilerplate

Conclusion

Based on what I learned so far from docs and talking to friends familiar with Next.js, my conclusion is that Next.js is NOT suited for our use case. It provides features that we don’t need and what’s worse, which will require extra effort to neutralize.

I am leaning towards using Vite + react-router + Vitest.

CSS & UI components

ipfs-desktop uses tachyons.io Unfortunately, this framework seems to be abandoned - the last release was in Jan 2018. Also the user satisfaction is rather low according to State of CSS.

I am proposing to use TailwindCSS and HeadlessUI, or even TailwindUI if we can pay for the license. EDIT: suggested to use https://daisyui.com/: It is Tailwind based, prestyled (aka timesaver), has a ton of components, and is free!

Module upgrades

Areas to explore:

  • How & where is Station going to discover new Module versions.
    • GitHub Releases
      Each module provides metadata about its GitHub repository to the Station.
      The Station periodically checks for a new release.
    • IPNS & IPFS
      Each module provides an IPNS address to obtain the list of all versions, where each version can be downloaded from an IPNS address using a shared naming convention.

      The Station periodically checks for a new release.

      $ ipfs cat /ipns/dist.ipfs.io/go-ipfs/versions
$ ipfs ls /ipns/dist.ipfs.io/go-ipfs/$VERSION
$ ipfs get /ipns/dist.ipfs.io/go-ipfs/$VERSION/go-ipfs_$VERSION_linux-arm.tar.gz
    • Pub/sub via libp2p
      When a new module version is released, the network operator broadcasts a message telling Stations about the new version.
      The Station is subscribed to these messages.
      Caveat: What if the Station is offline or not running when the message is broadcasted?
  • How can Saturn network operators notify users about a new version?
    • Leave it up to the Station app to discover the new version.
    • Send an email to the operator’s registered address.
    • (what else?)
  • How will the Station notify the user about the new version?
    • A banner in the Station
    • A pop-up notification, a badge in the systray, etc.
    • (what else?)
  • What options has the Station operator? Which ones are required for v0?
    • Upgrade immediately
    • Schedule the upgrade for a given period (e.g. Sunday morning)
    • Skip this particular version
    • Unattended mode - the upgrade is applied automatically by the Station.
    • (anything else?)
  • What happens if the Station operator stays on an old version
    • It’s up to the network to decide what versions can participate and which nodes are kicked out because of an incompatible version.
    • How can the network signalise to the node that it’s no longer allowed to participate in the network?
    • How can the Station Module signal this information to the Station Shell?
    • Which part of the WebUI (Shell vs Module) will present this information to the operator? Maybe both?
  • How to detect and handle the case where the new Module version requires a more recent Station version than the operator is currently running?

Initial version

I am proposing to start without custom Module Upgrades, bundle the Saturn L2 node into the Station desktop app and use the Electron auto-update process for upgrading both Station Shell and Saturn L2 node together.

Depending on the timing and other priorities, we can implement the custom module updater as part of the v0 release or leave this feature for later.

Roadmap to v0 [NO LONGER RELEVANT]

  1. Walking Skeleton (see definition) - Station Shell
    1. Frontend infrastructure for Shell WebUI, including a smoke test at unit-level and browser/electron/end-to-end level. Possibly also an integration smoke test to ensure we have set up the required infrastructure for testing.
    1. CI/CD process - linter checks, build step(s), run the tests.

      → There is already an automated CD process in place to build release artefacts for each git tag.

    1. A bundled Saturn L2 Node executable. A semi-automated workflow for pulling new versions, e.g. “run this script, commit these changed files, open a pull request”.
      → See https://github.com/filecoin-project/filecoin-station/issues/19
    1. Start/stop Saturn L2 node, show status in the UI. Including basic unit/integration/e2e tests. Use a hard-coded dummy FIL address from a test-net account.
      → https://github.com/filecoin-project/filecoin-station/issues/20
    1. Show Saturn L2 WebUI in an <iframe>, including basic test coverage.
      → https://github.com/filecoin-project/filecoin-station/issues/21
    1. Developer Guide (minimal): architecture overview, how to set up the dev env, how to make changes, how to run the tests, etc.
      → https://github.com/filecoin-project/filecoin-station/issues/22

    Prerequisites:

  1. Walking Skeleton - Saturn L2 WebUI
    1. A new GitHub repo with a LICENSE, with issues & projects enabled, teams & permissions configured, etc.
    1. Frontend infrastructure, see 1a above.
    1. CI/CD process, including a semi-automated process for publishing new versions to the npm registry and a semi-automated process for pulling this new release into filecoin-station repo.
    1. Developer Guide (minimal) - see 1g above.
  1. Dev setup for faster iteration on changes spanning both the Station UI and Module UI. See https://www.notion.so/pl-strflt/Station-Architecture-e2bf38821395485292a55b8a9b66a00b#1b34b3efcd024019ac0d4e7f0b74b944
    → https://github.com/filecoin-project/filecoin-station/issues/24
  1. WebUIs - order of tasks to be determined later
    1. Saturn L2 Node WebUI
    1. Station Shell WebUI
    1. Configuration of the FIL address inside the Station app
  1. Later we can add “should have” features
    1. Module configuration.
      For example, Saturn L2 Node needs to know which Region it is running in. The Settings UI can be a part of the Station Shell or inside the Module UI - this may need a bit of research before we decide.
    1. Custom module auto-updater, as discussed in Module Upgrades above.
    1. First steps towards a built-in FIL Wallet: show the current balance of the FIL address, show (recent?) transactions.