Here we look at issues to do with Authentication and Security in Federated Wiki. Fedwiki currently has a pull-only, one domain-one author philosophy which cuts down on spam.
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.
GPG can encrypt pages to be decrypted by any one of multiple recipients:
We consider how a transporter could provide services to site owners within one farm but not others. We assume an administrator with privileged access to both transporter and farm and suitable protection from man-in-the-middle attacks at all levels.
Here we think through how one could host a wiki farm for themselves and friends without opening hosting for the world. riot 
# Pull-only
Fedwiki strives not to push content to other authors sites. An author must explicitly find then fork content to be notified of what is happening in the federation, or to change content on their site.
These two aspects should best be considered separately: - Don't notify me - Don't touch my content
The combination of both these principles (with subtle and minor modifications), results in a security model which does not have to contend with the unwanted attention of spammers, or those that the author does not wish to be informed about.
Suggestions
This is work in progress, but a suggestion here is to use Capability URLs, and also separate authoring from viewing interfaces somewhat.
Given you know the url you have access to the ability to write to that domain. If you are concerned that other people may have a copy of the url, or you just want to renew / refresh your "password" - you can revoke the old url, and get issued with a new one.
These url's are impossible to guess, and are not crawled. It should be possible to set up a domain that generates and manages these Capability URL's and enables Fedwiki users to use them to gain the ability to author their sites in a way that does not have the problems abaove.