5.5 KiB
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.
NATS
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.
Integration of domani
Integration of domani will require some changes on domani's end. We want domani to be able to store cert information in S3 (garage), so that all isle lighthouse nodes can potentially become gateways as well. Once done, it would be possible for lighthouses to forward public traffic to inner nodes.
It should also be possible for users within the network to take advantage of domani's hosting ability even without an always-on host of their own, without requiring a passphrase.
Most likely this integration will require NATS as well, to coordinate cache invalidation and cert refreshing.
Web server + interface
Have every isle daemon run a webserver as one of its sub-processes. 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.
Invitation code bootstrapping
Once an HTTP gateway/load-balancer 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 stored, encrypted, 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 domain name and the invite code.
FUSE Mount
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.
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.
Design System
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:
- Color schemes
- Fonts and text decoration in different situations
- Some simple, reusable layout templates (splash page, documentation, form)
- Basic components like tables, lists, media, etc..
DHCP
Currently all hosts require a static IP to be reserved by the admin. Nebula may support DHCP already, but if it doesn't we should look into how this could be accomplished. Depending on how reliable DNS support is it may be possible to use DHCP for all non-lighthouse hosts, which would be excellent.
IPv6 network ranges
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.
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 isle install sub-command which would
auto-detect the installed operating system and install the daemon automatically.
Mobile app
To start with a simple mobile app which provided 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 we can at least use it as a reference to see how this can be accomplished.
Don't run as root
It's currently a pretty hard requirement for isle 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.
On linux it should be fairly straightforward to grant the entrypoint the necessary ambient capabilities up-front, and then drop down to a specified user. This is how the tests work. Doing this with other OS's will depend on how they work.
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.