Hacker News Reader

Comment by heliumcraft | Hacker News Reader

Those can be handled in a decentralized consensus system such as Ethereum.

That's a voting mechanism. How do nodes decide which version to vote for?

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

That doesn't scale. Any popular article would just be locked all the time. (How long does my "intention to edit" lock it for?)

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.

https://en.wikipedia.org/wiki/Help:Edit_conflict https://github.com/ethereum/wiki/wiki/Whisper

> 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.

You can also find an experimental PubSub system in IPFS [1]. One example use is peer-to-peer chat, Orbit [2].

[1] https://github.com/ipfs/go-ipfs/issues/3397#issuecomment-261... [2] https://github.com/orbitdb/orbit

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.

This doesn't scale in exactly the same way that file lock based revision control systems didn't. There is a good reason they are unusual these days.

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.

Ironically that might be China, at least it would be with Bitcoin.

"Just Add a Blockchain." The universal solution.

Reply on news.ycombinator.com