维基百科-IPFS:在IPFS中托管维基百科的探索

2020-05-10 07:35:34

在IPFS中托管维基百科的探索。该项目包含从维基百科中提取内容的代码,并添加到IPF和建议架构的文档中。这只是一个概念验证,还没有准备好进行任何认真的使用。

IPFS是一种用于构建去中心化网络的协议。维基百科目前托管在其服务器上。为了分散人类所有知识的总和,我们需要在一个分散的网络中托管和维护所有这些知识。这种分布式网络协议有很多候选方案。IPF、DAT就是一些例子。没有一个在普通互联网用户中很受欢迎,但它们或多或少都在积极发展。

几年前,IPFS曾试图托管土耳其语维基百科。它基于维基百科页面的静态快照-基本上是静态的html文件。如果有人更新托管快照,用户将获得该快照。但是维基百科是非常有活力的。每天都有数以千计的编辑发生。每次都会创建新的文章。预先呈现的HTML页面并不是真正方便的知识表示形式,至少它不便于计算。

如果您还不熟悉去中心化网络和IPF的概念,请阅读一些关于它们的背景知识,以便更好地理解本文档。

每个维基百科的内容修改都是分散的网络中的对象。它们是内容可寻址的:这是维基百科世界的基本内容单位。每个修订一旦创建,就是不可变的。你不可能改变它。每个修订都将具有与其相关联的内容和一些元数据,例如创建者和时间。

每一篇维基百科文章在去中心化的网络上都有一个对象,并有指向其修订的指针:维基百科上的一篇文章是可编辑的。最新的修订版代表了这篇文章的现状。但是人们总是可以在任何时候访问它的旧版本。希望具有人类可读的名称以及用于每篇文章的IPFS散列ID。

每个维基百科在分散的网络中都有一个对象,并带有其文章的地址:维基百科是文章的集合(但不限于此)。因此,像英文维基百科这样的维基百科是一种注册表,列出了它的所有文章。(如果你想知道为什么只有一个维基百科的时候我会提到每个维基百科--你可能不知道,但是有将近300种语言的维基百科。例如英语维基百科、西班牙语维基百科、泰米尔维基百科)。

一个可以生活在去中心化网络中的维基百科阅读Web应用程序:要使去中心化网络中的内容可用或可消费,我们需要一个维基百科阅读和可能的编辑界面。这个应用程序呈现了人类构思的内容。

如图所示,wiki是一个以页面作为子目录的目录。但是页面内容不在此目录结构中。苹果目录只有它的元数据、修订版列表和指向最新修订版的指针。在本例中,访问内容ID(Cid)为QmR1CXVerK91PTSDBXLhZLV9Wfs8zafkMHwriUXj14zGES的IPFS对象将提供具有内容的修订对象。

为什么不把每个版本及其内容都放在苹果目录下呢?如上所述,项目是可变的。它可以编辑。可以添加新的修订版本。当发生这样的更改时,其父目录的内容ID(称为散列或CID)也会更改,此更改会导致其所有父目录的CID更改。IPFS需要计算整个目录enwiki的CID。因此,IPFS中的这些数据需要设计为可变文件系统(MFS)。但修订是一成不变的。一旦创建了修订版本,它就会得到一个CID,也就是它。不允许对此进行更多更改。它在分散的网络中成为一个自由浮动的数据包,可以通过它的CID寻址。它仅在注册表跟踪其地址时才相关。未跟踪的修订CID是已删除的修订,它不对应于任何文章。

您可能会感到奇怪,为什么像Apple这样的文章不能有一个独立的可变IPFS对象,并且wiki通过地址来跟踪它,而不是作为wiki目录下的一个文件。这确实是可能的,但我选择了维基百科目录下的标题的想法,以便快速发现和按标题搜索文章。在这种情况下,遍历维基下的文章将涉及CID解析的太多IPF。

最后,我们有了维基百科版本的集合。我们需要跟踪这一点,因为这允许不同语言的交叉链接文章。

有些用户帐户是多维基帐户。我认为它们应该像文章一样被表现出来。它们是可变对象。

如果每次编辑都会更改wiki的CID或散列,我们如何才能永久地引用它呢?IPFS为此提供了一种方式--命名为IPNS(InterPlanetory Naming System)。

星际名称系统(IPNS)是用于创建和更新指向IPFS内容的可变链接的系统。由于IPF中的对象是内容寻址的,因此每次内容更改时,它们的地址都会更改。这对很多事情都很有用,但是很难获得最新版本的内容。IPNS中的名称是公钥的散列。它与包含关于它所链接的散列的信息的记录相关联,该散列由相应的私钥签名。新记录可以随时签署和发布。";

