5 ms·

I think the real problem with a decentralized read/write Wikipedia is conflict resolution (conflicting edits). Having a centralized site to handle those is extr

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.

heliumcraft 10y ago
Those can be handled in a decentralized consensus system such as Ethereum.
- nathcd 10y ago
  "Just Add a Blockchain." The universal solution.
- Dylan16807 10y ago
  That's a voting mechanism. How do nodes decide which version to vote for?
  - terhechte 10y ago
    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
    - cjbprime 10y ago
      That doesn't scale. Any popular article would just be locked all the time. (How long does my "intention to edit" lock it for?)
      - terhechte 10y ago
        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://en.wikipedia.org/wiki/Help:Edit_conflict https://github.com/ethereum/wiki/wiki/Whisper https://github.com/ethereum/wiki/wiki/Whisper
        duskwuff 10y ago
        > 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.
        lgierth 10y ago
        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-261670830 https://github.com/ipfs/go-ipfs/issues/3397#issuecomment-261... [2] https://github.com/orbitdb/orbit https://github.com/orbitdb/orbit
    - maxfurman 10y ago
      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.
    - ska 10y ago
      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.
  - dantillberg 10y ago
    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.
    - dignati 10y ago
      Ironically that might be China, at least it would be with Bitcoin.
esfandia 10y ago
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. We have some prior work on building a peer-to-peer wiki and dealing with the issues above: http://onlinelibrary.wiley.com/doi/10.1002/cpe.3420/abstract http://onlinelibrary.wiley.com/doi/10.1002/cpe.3420/abstract
- duskwuff 10y ago
  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.
  - esfandia 10y ago
    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.
    - duskwuff 10y ago
      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 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.

heliumcraft 10y ago

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

nathcd 10y ago
"Just Add a Blockchain." The universal solution.
Dylan16807 10y ago
That's a voting mechanism. How do nodes decide which version to vote for?
- terhechte 10y ago
  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
  - cjbprime 10y ago
    That doesn't scale. Any popular article would just be locked all the time. (How long does my "intention to edit" lock it for?)
    - terhechte 10y ago
      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://en.wikipedia.org/wiki/Help:Edit_conflict https://github.com/ethereum/wiki/wiki/Whisper https://github.com/ethereum/wiki/wiki/Whisper
      - duskwuff 10y ago
        > 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.
      - lgierth 10y ago
        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-261670830 https://github.com/ipfs/go-ipfs/issues/3397#issuecomment-261... [2] https://github.com/orbitdb/orbit https://github.com/orbitdb/orbit
  - maxfurman 10y ago
    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.
  - ska 10y ago
    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.
- dantillberg 10y ago
  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.
  - dignati 10y ago
    Ironically that might be China, at least it would be with Bitcoin.

esfandia 10y ago

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. We have some prior work on building a peer-to-peer wiki and dealing with the issues above: http://onlinelibrary.wiley.com/doi/10.1002/cpe.3420/abstract http://onlinelibrary.wiley.com/doi/10.1002/cpe.3420/abstract

duskwuff 10y ago
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.
- esfandia 10y ago
  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.
  - duskwuff 10y ago
    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.