Interfaces and platforms

Different interfaces to Flow will be useful to different users and for different use cases. They don't need to all exist for Flow to be useful, but thinking about what those interfaces are, who they might benefit, and when we should think about building them is probably still useful.

Ultimately, the different interfaces all allow users to access same functionality, namely:

- managing the lifecycle of a Flow instance
- proposing, accepting, amending, and canceling contracts
- activating contracts
- [performance](https://www.britannica.com/topic/performance-contract-law) of active contracts, i.e. paying according to the terms of active contracts
- monitoring performance of active contracts, i.e. verifying that payments are being received according to the terms of active contracts

However, users and use cases are very different:

An individual with many active contracts and high availability requirements may wish to host their Flow instance on a dedicated server; whereas a user who only uses Flow intermittently with a single active contract may find running Flow on their mobile device meets their needs.

Users with low trust in their counterparties may wish to keep their Flow instance running at all times, so they can receive breach alerts immediately; whereas users with high trust in their counterparties may be happy with intermittent uptime, confident that their counterparties will pay due funds as they are able to connect, and that non-payment due to technical issues can be easily resolved manually.

### Interfaces

- Library – Rust library exposing rich types and operations. The core building block of the other interfaces, useful for building any kind of Flow client or appliance.
- Foreign function interface – C-compatible wrapper around the Rust library. Useful for writing applications in languages other than Rust.
- Daemon – Headless service that can be controlled with RPC calls. I don't have enough experience with different RPC protocols to be confident in which to use, but JSON-RPC, gRPC, and REST are probably all reasonable choices. The daemon isn't useful on it's own, but serves as the backend for other interfaces.
- Command-line interface – Classic command-based interface. It can execute commands directly, or translate them into RPC calls against a local or remote daemon.
- Textual user interface (TUI) – Curses-style grid of characters interface. Can provide live status information and a more intuitive presentation of data.
- Graphical user interface (GUI) – Rich graphical interface. Not really a functionality improvement over a TUI interface, but can be prettier and more intuitive for users who are not used to text-mode applications.

The above interfaces may be self-contained, i.e. contain and manage a Flow instance lifecycle, or client-server, i.e. serve as thin frontends for interacting with a Flow instance that runs in the background or on another computer.

### Platforms

Orthogonal to the interfaces are the platforms on which they run. Ideally, users should be able to use Flow however and wherever they want, as long as we can make it secure on that platform.

Making Rust libraries, daemons, CLIs, and TUIs that run on MacOS, Windows, Linux, and other OSes is very doable, so likely those interfaces will be cross-platform from the beginning.

The story for cross-platform GUI applications in Rust is still evolving, and hopefully solid options will start to emerge. Some ideas for bringing users graphical applications that run on the web, and in Windows, MacOS, and Linux desktop environments are:

Some possibilities are:

- Bundling the TUI interface with a customized version of Alacritty. It would still be a text-mode application, but it would feel like a first-class native application, and might be more intuitive for users. Additionally, some hacks could make it quite nice, in a cyberpunk kind of way:
- Bundled font for a consistent look and feel across platforms, with custom glyphs for user interface elements.
- Support for touch gestures, which could make it usable on iOS and Android.
- Custom colors and fancy animations.

- GUI interface written with a cross-platform high-level Rust UI library, to produce native Web/MacOS/Linux/Windows/iOS apps. A high-level UI library provides ready-to-use components, like lists, check boxes, text fields, and the like, saving development time and effort. [gtk-rs](https://github.com/gtk-rs/gtk), a high-level library wrapping GTK 3 seems to be coming along nicely, and a less mature but very promising pure-rust candidate is [druid](https://github.com/xi-editor/druid).

- GUI interface written with a cross-platform low-level graphics library, to produce native apps on the same platforms. A low-level graphics library provides raw rendering primitives like lines, triangles, and textures. If we desire a high degree of control, a unique look, and uniformity across platforms, this would be a fun direction to explore. An unsafe, maximum-performance, low-level option is [gfx-rs](https://github.com/gfx-rs/gfx), and a higher level but easier-to-use option is [wgpu-rus](https://github.com/gfx-rs/wgpu-rs).