ds-host server should support multiple ways of reaching it

[teleclimber]

Currently ds-host server configuration is inflexible. It requires a domain name, for example, making it impossible to just start on localhost.

This issue is about outlining the possible ways to conect that should be supported (some day).

Current Config Fields

Currently the config for ds-host has these relevant fields:

Server

http port, tls port, no-tls and tls-cert.

External Access

scheme, domain, subdomain, port.

Docs say: "The values here are essentially used to create links in the interface that the user will follow."

Question: what is the definition of "external"? See scenarios below.

Manage TLS certificates

ACME stuff for obtaining TLS certs.

[teleclimber]

Different ways of accessing Dropserver

It should be possible to use Dropserver using the below scenarios:

localhost

User installs ds-host on their machine, they can reach it from localhost. Some browsers allow subdomain on localhost, so access to appspaces is doable.

TLS on localhost is maybe even possible? But it's very limiting for a server. Also not as important because localhost gets secure context anyways.

Need: server on 127.0.0.1, port. Maybe a TLS cert?

Localhost, public domain name

Like dropid.local.dropserver.org.

Is this still relevant? Useful in some way? Maybe for cases where localhost doesn't allow subdomains? But then there is no secure context!

Local network, IP only

Access to ds-host using its IP and port. No access to appspaces because no (sub-)domain names. No TLS over bare IP (though that may become possible?).

Very limiting, but useful for admin tasks within the home network.

Need: server on non-localhost IP. Which interface / IP? Need port.

Local network, mDNS

Same as above, but ds-host could broadcast mDNS names for both user admin and appspaces.

TLS is possible (I think?) with a local CA. However there are no subdomains on .local, so there are no wildcard certs! Either ACME to local CA, or...?

Need: same as above, plus mDNS config. ACME config for local CA.

Local network, internal DNS, non-unique internal domain name (.home.arpa.)

Network has PiHole or dnsmasq running and they can just make up a domain (or use .something.home.arpa) and point everything to ds-host.

TLS is possible with self-signed or local ca.

Local network, public domain name

admin has a registered domain name and they use public DNS to point to local network.

TLS is possible using public infrastructure if you use DNS challenge and have an API to name server.

Need: same as local network. ds-host needs awareness of domain and ACME config for TLS.

Public network, public domain name

ds-host is accessible from the Internet. Registered domain name pointing to public IP.

TLS possible and basically required.

Need: public IP, awareness of domain.

[teleclimber]

Taking the above scenarios, and looking at each of names, TLS cert config, Servers and External Access.

Names

Can be localhost, mdns (.local), internal domain (.home.arpa), public domain name. Each with constraints and capabilities.

TLS certs

Options: none, admin-supplied cert (self-signed or signed by local CA), managed by ACME (acme endpoint and config needed), wildcard cert managed by ACME (also requires config for DNS challenge)

Options should be per-name so that .home.arpa. names could have a wildcard self-signed cert, while somedomain.com can be lets' encrypt.

I'm unsure of the interface for admins to add their own certs. Maybe a special directory, kind of like nginx is all that's needed. And a way to trigger a reload of the dir.

Servers

IPs/interfaces, ports, whether to start TLS.

The only change is tls-cert should be removed, or it should be a directory.

External Access

Still need to think about this. Maybe it's tacked on as optional data for each name. So if you have a no-TLS server on :5050 and a "somedomain.com" name then by default links are http://somedomain.com:5050. But with "external access" or some other field you can specify "use-tls", "http-port", "tls-port" and make the links https://somedomain.com to get correct links to your reverse proxy.