Back to Home

🧭 Roadmap

The following are rough outlines of upcoming work on the roadmap, roughly in the order they will be implemented. This page acts as both a public record of where Micropelago is headed, as well as a brainstorming page for development details, and for that reason can get a bit technical.

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.

NATS Integration

Garage is currently used to handle eventually-consistent persistent storage, but there is no mechanism for inter-host realtime communication as of yet. NATS would be a good candidate for this, as it uses a gossip protocol which does not require a central coordinator (I don't think), and is well supported.

A sub-requirement of NATS integration is automatic firewall management by Isle. Because NATS will need to actively listen on a port, we must allow incoming traffic on the VPN's IP range. Currently operators are required to do this in order to provide storage to the network, but asking users to do this themselves is a bridge too far.

This is a direct requirement for developing a network-wide HTTP gateway. We want the HTTP endpoint to be loadbalanced across all public Isle hosts using round-robin DNS, but to do this they must share SSL certs. We can use garage for storage of certs, but coordinating renewal will require realtime communication.

Secret Sharing Framework

Every host manages secrets which give it certain capabilities, for example the ability to add new hosts or provide storage. There needs to be a mechanism for sharing these secrets between users in-App. Each secret being shared needs to have a proper description associated with it, so that the user knows the consequences of being in possession of it.

Ideally the mechanism would take advantage of garage, so the receiving host doesn't need to be online in order to receive a secret. It should also take advantage of NATS, so that secret sharing can be instantaneous if both hosts are online.

FUSE Mount

Dropbox/KBFS style. For a first step there should be a "protected" folder which is editable amongst all users on the network, but not accessible outside the network.

In the future there will also be a "public" folder (editable by all users on the network, viewable publicly via HTTP gateway) and a "private" folder which is only accessible to a particular user.

The names of all these folders is TBD.

Desktop GUI

For Isle, and Micropelago as a whole, to be considered accessible to non-technical users it must have a simple GUI. To start with the GUI should have the following features:

Develop a Distributed ID System

Each user is expected to have multiple devices, but will expect those devices to behave in a uniform way. For example, if they have a private storage bucket, that bucket should be accessible to them from all devices. Implementing this will require some kind of per-user shared secret, and some kind of flow where a user's existing device can be made to share that secret with a new device. NATS will probably prove useful here.

Caddy Integration

Caddy will be used to provide both an internal and public HTTP gateway service for a network. This gateway can then be used to host websites for all members of the network (not just Isle operators), as well as private and public services related to the network itself.

Isle operators will need to opt their host into being available to be an HTTP gateway, as it will require committing to being always-online. Hosts providing nebula lighthouses and storage can be automatically opted-in, as they will be expected to be always-online anyway.

For a host to be a *public* HTTP gateway will require:

Isle needs to provide an operator with detailed debugging information if any part of their network configuration is missing, e.g. the host is not publicly available or the required ports aren't public.

This integration will require NATS to coordinate cache invalidation and cert refreshing.

Invitation code bootstrapping

Once a public HTTP gateway is set up it should be possible to do host bootstrapping using invite codes rather than manually giving new users bootstrap files. The bootstrap file would be encrypted and stored in garage, with the invite code being able to both identify and decrypt it. To instantiate a host, the user only needs to input the network's public domain name and the invite code.

How invitation codes might work if a network doesn't have a public domain name is TBD.

Side quests

These items aren't necessarily required by the main quest. They are nice-to-haves that we do want to eventually complete, but aren't the main focus.

Proper Linux Packages

Rather than distributing raw binaries for Linux we should instead be distributing actual packages.

This will allow for properly setting capabilities for the binary at install time, so that it can be run as non-root, and installing any necessary `.desktop` files so that it can be run as a GUI application.

Mobile app

To start with, a simple mobile app which provides connectivity to the network would be great. We are not able to use the existing nebula mobile app because it is not actually open-source, but in the long run a Micropelago-specific app would be the way to go anyway.

DNS/SSL Configuration

Ideally Isle could detect the DNS/SSL subsystems being used on a per-OS basis and configure them as needed.

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.