Thankyou again. I hope you are enjoying this dialog -- I sure appreciate it. :)

That doesn't account for attacks that can be used to steal passwords from other users (think of CSRF, faked login screens etc.), which kinda defeats your next point:

Any functionality considered vulnerable to corruption (which means almost anything other than browsing the site), requires an account and login.

Let me back up a mo...

As far as system integrity and availability is concerned, I was thinking the approach I listed under point 1 in my previous reply (VM etc.) would be sufficient, on its own, for many useful projects.

This is a central issue. Do you think that the following can, at least in theory, work?

No logins; all data in the Parrodocs (and its underlying server) (potentially) public; all data (and code) in the Parrodocs (and its underlying server) open to temporary corruption or worse.

Stealers will eventually pass Parrodocs by because there's nothing worth stealing; no private data, and no worthwhile computation because mallory is more likely to be spotted on (and booted off of) a Parrodocs server than on a more conventional owned server.

(Vandals, otoh, might have a lot of fun.)

When trouble is spotted, a sysop or a bot either fixes the relevant page(s) or restarts the server and rolls all pages forward to the last known good set.

A login provides some value. It isn't about establishing trust and it won't even stop deliberate trouble makers, just as wikipedia's login feature doesn't, but it'll make a useful difference, I think.

if it's more like PHP than a wiki, where is the connection to

? :)