There's a better way to implement this. Much better, and already mostly done. My previous remarks about db load and such are wrong. There's a device called the "editor's history" that shows the history of changes by editors. I think we should make all edits show up on that history, and make it visible to all.

Cons: more db use, there's no way for editors to hide things without additional effort/code. Non-cons: no additional overhead per view. Very little new code to write. Editors can't hide things without additional effort/code (yes, that is both). (The pros are obvious. The non-cons above are more of non-issues -- things which may appear to be pros or cons, but are in fact no different from the current state.)

As to taking up more db space, the current implementation of this featuere is hugely innefficent. Each edit stores the complete pre/post state. The poststate is redundant -- it is the same as the prestate of the next edit, or in the case of the last edit, the current node (which has sepperate storage). Additionaly, for most edits, most of the content is unchanged. Storing a diff instead of the prestate would alleviate this, and diff -u is easy enough to process (if edits should be reversed), or simply read.

(There is a similar innefficency in the patch system, bu it isn't as bad, and is a less important system.)