Roadmap has been moved to micropelago.net
This commit is contained in:
parent
39e12f6ebd
commit
4f6a89ced0
@ -105,7 +105,4 @@ Documentation for devs:
|
||||
|
||||
Besides documentation, there are a few other pages which might be useful:
|
||||
|
||||
* [Roadmap][roadmap]
|
||||
* [Glossary](docs/glossary.md)
|
||||
|
||||
[roadmap]: docs/roadmap.md
|
||||
|
||||
128
docs/roadmap.md
128
docs/roadmap.md
@ -1,128 +0,0 @@
|
||||
# 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.
|
||||
|
||||
### Windows Support + GUI
|
||||
|
||||
Support for Windows is a must. This requirement also includes a simple GUI,
|
||||
which would essentially act as a thin layer on top of `daemon.yml` to start
|
||||
with.
|
||||
|
||||
Depending on difficulty level, OSX support might be added at this stage as well.
|
||||
|
||||
### 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 [Caddy](https://caddyserver.com/docs/)
|
||||
|
||||
Integration of Caddy's will require some plugins to be developed. We want Caddy
|
||||
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 use lighthouse
|
||||
Caddy's to host their websites (and eventually gemini capsules) for them.
|
||||
|
||||
Most likely this integration will require NATS as well, to coordinate cache
|
||||
invalidation and cert refreshing.
|
||||
|
||||
### 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.
|
||||
|
||||
### Proper Linux Packages
|
||||
|
||||
Rather than distributing raw binaries for Linux we should instead be
|
||||
distributing actual packages.
|
||||
|
||||
* deb files for debian/ubuntu
|
||||
* PKGBUILD for arch (done)
|
||||
* rpm for fedora?
|
||||
* flatpak?
|
||||
|
||||
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 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.
|
||||
|
||||
### DNS/Firewall Configuration
|
||||
|
||||
Ideally Isle could detect the DNS/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.
|
||||
|
||||
### 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.
|
||||
@ -10,6 +10,10 @@ import (
|
||||
"dev.mediocregopher.com/mediocre-go-lib.git/mlog"
|
||||
)
|
||||
|
||||
// TODO it would be good to have an `isle daemon config-check` kind of command,
|
||||
// which could be run prior to a systemd service restart to make sure we don't
|
||||
// restart the service into a configuration that will definitely fail.
|
||||
|
||||
var subCmdDaemon = subCmd{
|
||||
name: "daemon",
|
||||
descr: "Runs the isle daemon (Default if no sub-command given)",
|
||||
|
||||
@ -22,6 +22,11 @@ func newHTTPServer(
|
||||
*http.Server, error,
|
||||
) {
|
||||
socketPath := daemon.HTTPSocketPath()
|
||||
|
||||
// TODO I restarted isle once and when it came back up it errored here
|
||||
// because the socket file already existed. isle should delete the file
|
||||
// during shutdown, but it should also check if the file exists on startup
|
||||
// in case shutdown wasn't clean.
|
||||
l, err := net.Listen("unix", socketPath)
|
||||
if err != nil {
|
||||
return nil, fmt.Errorf(
|
||||
|
||||
@ -75,6 +75,14 @@ func dnsmasqPmuxProcConfig(
|
||||
Cmd: filepath.Join(binDirPath, "dnsmasq"),
|
||||
Args: []string{"-d", "-C", confPath},
|
||||
StartAfterFunc: func(ctx context.Context) error {
|
||||
// TODO consider a shared dnsmasq across all the daemon's networks.
|
||||
// This would have a few benefits:
|
||||
// - Less processes, less problems
|
||||
// - Less configuration for the user in the case of more than one
|
||||
// network.
|
||||
// - Can listen on 127.0.0.x:53, rather than on the nebula address.
|
||||
// This allows DNS to come up before nebula, which is helpful when
|
||||
// nebula depends on DNS.
|
||||
return waitForNebula(ctx, logger, hostBootstrap)
|
||||
},
|
||||
}, nil
|
||||
|
||||
Loading…
Reference in New Issue
Block a user