Improve censorship-resilient Wikipedia on IPFS (Community Wishlist/W541)

Description

Wikipedia is available on the decentralized InterPlanetary File System (IPFS). It has been valuable during Turkey's censorship of Wikipedia. However, the overall impact and success in enabling people to circumvent censorship of Wikipedia has been limited, especially when it comes to people in China where a billion humans can't really access Wikipedia.

The main entry-point for Wikipedia on IPFS is https://ipfs.kiwix.org/ – more data about the project can be found at Wikipedia on IPFS (Q138220088) such as the GitHub repos.

Please improve Wikipedia on IPFS. This post by Kiwix (project for an offline Wikipedia reader app) lists a few major open problems (incl. #1). This wish is about two things:

Add a search functionality – currently one can read articles just fine on IPFS but there is no search function whereby one can search and find a specific article.
Investigate the main obstacles why Wikipedia on IPFS is not widely used to access the site despite of censorship. For example, even if users theoretically can access the site, if its pages are not included in Web search engine results that most normal Internet users use most of the time – even when knowing a useful Wikipedia probably exists – then it's probably not going to have much of an impact.

IPFS distributed and decentralized, making the system more resilient to attacks and censorship attempts.

Later or other improvements could include making Wikipedia editable on IPFS where it's currently read-only as described at https://blog.ipfs.tech/24-uncensorable-wikipedia/

Regarding point 2 I have asked an LLM – below is its response (may be inaccurate; feel free to improve/replace this with sth better via talk page – see point #2)

Q: "has ipfs been used to circumvent censorship like the great firewall in china and if not or if the impact has been low what are the main obstacles/difficulties with ipfs wikipedia for censorship resilience?"
A:
Short answer: Yes — IPFS has been used in attempts to circumvent censorship (including projects to mirror Wikipedia and shadow libraries), but its real-world impact against heavily resourced national censoring systems like China’s Great Firewall has been limited. Below are the main reasons why.

Why impact is limited

Discoverability: IPFS uses content-addressed hashes (CIDs). Users need the CID or a pinned gateway/name to find content; without usable decentralized naming or widely-shared links, blocked users can’t easily discover material.
Network-level blocking: Censors can and do block IPFS gateways, known bootstrap peers, or IP ranges hosting many public nodes; aggressive IP or DNS blocking and DPI can disrupt IPFS traffic or make gateways unreachable.
Gateway centralization: Most casual users access IPFS via public HTTP gateways (ipfs.io, Cloudflare, etc.). Those gateways are easy targets for blocking or legal pressure; heavy reliance on them reduces censorship resistance.
Availability (pinning): Content persists only while nodes pin it. If mirrors/pinners are removed or not numerous inside a censored region, content can become unavailable to local users even if theoretically addressable.
Traffic fingerprinting and DPI: IPFS traffic can be distinguished and throttled; without careful traffic obfuscation (VPN, DoH, tunneling, pluggable transports) it can be detected and blocked.
Usability and tooling: Non-technical users find IPFS harder to use than web URLs; installing/configuring local nodes, pinning, or resolving IPNS/ENS adds friction that reduces adoption inside censored populations.
Naming and mutability: IPNS/ENS or other name layers add mutability but are slower, more fragile, and can be blocked or censored differently than content CIDs.
Legal/operational risk: Hosts and operators inside a jurisdiction may face legal risk for serving banned content, reducing volunteer pinning inside targeted countries.

[…]Those projects show feasibility but rely on gateway access, external pinning, and distribution to be effective[…]

What would increase IPFS effectiveness against national censorship

More local/in-country pinning and peer presence (ideally many independent peers inside censored areas).
Integration with censor-resistant transport (obfuscated tunnels, mesh networks, DoH/DoT/ODoH, pluggable transports).
Decentralized, censorship-resistant naming accessible without central gateways (improvements to IPNS/alternate name systems with stronger UX).
Robust, distributed public gateways with hard-to-block delivery (CDN-like multi-homing, ephemeral endpoints, domain fronting–style approaches where legal).
Better tooling and UX for non-technical users (easy pin/share workflows).
Incentive and legal frameworks that encourage distributed pinning (e.g., paid pinning, hosting incentives, or community mirrors).

Assigned focus area

Unassigned

Type of wish

Feature request