micropelago/isle
4
1
Fork 0
Code Issues 1 Pull Requests Projects Releases 5 Activity
6ba8b948c2
isle/docs/roadmap.md
Brian Picciano 3ac86e07cf Use yaml instead of tgz for bootstrap file
2022-11-02 14:34:40 +01:00

3.7 KiB
Raw Blame History

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.

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.ymls. 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. The main changes needed would be:

  • Allow importing a bootstrap.yml file, rather than requiring manual setup by users.

  • Set device's DNS settings. There is an open PR 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.