b35a3d6574
There has been over 1 year of commit history leading up to this point, but almost all of that has had some kind network configuration or secrets built into the code. As of today all of that has been removed, and the codebase can finally be published! I am keeping a private copy of the previous commit history, though it's unclear if it will ever be able to be published.
88 lines
3.5 KiB
Markdown
88 lines
3.5 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).
|
|
|
|
### 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.
|