所以每个维基百科,除了它的IPFS/CID地址之外,还会有一个IPNS地址,比如/ipns/QwxosidSOKWms…。如果这是不可读的,DNSLink就派上用场了,我们可以使用/ipns/en.wikipedia.org这样的地址。

拥有私钥并在此基础上生成IPN的要求有助于加强某些真实性-本文确实发布在Wikipedia上,其他任何人都不能使用此IPNS复制、修改和发布IPFS结构。他们确实可以复制、修改和发布,但永远不能拥有维基百科拥有的IPN。

在过去,我(Santhosh)曾试图构建一个可以托管在分布式Web上的静态Web应用程序。为此,我使用了DAT协议,您可以在普通网站wikipedia.thottingal.in和wikipedia.hashbase.io上看到这个应用程序,这是一种钉住服务,或者直接从DAT协议dat://aab37b6f74832891e5b2c593fac748df6379d81c0f2b781f713b0dde229a298d/(这需要beaker浏览器)中看到。

如果您想知道为什么它看起来不像IPFS URL,那是因为此应用程序作为具有历史模式路由的单页应用程序,它需要从域或子域进行寻址。因此,我使用DWEB Projects子域方法来访问它。bafybeibgkplzawivq3w3evxj6uxy2e4uckgy3skyxicll7rxnrpuz6okn4是Base32编码形式的QmQvGMPfub4HwD5BxuPQ95skHENw36wrkJisYMQWkgqdkJ.。或者,这个应用程序可以在桌面或移动设备上运行(它是一个渐进式Web应用程序)。无论如何,在这方面需要做一些工作,但有一个概念的证明。它目前使用的是维基百科rest API,需要重新连接才能从分散的网络上获取内容。

我编写了一个NodeJS应用程序,根据上面概述的内容架构将内容上传到IPFS。每个维基百科都有数千篇文章,每个编辑对应数百万次修订。这个应用程序不是遍历每个wiki和每篇文章,而是侦听编辑事件流-编辑发生时发出的事件。我们还将一小组小型维基列入白名单,以监听此事件。我们的应用程序根本无法处理所有维基中一直发生的数百万次编辑。

要将文件添加到IPFS,我们需要一个IPFS网关,特别是一个可写网关。我使用了go-ipfs并运行了ipfs守护进程:

$ipfs守护进程--可写初始化守护进程.go-ipfs版本:0.4.23-回购版本:7系统版本:amd64/linuxGolang版本:go1.13.7集群侦听/ip4/127.0.0.1/tcp/4001集群监听/ip4/172.17.0.1/tcp/4001集群监听/ip4/192.168.31.222/tcp/4001集群监听/ip6/::1/tcp/4001s。IP4/172.17.0.1/tcp/4001群通告/ip4/192.168.31.222/tcp/4001群通告/ip4/49.37.206.204/tcp/4001群通告/ip6/::1/tcp/4001API服务器侦听/ip4/127.0.0.1/tcp/5001WebUI:http://127.0.0.1:5001/webuiGateway(可写)服务器侦听/ip4/127.0.0.1/tcp/8082守护进程已就绪。

有一个称为JS-IPFS的IPF的javascript实现,您可以使用它编写NodeJS应用程序。但我最初尝试使用它时遇到了很多问题,我决定使用Go-IPFS运行IPFS守护进程,并使用它的web API。在我们的示例中,API侦听的位置是localhost:5001。您可以参考HTTP API文档。但是,有一个js http客户端库抽象了所有这些API调用,并给出了类似的js-ipfs API。我们在这个项目中用到了这一点。

在运行守护进程之后,我们可以运行代码来添加内容。在此之前,使用以下命令安装依赖项

对我们列入白名单的所有维基重复此操作。确保在config.json中正确提供密钥名称。

