Here we think through how one could host a wiki farm for themselves and friends without opening hosting for the world. matrix 
See Zero-Steps to Claim for earliest thoughts.
Say I have a list of names and emails, how would I make sites for everyone on the list and get them the right credentials to use it? Or, say I am at a meetup and want to open signup at the meetup for anyone there and then close it for anyone else after that?
Our current farm behavior is to create sites on first reference. What if we reconsider this?
One idea would be to redirect non-existent fetches to the first superior name that exists. This domain would then have the opportunity to manage its own expansion.
As is, no expansion would happen. But a site might add a plugin that subscribes new members by some workflow configured into that plugin. The server administrator retains some control by restricting which new site workflow plugins are available.
See Register Plugin for the simplest of examples.
Such a plugin and the workflow that it administers could be 2x more complicated that the Club plugin suggested here before which would allow sites to join a Roster maintained on another site. That alone enabled abuses that were hard to think through. The delegation of rights to new sites is even more complex but just being wide open as we are now is probably a non-starter as we grow.
See Open Membership in a Club for similar complexities.
# Invitations
The best login experience would be through giving users a temporary and hard to guess url which would expire after a given period. We could simply generate an invitation to include information that the site-owner/author chooses.
When a new user visits this page they can interact with resources there in order to create and customize their site. The invitation and the provisioned site should recognize the context of the invitation and provide custom content for each new site.
It would be important that resources created for in-progress invitations not show up in a site search.
# Discovery
These could work the same as Secure scuttlebutt, in that multiple local severs would be able to discover each other over the LAN with multicast UDP and connect (via a roster?).
# Caddy
A reverse proxy in front of a farm makes for convenient automation of TLS certificate registration for new domains. This requires additional configuration.
github
https://example.com, http://example.com, https://*.example.com, http://*.example.com:80 gzip tls { max_certs 4 } proxy / farm:3000 { transparent }
The `max_certs` directive within the `tls` block is required. Caddy thereby limits potential abuse of local disk space and of letsencrypt for that matter. doc
> Mitigating abuse: This feature is intentionally rate-limited. The max_certs property of the tls directive sets a hard limit on how many new certificates are issued this way, so that even over a long period of time, attackers cannot issue unlimited certificates and fill up your disk space.
I currently write in four subdomains. If I were to create a new subdomain, I would add 1 to the max_certs directive, restart caddy, and then visit the domain in my browser to cause the farm to instantiate the new wiki.
It happens that letsencrypt will start offering wildcard certificates in January 2018 and Caddy plans to support them. Perhaps this specific complication will resolve itself.
The details here are specific to Caddy, but probably generalize to any similar reverse proxy using letsencrypt ACME protocol to obtain certificates automatically.
How will registration of a subdomain of a farm interact with certificate negotiations or any other administered configuration? More markup? Delegate to shell script?