4 ms·

It does work well though. As a user, I can't remember significant Wikipedia or Wikidata outages. And I'm really not sure if whatever blockchain solution that p

It does work well though. As a user, I can't remember significant Wikipedia or Wikidata outages. And I'm really not sure if whatever blockchain solution that person on twitter wants Wikimedia to use is even able to get to that scale, yet alone perform better an it than what Wikimedia currently has.

diegoperini 7y ago
Here in Turkey, we had Wikipedia banned for 4 years. Luckily, the ban has been lifted last month. I'm not arguing blockchain would be a good mitigation for a future incident though.
- JshWright 7y ago
  Was that the fault of Wikipedia's database?
  - samatman 7y ago
    In a limited sense, yes, it was. Because Wikipedia's database is centralized, and lives at a particular (range of) IP addresses, it's trivial for a state actor to censor it. Does a sprinkling of magic blockchain solve this problem? Not really. But something more specific to the problem might; being able to torrent the full data dump is a step in the right direction.
    - JshWright 7y ago
      Users do not connect directly to the database. Turkey definitely didn't blackhole traffic to Wikipedia's database.
      - icebraining 7y ago
        The fact that users can't connect directly to the database is, at least in part, a limitation of the database chosen.
        jonathanpierre 7y ago
        Yes, in a strictly semantic sense, it is a limitation. However, in general such access would be not only a bad idea due to the loss of abstraction and additional work to implement (duplicate) access controls, it would also not be very useful for users over the multiple possibilities for access that already exist. And all this is really a red herring, both in relation to the unspecified use of blockchain and in relation to resistance to state censorship.
        icebraining 7y ago
        No, it's not a red herring. The point is that Wikipedia could use a database that didn't rely on a limited number of access endpoints, which would make it harder to censor. And you don't need duplicate access controls if the database implemented them fully. This is not restricted to the blockchain, of course. Something like e.g. SSB fits the bill.
        jonathanpierre 7y ago
        Since not all information in the database is public, yes, you'd need to duplicate the work. You'd also need to put a lot of work into securing the now open service against attack and denial of service. It would still be just as easy to censor. If a censor goes beyond simple DNS manipulation and drops packages to specific IPs, he can just as easily add the few hundred IPs of database servers to that list as he can add the few hundred IPs of the frontend web servers. Now, your example of SSB shows very well why this is a red herring. Even if Mediawiki put in the huge work to use SSB as a storage backend, nothing would change at all regarding censorship. What you really want is, I assume, a federated version of Wikimedia's architecture. Feel free to develop such a system but I don't think anything but a complete rewrite of Mediawiki would allow for that, and even then, I doubt it would be much more censorship resistant, unless you also take on such features like using TOR hidden services or invite-only networks, which are both perfectly possible right now (and are in fact available right now). And as I said, there is a multitude of options to access the data right now. For example, to build mirrors of Wikipedia for citizens of countries where Wikipedia is blocked. However, it's not necessarily trivial and it doesn't get easier simply by sprinkling some cryptography over the storage layer of all places.
    - dharma1 7y ago
      You can torrent a full snapshot https://wiki.kiwix.org/wiki/Content_in_all_languages https://wiki.kiwix.org/wiki/Content_in_all_languages And also download snapshots from IPFS https://blog.ipfs.io/24-uncensorable-wikipedia/ https://blog.ipfs.io/24-uncensorable-wikipedia/ I guess the issue with snapshots of large datasets is that they go out of date, and downloading the whole data set regularly is a bit painful
      - samatman 7y ago
        Well, yes, that's why I indicated that being able to torrent a fully snapshot is a step in the right direction.

diegoperini 7y ago

Here in Turkey, we had Wikipedia banned for 4 years. Luckily, the ban has been lifted last month. I'm not arguing blockchain would be a good mitigation for a future incident though.

JshWright 7y ago
Was that the fault of Wikipedia's database?
- samatman 7y ago
  In a limited sense, yes, it was. Because Wikipedia's database is centralized, and lives at a particular (range of) IP addresses, it's trivial for a state actor to censor it. Does a sprinkling of magic blockchain solve this problem? Not really. But something more specific to the problem might; being able to torrent the full data dump is a step in the right direction.
  - JshWright 7y ago
    Users do not connect directly to the database. Turkey definitely didn't blackhole traffic to Wikipedia's database.
    - icebraining 7y ago
      The fact that users can't connect directly to the database is, at least in part, a limitation of the database chosen.
      - jonathanpierre 7y ago
        Yes, in a strictly semantic sense, it is a limitation. However, in general such access would be not only a bad idea due to the loss of abstraction and additional work to implement (duplicate) access controls, it would also not be very useful for users over the multiple possibilities for access that already exist. And all this is really a red herring, both in relation to the unspecified use of blockchain and in relation to resistance to state censorship.
        icebraining 7y ago
        No, it's not a red herring. The point is that Wikipedia could use a database that didn't rely on a limited number of access endpoints, which would make it harder to censor. And you don't need duplicate access controls if the database implemented them fully. This is not restricted to the blockchain, of course. Something like e.g. SSB fits the bill.
        jonathanpierre 7y ago
        Since not all information in the database is public, yes, you'd need to duplicate the work. You'd also need to put a lot of work into securing the now open service against attack and denial of service. It would still be just as easy to censor. If a censor goes beyond simple DNS manipulation and drops packages to specific IPs, he can just as easily add the few hundred IPs of database servers to that list as he can add the few hundred IPs of the frontend web servers. Now, your example of SSB shows very well why this is a red herring. Even if Mediawiki put in the huge work to use SSB as a storage backend, nothing would change at all regarding censorship. What you really want is, I assume, a federated version of Wikimedia's architecture. Feel free to develop such a system but I don't think anything but a complete rewrite of Mediawiki would allow for that, and even then, I doubt it would be much more censorship resistant, unless you also take on such features like using TOR hidden services or invite-only networks, which are both perfectly possible right now (and are in fact available right now). And as I said, there is a multitude of options to access the data right now. For example, to build mirrors of Wikipedia for citizens of countries where Wikipedia is blocked. However, it's not necessarily trivial and it doesn't get easier simply by sprinkling some cryptography over the storage layer of all places.
  - dharma1 7y ago
    You can torrent a full snapshot https://wiki.kiwix.org/wiki/Content_in_all_languages https://wiki.kiwix.org/wiki/Content_in_all_languages And also download snapshots from IPFS https://blog.ipfs.io/24-uncensorable-wikipedia/ https://blog.ipfs.io/24-uncensorable-wikipedia/ I guess the issue with snapshots of large datasets is that they go out of date, and downloading the whole data set regularly is a bit painful
    - samatman 7y ago
      Well, yes, that's why I indicated that being able to torrent a fully snapshot is a step in the right direction.