>;维基百科-ipfs@http://127.0.0.1:5001┌─┬─┐│/home/santhosh/work/exp/ipfs>;节点src/index.js连接到位于索引位置的IPFS服务器│Values│├─┼─┤│Version│';0.4.23';││Commit│;││Repo│';││System│';amd64/linux&39;││Golang│';go1.13.7';在https://stream.wikimedia.org/v2/stream/recentchange-处连接到事件流的页面已打开连接。-已为mlwiki初始化观察器。[修订版]/│└─┴─┘/Revision/3317531:QmTkS28xfdLkJ9nQeUCGLf5GLsm7a9YLLQLk9LBr39ungsPublished]/FreeKnowledge/Revision/3317522:https://gateway.ipfs上的QmbUMDRfrxCVcGFrupFxWiLBce7texEHwAnGgnke14zPFR[Page]/mlwiki/│└─┴─┘/രവിവള്ളത്തോൾ:FreeKnowledge/Revision/3317522。.io/ipns/QmS3kbdWDixvThKjcyprjrwNR5PmBGAaZmGQxgPRqGiKcXPublished mlwiki at https://gateway.ipfs.io/ipfs/QmaFaZM5xqXoUHA4dnQ4u77osZCd5M7fdvqcNvew1Gj4c6Published mlwiki at https://gateway.ipfs.io/ipfs/QmaFaZM5xqXoUHA4dnQ4u77osZCd5M7fdvqcNvew1Gj4c6[Rev]/FreeKnowledge/Revision/3317532:QmbjYwToYdirFtskpePVpqjoRoie7oVTsm3kUqQ7jMHXwv[Rev]/FreeKnowledge/Revision/3317531:QmRtmHBdekZeEw2GLpkHMMRGHj9CrcwSCj8vWg2z6hpAXP[Page]/mlwiki/page/Qma34PBvsqfZzAquegME7QbgEW3tJY7Bsy9vRM6Wwsn8eGPublished:https://gateway.ipfs.io/ipns/QmS3kbdWDixvThKjcyprjrwNR5PmBGAaZmGQxgPRqGiKcXPublished mlwiki at https://gateway.ipfs.io/ipfs/QmPr4Pmv2L43wSGMHP8NRsTPUVcHRknBhasAAaCbLVbo9A-രവിവള്ളത്തോൾInitialized。QmZbcrsSnRqc6rVZtezQyn3g9rWxDjyVDhWMNgGA668VBePublished tawiki at https://gateway.ipfs.io/ipns/QmQiYSbDXcrnLgWFmt3A7ZpejxPSEay9Wn7Y1CAQmjd34QPublished tawiki at https://gateway.ipfs.io/ipfs/QmWib52CZRS7z9BphGQxeY1Mbrq4Ujo5KxkFYo2ZSJ914H atகும்மாயம்。

您可以在浏览器中打开https://gateway.ipfs.io/ipns/QmS3kbdWDixvThKjcyprjrwNR5PmBGAaZmGQxgPRqGiKcX,查看我们刚刚添加的文章内容。

那里的最新文件包含指向文章最新修订版的内容Qmb3xocfwrerXHZ7mo6T6qSHNN4JeWLRy2ZQ5mfQiixKES。您可以使用https://gateway.ipfs.io/ipfs/Qmb3xocfwrerXHZ7mo6T6qSHNN4JeWLRy2ZQ5mfQiixKES打开该CID。

您可以在关于程序输出中观察到更多内容。在我们运行程序时,这篇文章被编辑了2次。文章രവിവള്ളത്തോൾ经过了两次修订,分别为3317531和3317532。你可以看到它是用两个不同的mlwiki CID发布的。

但我们用私钥发布了它,并得到了永久地址:/ipns/QmS3kbdWDixvThKjcyprjrwNR5PmBGAaZmGQxgPRqGiKcX/page/രവിവള്ളത്തോൾ。这将始终指向文章的最新修订版。

正如您可能已经注意到的,我也试验过DAT协议。所有分散的Web协议都处于早期阶段。去年我注意到DAT项目发展很活跃,但现在似乎进展缓慢。烧杯浏览器需要访问dat://协议,并且主流浏览器不支持,这仍然是一个主要问题。IPFS也不例外。IPFS中的原生URL-ipfs://-需要像IPFS Companion这样的浏览器扩展,但至少存在这样的扩展。我必须说,对于使用IPF来说,它是一个非常方便的扩展。钉住或公共网关的可用性是适用于所有协议的另一个问题。只有当有大量的活跃节点时,分散的网络才是廉价和快速的。我认为这个问题会一直持续下去,直到出现一些大的用例,协议成为主流。IPFS的发展非常活跃,但与此同时,它似乎有时也在大方向上迷失了方向。

但是,上面概述的体系结构对于其他协议不应该有太大的不同。内容可寻址数据单元的编码思想保持不变。

维基百科很大。我在内容体系结构中解释的概念只涉及内容的一个子集。有用户,非文章内容。有互动的(基于JS的)内容。有讨论版等等。我们需要一个内容架构来容纳所有这些内容。如果我们能够将Wikipedia的每个rest API输出映射到IPFS中的相应数据源,那么构建阅读应用程序就更接近了。

要解决的问题太多了:内容中有需要重写的链接。需要对图像进行存储和寻址。我不知道如何在IPFS内容中实现强大的搜索。更重要的是,如何编辑这些内容?解决冲突?无论如何,它们并不是不可能的。

维基百科用户分享免费知识的总和。他们协作创建内容并共享。他们也可以共享基础设施吗?如果阅读维基百科页面意味着在一个去中心化的网络中拥有节点内容的副本,我认为运行维基百科会更快、更便宜。

尽管作者是维基媒体基金会的一名工程师,但这并不是官方的维基媒体基金会项目。