On Federating Wiki
I reported at the Indie Web Camp that one of my most dramatic mistakes was making wiki a centralized service. While I enjoyed years where creative people would bring their best stuff to me, I knew this wouldn't last. It was unnatural. That is, such concentration is not a pattern that nature uses. I claimed to mimic nature but not in this case.
Life rewards successful scavengers. Where stuff collects, exploitive species evolve.
I've been trying to federate wiki for a decade. FolkMemory was my most complete design, a manifesto really, using the evolution of folktales among storytellers as my inspirational model. When wiki sites proliferated I simplified FolkMemory advocating SisterSites instead. This project seeks a middle ground.
Ants form trails by following pheromones left by others. Similarly visitors will leave enough history that trails will form between federated wikis. We now consider recording and rendering this history.
Every page has an edit history called the journal. Editing changes hands through copying a remote page onto the editor's own wiki. We say, the editor has cloned the remote page, making it his/her own. Further edits occur in place. The original author is welcome to clone the revisions back or continue authoring on their original fork. This is the scenario shown in the following mockup: the history shows his edits to her clone of his orignal work.
One clicks the person-icon to view the page as it appeared on that person's site. That page will have its own journal which will show any edits since the page was cloned.
We have described the clone-on-edit policy. The clone-on-read alternative aggressively retrieves pages making the local wiki behaving like a cacheing proxy.
Although servers are expected to keep history, reliable history cannot be assumed. Likewise, following a link may involve some searching to find the most suitable target page. When servers may, but do not have to make readers aware of clones not included in a page's journal.