![[Home]](/static/logo.png){kind=logo}
Features that impact who and how can access and edit the pages and how the changes are logged. Also anti-spam measures.
We all don’t like seeing the FrontPage defaced. Yet, we still want to be able to edit it. How can we do this safely, without using AccessControlLists or even StagedCommits?
You can have it so that the FrontPage uses DelayedCommits. When a page uses DelayedCommits, changes don’t apply until a specific number of hours or days have passed since the last edit to the page.
“Staged Commits” means that when you save a change, it doesn’t actually change the page right away. When you hit the “Save” button, the page still looks like it did before you made any changes. You have to wait for someone to authorize your changes, before they actually apply.
See MailedUpdates.
Some WikiEngines will mail you if something interesting happens.
A way to filter the recent changes by user, part of a wiki, or other rules. In other words, search in recent changes, or see recent changes in search results 
Members acquire ratings from other members.
If TrashCan were implemented, then “delete page” would be easy to undo. (Making things easy to undo is generally a good thing – this helps people CommunityWiki:BeBold, and reduces the “are you SURE?” dialogs and other annoyances that tend to grow around things that cannot be un-done).
Everyone can see who’s visiting the site, what pages they are visiting, more or less as it happens (or, within 10-20 seconds, given HTTP).
Use a cryptographic signing system like OpenPGP to sign edited pages.
Treat multiple quick edits by the same user as a single edit.
Instead of making a page completely ReadOnly, it could get a PageFlag which restricts access in that existing content of a page cannot be changed further, but text could still be appended at the bottom of a page.
Hide e-mail addresses (or other addresses like ICQ numbers or Jabber account names) from automated spiders while keeping them accessible to humans at the same time.
A wiki where users don’t even notice when any one machine is unplugged.
“FailSafeWiki – the idea that you might have redundancy between wiki, one goes down, the next comes on-line.”
Wikis that don’t expire old versions. The original wiki implementation didn’t store old versions at all. Wikis based on versioning systems stored all old versions. Some wikis expire older versions, not immediately.
The idea of this feature is to have a “license switch” among a user’s preferences.
The license switch starts in “Default Copyright,” which means that if the user wants to do anything other than “Default Copyright,” the user must consciously flip the switch, thereby saying: “I understand and acknowledge that my posts are by another license.”
The idea is to have an Intermap that the public can edit. That means that the system administrator doesn’t have to edit a static intermap.txt file.
See InterLink for more information about intermaps.
Rollback all edits made after a certain point in time.
Assume your wiki has been hit by a spam-bot. There are over 1000 edits to revert. The rollback feature allows the administrator to revert the entire wiki to whatever state it had at some time X in the past.
A mechanism preventing high server loads and spam/dos attacks by limiting the activity of the users to a pace appropriate for most human beings.
Use bayesian filtering techniques detect unwanted edits to Wiki pages.
A HoneypotFrontPage is a FrontPage that intentionally left open for editing to attract WikiSpam bots, so they can be easily detected and banned. It’s meant to be a spam prevention feature that’s simple and automagical.
The idea is based on these basic but important characteristics about WikiSpam and FrontPages:
Most admins lock their wiki FrontPage to prevent WikiSpam and WikiVandalism. However, by intentionally leaving the FrontPage open for editing to attract WikiSpam bots to spam it, it’s possible to detect WikiSpam as they arrive and then proceed to ban their IPs from editing any other pages for a limited time.
#REDIRECT LinkBan
We want high-quality wiki pages, right ? How in the world do we measure “quality” ?
Each page is assigned a rating by users.
Allow users to form multiple groups for the purpose of rating content on the wiki. Each piece of content may then be associated with multiple ratings.
Reject all edits that add a URI that already exists on some other page of the wiki. Perhaps with a polite comment about “We’re already talking about that on (name of other wiki page)”.
This helps well-intentioned users condense information Wiki:ExactlyOnce. (Unlike many proposed anti-spam features, which annoy well-intentioned users).
Once this is implemented, then IdeasToPlace #179 MassRevert and #177 SpamMop are unnecessary – any user can just delete the Wiki:ExactlyOnce instance of that URI in a few seconds. This also #149 LinkBanning is trivial – any user can put/move that link on a “Banned Links” wiki page that can only be read by logged-in users (and so is invisible to Google). (CategorySecurity)
Many proposed wiki features are in reaction to the problem of spam.
(Click the heading to get a list of all wiki features that mention wiki spam).
Spam has made Usenet News and email practically unusable for some people. There is great hope that wiki technology (perhaps with just a few modifications) will be far more resistant to spam. People also hope that a solution to spam can be found for at least one of wiki, blog, email, news, then later perhaps that solution could be applied to the others.