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.
I'm not arguing blockchain would be a good mitigation for a future incident though.
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.
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
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.
This is not restricted to the blockchain, of course. Something like e.g. SSB fits the bill.
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.
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.
Of course I now feel bad for occasionally hitting it with my frivolous queries, and would be very sad to see it limited.
https://www.mediawiki.org/wiki/Manual:Installation_guide
There have been various forays into Semantic Web technologies. Previously people have done things like parse the infoboxes on Wikipedia pages and then import that into a triple store.
It seems that now the Wikimedia Foundation is finally interested in moving in this direction. But the software isn't there yet, certainly not at the scale Wikipedia needs.
In fact, SQLite is the first database listed on the detailed install instructions page[1]!
[1] https://www.mediawiki.org/wiki/Manual:Installing_MediaWiki#C...
Actually, too many... I need to go and upgrade it.