We imagine controlling visibility of wiki pages on a site or farm similar to operating a server on a private LAN but using distinguished logins rather than network access.
We will describe a simple configuration that might meet the needs of a school or company that manages email addresses within a specific domain name. We'll then consider variations on this base use case.
# School
All students and staff to be authorized to read will have authenticated with an email address at the school's unique domain already managed by the school.
Any so authenticated user can claim a not yet claimed site which will authorize write for that user alone.
An unauthenticated reader will be invited to authenticate with a suitable email address and little more. See Login Invitation
The suffix that distinguish a schools unique email domain will be specified by a server configuration parameter. See Participating Email Addresses
# Variations
A district with multiple schools might serve multiple domains from the same farm at distinct domains and with distinct email suffix conventions.
Multiple email domains might be configured with read access to a given wiki subdomain.
What if some classes at the school wanted private discussion for the class only?
A student or staff might be restricted to claiming subdomains consistent with their email address. See Registration Workflows
Retrieval of sitemaps should be similarly restricted to logged in users.
Server-side plugins would only be restricted if the plugin logic recognized the need for read authorization. For Rss plugin maybe yes, Json plugin maybe not.
It is possible that encryption will provide a more versatile read sharing mechanism. See GPG Encryption