isle/docs/roadmap.md

# Roadmap

The following are rough outlines of upcoming work on the roadmap, roughly in the
order they will be implemented.

## Main quest

These items are listed more or less in the order they need to be completed, as
they generally depend on the items previous to them.

### Cross Compilation

Currently the only supported OS/CPU is Linux/amd64. This can be expanded
_theoretically_ quite easily, using nix's cross compilation tools. First target
should be OSX/arm64, but windows would also be quite the get.

### Bootstrap

This will be difficult. There's currently no way to bootstrap a new cryptic-net
network from scratch, only the currently existing one is supported. Support for
IPv6 internal CIDR should also be a part of this effort.

### Testing

Once bootstrap is generalized, we'll be able to write some automated tests.

## Side quests

These items aren't necessarily required by the main quest, and aren't dependent
on any other items being completed. They are nice-to-haves that we do want to
eventually complete, but aren't the main focus.

### DNS resolver settings

The daemon should update the resolver settings of the host, so that it
automatically serves DNS queries, unless set to not do so in `daemon.yml`.

### Install sub-command

It would be great to have a `cryptic-net install` sub-command which would
auto-detect the installed operating system and install the daemon automatically.

### Web server + interface

One idea is to have every `cryptic-net daemon` run a webserver as one of its
sub-processes. This server could serve multiple functions:

- Possible public gateway, if the host is configured to be public, into internal
  cryptic-net services. This will require some sort of service discovery
  mechanism that other hosts in the network can easily hook into via their
  `daemon.yml`s. Ideally this mechanism would involve little beyond updating
  entries in garage, which the public gateways then pick up on.

  One wrinkle here will be TLS certificates. Ideally internal hosts could host
  websites publicly via the gateways on their network, using arbitrary domains
  that the users own. The gateways will need some way of obtaining certs for
  these domains automatically (or as automatically as possible).

- Local interface for the `cryptic-net daemon` process. For example, status and
  connectivity information for the local host could be provided via a simple web
  interface, which the user can open in their browser. This saves us the effort
  of needing to develop UIs for individual OSs. This could also make remotely
  debugging hosts easier for admins.

### Mobile app

To start with a simple mobile app which provided connectivity to the network
would be great. Such a mobile app could be based on the existing
[mobile_nebula](https://github.com/DefinedNet/mobile_nebula). The main changes
needed would be:

- Allow importing a `bootstrap.tgz` file, rather than requiring manual setup by
  users.

- Set device's DNS settings. There is an [open
  PR](https://github.com/DefinedNet/mobile_nebula/pull/18) for android to do
  this upstream.

- Rebranding and possibly submitting to Apple app store (bleh).

### Don't run as root

It's currently a pretty hard requirement for `cryptic-net daemon` to run as
root. This is due to:

- nebula's network interface root to be started.

- dnsmasq listening on port 53, generally a protected port.

If we can't figure out how to get these things running from the start as
non-privileged users, we at least need to get cryptic-net to drop priveleges
from root after initial startup.

### Plugins

It would not be difficult to spec out a plugin system using nix commands.
Existing components could be rigged to use this plugin system, and we could then
use the system to add future components which might prove useful. Once the
project is public such a system would be much appreciated I think, as it would
let other groups rig their binaries with all sorts of new functionality.