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:
|
Besides documentation, there are a few other pages which might be useful:
|
||||||
|
|
||||||
* [Roadmap][roadmap]
|
|
||||||
* [Glossary](docs/glossary.md)
|
* [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"
|
"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{
|
var subCmdDaemon = subCmd{
|
||||||
name: "daemon",
|
name: "daemon",
|
||||||
descr: "Runs the isle daemon (Default if no sub-command given)",
|
descr: "Runs the isle daemon (Default if no sub-command given)",
|
||||||
|
@ -22,6 +22,11 @@ func newHTTPServer(
|
|||||||
*http.Server, error,
|
*http.Server, error,
|
||||||
) {
|
) {
|
||||||
socketPath := daemon.HTTPSocketPath()
|
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)
|
l, err := net.Listen("unix", socketPath)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
return nil, fmt.Errorf(
|
return nil, fmt.Errorf(
|
||||||
|
@ -75,6 +75,14 @@ func dnsmasqPmuxProcConfig(
|
|||||||
Cmd: filepath.Join(binDirPath, "dnsmasq"),
|
Cmd: filepath.Join(binDirPath, "dnsmasq"),
|
||||||
Args: []string{"-d", "-C", confPath},
|
Args: []string{"-d", "-C", confPath},
|
||||||
StartAfterFunc: func(ctx context.Context) error {
|
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)
|
return waitForNebula(ctx, logger, hostBootstrap)
|
||||||
},
|
},
|
||||||
}, nil
|
}, nil
|
||||||
|
Loading…
Reference in New Issue
Block a user