I'd be really curious to hear more about how Goal 2 (a full read/write wikipedia) could work.
IIRC, writing to the same IPNS address is (or will be?) possible with a private key, so allowing multiple computers to write to files under an IPNS address would require distributing the private key for that address?
Also, I wonder how abuse could be dealt with. I've got to imagine that graffiti and malicious edits would be much more rampant without a central server to ban IPs. It seems like a much easier (near-term) solution would be a write-only central server that publishes to an (read-only) IPNS address, where the load could be distributed over IPFS users.
You can write to the same IPNS entry with multiple different computers, but i'm not sure that would be the desired way of updating this.
One way i would imagine it could be done is using crdts in combination with some global immutable log (not necessarily a blockchain). Then there needs to be some sort of concept of identity to help avoid spam and trolls, I really like the idea of a web of trust, and that could very likely work here. I'd love to see more widespread applications of CRDTs
I think the real problem with a decentralized read/write Wikipedia is conflict resolution (conflicting edits). Having a centralized site to handle those is extremely useful.
An alternative is to eschew conflict resolution altogether, and have various edits co-exist. That would basically be like the fork model on GitHub. The main issue then is how to help the user choose between competing edits. That's where metrics based on upvotes or the social network topology can help.
That sort of forking model really doesn't work for prose. Making a fork is easy, but merging those changes with other forks to combine improvements rapidly becomes impossible -- especially if anyone tries to perform any sort of large change to an article.
There doesn't need to be a merge. Just pick the most promising version and edit it to create a new version. The old version sticks around. An add-only data structure.
How do you determine "most promising", though? Especially when many edits may not individually look like much (e.g, copyediting, fixing typos, etc), but help improve the overall quality of an aticle.
What this is likely to turn into, in practice, is a forest of dead forks. Division of effort, without a combination of progress.
I presume that "use ethereum" would imply "the viewpoint with the most hashing power wins," which might not align well with how most of us would like to determine truth.
There'd be no voting. By using contracts you could simply lock an article while it is being edited, much like it happens on Wikipedia already.
Ethereum computes all "code" all the time on all nodes and makes sure that all nodes come to the same result. Thus, you can write one Wikipedia that runs in a distributed manner while still acting like one centralised application
I never edit articles on Wikipedia, so I just looked up how it is done there. The editing users are currently merging the changes. The same could be done with Ethereum and a contract. (Although it would be a bit tricky right now because the computational cost of calculating a diff for complex articles would make the operation expensive).
However, there're a couple of outstanding Ethereum Updates that would make this process easier and faster. I'd suppose that in around one year it should be possible to implement this in a fast and cheap way.
Alternatively, one could use 'Whisper', which is Ethereum's 0MQ alternative, and let multiple users work on the same document at the same time (like Google Docs or a multitude of other editors).
Ethereum is still a very young project, but it would allow to implement a truly decentralized Wikipedia.
> I never edit articles on Wikipedia, so I just looked up how it is done there.
I think you've misconstrued how edit conflict resolution works. There is no "locking" involved.
If two editors both open the same revision of a page and save changes, the second editor to submit changes may encounter an edit conflict. In most cases, conflicts are resolved automatically by the wiki engine. If this isn't possible, the second editor is prompted to merge their changes manually, or to reapply their changes.
This is not a locking mechanism. Having an article open for editing does not lock it for future changes; it just records the revision that you started with to help resolve a conflict, should one arise.
What happens where there are merge conflicts, as in git? A fully decentralized app would have to resolve those conflicts on it's own, and there's a very low chance it would do so perfectly every time.
IIRC, writing to the same IPNS address is (or will be?) possible with a private key, so allowing multiple computers to write to files under an IPNS address would require distributing the private key for that address?
Also, I wonder how abuse could be dealt with. I've got to imagine that graffiti and malicious edits would be much more rampant without a central server to ban IPs. It seems like a much easier (near-term) solution would be a write-only central server that publishes to an (read-only) IPNS address, where the load could be distributed over IPFS users.