FileReplacement

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Often scripts make use of special files, stored on the server, to perform various tasks (see below for some examples). Simply allowing universal read access, a PublicScript, is good for OpenProcess, but it doesn't go far enough. We'd like these to be editable by the community. Allowing universal write access may well raise serious security concerns, or the danger of a MilitaryCoup. One option is the HardSecurity of AccessLevels, but we'd like a SoftSecurity alternative.

Therefore, create a page where the contents of the file are stored. Anyone may edit this page. After a certain timeout period, if no one edits the page in the interim, the contents of the page are accepted and are saved to the file the page represents. But, anyone can veto the change just by editing the page. This will dissuade harmful server-side attacks that would otherwise be trivial if the file was accepted automatically. Here we benefit from all the SoftSecurity built into the rest of the site, such as PeerReview. This follows the same principle of DelayAction as KeptPages, and meatball's PageDeletion system.

This addresses both forces. We need to allow the community to administrate itself instead of putting control in the hands of AbsentLeaders or GodKings. Think of the frustration that the community would have for slow to respond proprietors. We also need to protect the site proprietors and site users from potential liabilities, and the stress of a site proprietor from having to be around to maintain the site at all times.

For UseModWiki folk, see UseMod:WikiPatches/FileReplacement.

But, avoid the VanityFear of always thinking that you necessarily need the extra level of protection given by a delay, especially for a ReversibleChange. SecurityByObscurity may be sufficient.

For content other than plain text, a FileUpload mechanism (possibly with a delay or other checks) is one way forward. Another is to create a java applet (or similar) to allow users to edit the file directly in their web browser.

Applications

On MeatballWiki, the InterMapTxt file is handled that way (see also PublicallyEditableInterMap, InterMapPublic).

A wildly empowering possibility is a CommunityProgrammableWiki - putting the script that runs the site in the hands of the community. Think NomicGame?, think lawmaking.

StableCopy and StableHistory? apply the FileReplacement model to (potentially) every single page.

Implementation

While pondering how to work FileReplacement into the UseMod:MagicContent stuff I'm doing, it struck me that there is a much easier way to do this than having the script write to any old file. Let's take the Intermap as an example. Instead of reading from the intermap.txt file, have a PublicallyEditableInterMap page, and the script reads from the stored wikitext. Now that suggestion was rejected, for the very good reason that should someone vandalise the page, it breaks links across the site until the page is restored. BUT here's where the clever bit comes. The wiki script doesn't read the current version of the PublicallyEditableInterMap. Instead, it uses the following algorithm:

Let t be the delay time
If ( Current time ) - ( Date of newest version ) > t, use newest version
Otherwise, find the version v for which ( Date of version v+1 ) - ( Date of version v ) > t

I'll ponder making a general implementation of this. -- TarQuin

Speeding it up

FileReplacement doesn't work fast enough in my opinion--it has been almost non-functional for the "intermap" file. (Changes to the intermap file using FileReplacement have often taken more than a month to be effective because of multiple edits.) --CliffordAdams

: A problem. Some technical solutions to this:

: Reduce the timeout. Allow the community to alter the timeout (possibly via another file guarded by FileReplacement!). This is useful in applying the StableCopy paradigm to rapidly edited pages (e.g. WikiPedia:current_events).

: Rather than activating replacement when the page has been unaltered for nine days, activate replacement when the current version of the page has been the most recent page for more than 90% of the last ten days. This prevents quickly reverted changes from delaying FileReplacement significantly. (clear, or do I need to give an example?) One danger is that it might encourage EditWars. --MartinHarper

Delaying deployment due to further development is not ideal. Perhaps the page could be split into a development version and a stable subpage. Then you encourage people to edit the development version, and update the stable version only once per replacement period. Updating the stable version shortly before the replacement period comes up, and thereby delaying deployment for another period, would be frowned on. Hence, deployment would only be delayed by people who disagree with the new version, not by people who want to improve it. -- TimStarling

: I think it would be an small improvement if the deployment time would be made visible to the users. A message "this page will become effective if it not edited until ..." could make the process more visible. Requests could be better "serialized". -- HelmutLeitner

Another thing could be positive feedback. A log of unique users or IPs that accessed the page could be kept. Any named user could reduced the time by N hours, any IP by M hours up to a minimum of X days. -- HelmutLeitner

: Visibility is definitely a good thing - agree with Helmut. Having two pages (a la Tim) would be a workaround, but it feels clumsy - the technology is being intrusive, rather than supportive.

Here's another option: by default, every version goes live after ten days. So if I make version 1 on day 1, version 2 on day 2, etc, then on day 11 version 1 is released, on day 12 version 2 is released, and so forth. However, any user may go through the history and mark old versions "not for release" (via some UI change). Thus, vandalism would need to be treated by reverting the page and marking the reverted version not for release. This system preserves "veto semantics" of the existing system. However, in continuous incremental development mode, one can just edit freely without having to worry about the replacement cycle. --MartinHarper

: Another option: apply the StableCopy/veto algorithm to each InterMap prefix individually. So if I add a new site, and nobody removes its entry for t days, then it goes live, no matter how many times the actual page was edited in the meantime; equally, a removed entry that is not reinstated at all over t days will be removed from the actual file. Idiot spammers who replace the entire page can be discarded by only taking into account changes that leave both the #ReplaceFile ... and the <pre>...</pre> in place, and well-intentioned newbies will not accidentally annoy everyone else. -- ChrisPurcell

CategoryWikiTechnology CategoryUncommonWikiTechnology

FileReplacement

Applications

Implementation

Speeding it up

Discussion