Roadmap has been moved to micropelago.net

README.md

@@ -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

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.

go/cmd/entrypoint/daemon.go

@@ -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)",

go/cmd/entrypoint/daemon_util.go

@@ -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(

go/daemon/child_dnsmasq.go

@@ -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