💾 Archived View for micropelago.net › roadmap.gmi captured on 2024-09-28 at 23:37:34. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
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.
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.
Isle needs to support a single host being a member of multiple networks. It's better to do this prior to working on a GUI, as adding this later will require refactoring the GUI anyway. This will require a couple of changes to the format of the daemon configuration file.
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:
All of those abilities need to be present on the command-line as well. Notably, the "Allow for configuration of the host" feature will require some logic to differentiate configuration provided at runtime vs configuration provided via the daemon config file.
Support for Windows is a must. The difficulty here will be getting the garage sub-component compiled for Windows, as it's not currently a supported build target.
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.
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.
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.
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 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.
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.
KBFS style. Every user should be able to mount virtual directories to their host which correspond to various buckets in garage.
- "public": editable amongst all users on the host, shared publicly via HTTP gateway.
- "protected": editable amongst all users on the host, but not accessible outside the network.
- "private": only accessible to a particular user (client-side encrypted).
Whether it's necessary to support directories which are shared only between specific users remains to be seen. The identification of a single "user" between different hosts is also an unsolved problem.
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.
It would be great to get some help from a designer or otherwise artistically-minded person to create some kind of design framework which could be used across publicly-facing frontends. Such a system would provide a simple but cohesive vision for how things should look, include:
It should theoretically be possible for the internal network IP range to be on IPv6 rather than IPv4. This may be a simple matter of just testing it to confirm it works.
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.
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.
Ideally Isle could detect the DNS/SSL/firewall subsystems being used on a per-OS basis and configure them as needed. This would be simplify necessary documentation and setup steps for operators.
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.