你可以随时在ipfs.kiwix.org(ipfs.kiwix.org)找到最新的列表，还能通snapshot-hashes.yml(https://github.com/ipfs/distributed-wikipedia-mirror/blob/main/snapshot-hashes.yml “snapshot-hashes.yml”) 文件来获取。
分布式维基百科镜像服务的想法可以追溯到2017年，当时IPFS项目创建了英文和土耳其语的内容快照并存放到IPFS网络上。要了解我们这样做的目的，请阅读最初的IPFS上的维基百科(https://blog.ipfs.io/24-uncensorable-wikipedia/) 一文。
下面是一个简短的状态简报，包括了优化后的使用方法，当前搭建过程及存在的问题，以及未来可以贡献到该项目的工作。
访问维基百科镜像服务的改进方法
用户友好型的ipns://{dnslink}及公共网关
带有IPFS地址支持的浏览器(Brave(https://brave.com/brave-integrates-ipfs/), Opera(https://blog.ipfs.io/2020-03-30-ipfs-in-opera-for-android/), 或常规的Firefox(https://www.mozilla.org/en-US/firefox/new/)和Chromium(https://en.wikipedia.org/wiki/Chromium_(web_browser)) 装上IPFS Companion(https://github.com/ipfs/ipfs-companion#readme)) 就可以使用 DNSLink(https://docs.ipfs.io/concepts/dnslink/)载入最新的快照:
- ipns://{dnslink}
- ipns://en.wikipedia-on-ipfs.org
为了确保真正的点对点传输，离线存储和内容的完整性，你可以运行自己的IPFS节点，方法是(命令行(https://docs.ipfs.io/install/command-line/)或IPFS Desktop桌面端(https://docs.ipfs.io/install/ipfs-desktop/) ) 和IPFS Companion(https://docs.ipfs.io/install/ipfs-companion/)浏览器扩展工具的结合。你也可以使用内置IPFS支持的Brave浏览器(https://brave.com/brave-integrates-ipfs/):
点此观看视频（https://youtu.be/jTDkTQiKzJA）
当你无法运行自己的IPFS节点时多个公共网关(https://ipfs.github.io/public-gateway-checker/)中的一个可以被用作访问镜像服务的代理。例如：
- https://dweb.link/ipns/my.wikipedia-on-ipfs.org
- https://cf-ipfs.com/ipns/my.wikipedia-on-ipfs.org
强健及不可篡改的ipfs://{cid}
如果DNS解析被阻挡，或一个公共网关无法被信任，那么建议使用底层的密码内容标识(CID(https://docs.ipfs.io/concepts/content-addressing/))来访问不可篡改的快照。
- ipfs://{cid}
特定镜像服务的 {cid} 标识可以通过 snapshot-hashes.yml(https://github.com/ipfs/distributed-wikipedia-mirror/blob/main/snapshot-hashes.yml)获取，或使用`ipfs resolve -r /ipns/en.wikipedia-on-ipfs.org`从其DNSLink记录中读取。在本文书写时，英文版镜像指向了 ipfs://bafybeiaysi4s6lnjev27ln5icwm6tueaw2vdykrtjkwiphwekaywqhcjze。
通过sneakernet(https://en.wikipedia.org/wiki/Sneakernet)来分享CID标识是绕过ＤＮＳ问题和审查的流行方式。土耳其人在2017年土耳其屏蔽维基百科(https://en.wikipedia.org/wiki/Block_of_Wikipedia_in_Turkey)时使用了这个方法。历史不会重演，但经验和教训值得学习。今年早期缅甸开始进行互联网中断的实验:
为满足这个重要的需求，我们创建了一个缅甸语版本的维基百科镜像(https://github.com/ipfs/distributed-wikipedia-mirror/pull/83) ，并分享了DNSLink和CID标识号(https://github.com/ipfs/distributed-wikipedia-mirror/pull/83#issuecomment-786021082)：
如何帮助共同存放这些内容？
你可以运行自己的IPFS节点和共同存放维基百科的一个子集，存放完整副本，或追踪协作集群以自动拉入未来更新。
也可以通过将特定CID标识pin到远程服务上来贡献共同存放的成本。
用你自己的IPFS节点进行延迟加载存放服务
其实是可以保留一个延迟加载的副本的。这样就不需要取回整个维基百科了，而是保留浏览过的页面的子集数据。
也可以通过将特定CID标识后的DAG(https://docs.ipfs.io/concepts/glossary/#dag)循环进行pin操作：
循环pin（recursive pin）会在本地数据存储器中预先装载整个镜像。注意，英文版的体积远远大于其他语言版本，因此对其进行pin操作需要几百ＧＢ的空间，可能需要很长的时间。
特定镜像的尺寸可以通过 ipfs files stat /ipfs/{cid} 命令来获取。
协作集群
服务器管理员和高级用户可以使用一个高级的选项。wikipedia集群包括了所有的语言版本，其体积随着时间推移只会不断增加。
若要查看操作指令，可以到collab.ipfscluster.io。
贡献远程pin服务
当共同搭建IPFS节点不可行时，还是可以通过将快照的CID标识pin到远程的pinning服务上。学习如何使用远程pinning服务(https://docs.ipfs.io/how-to/work-with-pinning-services/).
一个镜像服务是如何搭建的？
当前的方法依赖于ZIM格式的维基百科快照(https://download.kiwix.org/zim/wikipedia/) ，这是由Kiwix(https://kiwix.org/) 项目提供的。
目前我们还没有基于Web页面的ZIM归档文件阅读器（下面的章节会细说）。而且，我们搭建镜像服务的方式是一个复杂/耗时的过程。
虽然这是可行的，但由于这依赖于对快照进行解压和定制，因此影响了生成更新的可靠性。而且在Kiwix离线阅读器(https://www.kiwix.org/en/kiwix-reader)上包含原始的ZIM文件也在一定程度上数据变得重复。
我们很乐意建立更多语言的镜像服务和加快更新的节奏，不过这先要脱离对展开（解包）ZIM归档文件这个过程的依赖。
我们将会研究在IPFS上放入来自Kiwix的所有ZIM文件(https://download.kiwix.org/zim/wikipedia/)，并为实现长久储存放入Filecoin(https://filecoin.io/)网络上，这是farm.openzim.org(https://farm.openzim.org )流水线的一部分。
征集帮助，以及现存问题
如果你还在看这篇文章，那么很有可能你对改进分布式维基百科镜像服务的运行方式感兴趣。
以下是可能需要帮助的领域，还有让人展开探索的一些想法。
- 搜索功能。目前暂时没有搜索功能。利用ZIM文件里现有的索引，或搭建一个为网页浏览器优化的基于有向无环图（DAG）的搜索索引可以让现有的镜像服务更为有用。查看这里 [distributed-wikipedia-mirror/issues/76](https://github.com/ipfs/distributed-wikipedia-mirror/issues/76)了解更多。
- 基于Web网页的ZIM文件阅读器。对此项目最大的影响莫过于实现一个基于网页的ZIM归档文件阅读器，让人们在无需解压＼无需安装任何专用软件的情况下就能够浏览原始的ZIM归档文件。想帮助将其变成现实吗？查看这里 [kiwix-js/issues/659](https://github.com/kiwix/kiwix-js/issues/659)
- 改善ZIM文件在IPFS网络上的存放方式。当我们在IPFS网络上存储一个原始的ZIM文件时，相关的DAG（有向无环图）是通过ipfs add –cid-version 1命令生成的。这个方法是可行的，但如果对优化DAG创建过程开展进一步研究，我们或许能够在进行特定字节范围请求时优化重复数据删除过程和提升速度。下面有几个可供探索的不同阶段研究内容。如果对哪个感兴趣了，请在distributed-wikipedia-mirror/issues/42(https://github.com/ipfs/distributed-wikipedia-mirror/issues/42)这里进行评论。
-
第１阶段：投入一点时间去对参数空间进行分析检测，看看有没有很容易就发现的成果。 -
第２阶段：创建一个DAG生成器，它能够理解ZIM格式，并通常将图形资源以dag-pb存在的子DAG形式来代表，从而最大化地进行重复数据删除。 -
第３阶段：研究使用IPLD(https://ipld.io/)增强或取代ZIM文件。应如何在所有的快照和语言之间最大化地提升重复数据删除的性能？一个基于IPLD的搜索索引将会如何工作？
免责声明：平台所发布文章仅代表作者个人观点，与链科天下无关。文章内的信息、意见等均仅供参考，并非作为或被视为实际投资建议。
