101 lines
3.9 KiB
Markdown
101 lines
3.9 KiB
Markdown
# 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.
|