We return to registering members of a community and provisioning wiki sites for their collaboration. This time we may make it simple enough to work.
We propose a solution in three parts: a plugin that creates a new site, an html landing page that collects and validates new user information before invoking the plugin's server-side, and, a server configuration option that prevents the older mechanism of create on first reference.
# History
We've explored various versions of this and have some incomplete or unsatisfying implementations.
Registration Workflows for making subdomains.
Private Pods with collective acknowledgement.
Open Membership in a Club version of a Roster.
Pop-Up Community with downloadable app.
Community of the Moment present and paying attention.
Organizing Large Communities hosted on wiki.
# Solution
Now our solution as a series of small steps to be coded, tested and and then reviewed to be sure we are making useful modifications and not closing off more useful options later on.
Write in html a custom home pages that can be uploaded as a home/index.html asset at any level of a domain name hierarchy served by a farm.
- Sample: tries.fed.wiki 
assets github
Code in html the collection, validation and submission of registration information such as user name, preferred subdomain and event registration code. Check for duplicates. Submit and report success.
Code in a server-side plugin the endpoint that will validate entries and provision a minimal site, possibly just the expected subdomain directory. See Register Plugin
Create the configuration option that will disable automatic registration of farm sites on first reference, probably a variation of the --allowed option. When selected, one must use some other mechanism, like the custom landing page to create new sites. See Restricting Wiki Farm Growth
# Prototype
Here we have two sites, one offering landing page registration, the other a registered site with peers.
tries.fed.wiki: I often invite folks to try authoring in federated wiki by suggesting they make a subdomain of this site. We have prepared a custom landing page for self-service provisioning. home
ward.tries.fed.wiki: I'm testing some improvements of the search/scrape machinery. I've made this new site but scrape hasn't found it yet. What's up with that?
# Catalog
We can foresee sufficient configuration complexity that we should offer a catalog of html assets and preconfigured Register plugins designed for typical group enrollment situations.
The catalog would consist of a curated site and perhaps many derivative sites following the same model. The site would be composed as a decision tree leading to a most suitable configuration expressed as a single page with both Register plugin and Assets folder ready to be forked into a new site.
# Enhancements
Consider how proper oauth login could be required, checked and forward to the provisioning endpoint from the custom landing page.
Consider how event specific welcome-visitors-template could be instantiated for new sites.
Consider how a proper user page could be created for the new user.
Consider how the new site could be automatically appended to the event roster. (When will the flag be created?)
Consider how the new site could (optionally) create further subdomains, possibly restricted to identical ownership.
Consider how new users learn of others in their cohort. We expect some variation of Roster or Present plugins. See About Present Plugin