[samatman]

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.

[dharma1]

You can torrent a full snapshot

https://wiki.kiwix.org/wiki/Content_in_all_languages

And also download snapshots from IPFS

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]

Well, yes, that's why I indicated that being able to torrent a fully snapshot is a step in the right direction.

[JshWright]

Users do not connect directly to the database. Turkey definitely didn't blackhole traffic to Wikipedia's database.

[icebraining]

The fact that users can't connect directly to the database is, at least in part, a limitation of the database chosen.

[jonathanpierre]

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]

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]

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.

[icebraining]

I want nothing. I merely stated a fact, with which for some reason you seem to take issue.

The choice of database, much like the choices of the rest of the architecture, limit it in some ways. That's it. It's not a "red herring". And of course, other choices would have limited in different ways, no doubt.

By the way, the use case I was thinking of was updating pages over sneakernet, which is how information is disseminated in countries where Internet assess is not just censored, but also quite limited. TOR and other tunneling systems are no help at all with this. But like I said, I do not want Wikipedia to be changed. I just want to note that it's a limitation it has.

[zozbot234]

MediaWiki is federated already, due to the interwiki links mechanism. Any large public wiki can have an editable list of shortcuts to other such wikis, and then a link such as [[otherwiki:Some Article]] will work just as well as a local one to [[Some Article]]. This is the exact same federation model as, e.g. email.