[Gnu-arch-users] Wiki software using arch as a datastore?

[Robin Green]

I've just been thinking about writing Yet Another Wiki Server
(for a general free software wiki with all sorts of handy hints, lore,
advice, humour, etc.), and the idea struck me of using GNU arch as
a back-end. arch could potentially be of help in many ways, e.g.:

1. Revision control: Keeping only one prior version of each page (as
some wikis do or did) is unsafe because it allows malicious damage.
Why not keep a complete history?

[Please note: Although Ward Cunningham's original Wiki allowed anyone
with a web browser to edit pages, modern wikis can have optional
authentication. Indeed, my wiki will be directly editable by
trusted users only - see below.]

2. Page moves/renames: arch would obviously support revision control
in the presence of moves and renames. Although an ability to say
"this file is the merge of this file and that file" or the reverse,
"these N files are the decomposition of this file", would be a nice
feature to add to arch - for source code tracking as well as for
Wikis.

3. Disconnected editing: get a private copy of perhaps a subset of the
Wiki, and perhaps just the latest version, and be able to work on it
offline and then merge it back in, all using the same web interface
(just on two different machines).

4. Wiki forking: There are several possible models here, many/all of
which arch could support - for example:

  - Fork a private organisational wiki from a public one, e.g. for a
    tech support company that wants to build on my free software wiki,
    merge in outside changes from time to time, and add their own
    tips and hints, but doesn't want to give too much of their
    "advanced knowledge" out too freely.
    (Well, that's their right - if they don't want to give back, they
    don't have to ...)
    
  - A wiki with a stricter/laxer/just-different editorial policy/ethos.
    Depending on the policies or personal animosities involved, if any,
    merges could go in one direction only, or both ways, and could be
    totally moderated or unmoderated or whatever.
    
  - If the owners of a private fork later to decide to merge it back
    into the trunk again, again, arch facilitates that.
    
Of course, all this would usually depend on appropriate copyright
licensing to allow forking to take place. I'm thinking that what I'll
use on my free software wiki is some kind of license that is fairly
liberal but disallows editing people's signed words to misrepresent
their opinions.

5. Fixing the "trusted admin" vulnerability. Users should not have to
trust that the wiki admins - who they may never have met and may have
no reason to trust (or may even have reason to _distrust_) - will not
abuse their privileged position, e.g. by "rewriting history" or
erasing things because they don't like them.

If a user cryptographically signs all commits, then fraudulent changes
to that user's commits could be detected.

Similarly, there should be the option of building a distributed,
redundant wiki, to limit the damage an internal or external attacker
could do. I haven't decided how best to do this.

6. Staging areas for less-trusted newbies. These allow newbies to
make microbranches of a wiki on the same server, and thus allow them
to earn trust and co-operate with direct committers more efficiently.
A similar idea has been implemented by the Open Directory Project
(<http://dmoz.org/>); however, as with my proposed wiki, not everyone
is allowed even to edit in the staging areas.

7. Microbranches for differences of opinion which don't warrant
forking off a whole new server. For example, I might institute a
policy on my wiki of "No promotion of proprietary software on
the main-line wiki", but others who disagreed with that RMS-ism
("Use the best tool for the job, dude!" I can hear them say)
could perhaps promote proprietary software on a branch. (That's
not a promise of what my actual wiki is going to be like, that's
just a hypothetical, motivating example.)


Anyway, those are just some very rough ideas. Basically, (1) and (2)
are my core reasons to think about using arch as the back end, while
the rest are based on asking the question "How might arch be able to
help address my preexisting concerns about trust, control, diversity
vs canonicalness, etc?"

If anyone else is interested in making advanced wikis with
characteristics like these, please get in touch off-list. (If there's
enough interest, we might have to find an existing wiki somewhere
where we can hash it out. Well fancy that!)

-- 
Robin