Deece
1.0.0
Deece搜索是IPF的开放，协作和分散的搜索机制。运行客户端的任何节点都可以在IPF上爬网，并将其添加到索引中，该索引本身以分散的方式存储在IPF上。这允许在分散内容上分散搜索。
当前的实施仍然是高度实验性的。我们正在开发未来的版本，而无需中央门户，并正在探索替代性搜索机制。我们当前的服务器已关闭，并且该项目尚未维护。
ClientGatewayLibraryDeece搜索允许在IPFS数据上分散搜索。这是由IPFS节点网络实现的，他们参与网络上数据的爬网和索引。该索引存储在IPF上，并分为两层层次结构，第一个是顶级索引（TLI），第二个是关键字特定索引（KSI）。 TLI包含每个关键字的KSI标识符（CID），并且当节点提交爬网时会不断更新。爬网时，节点添加到当前的KSI列表包含该关键字的文件的标识符列表。
Deece搜索允许两个具体的操作： search和crawl 。搜索查询最新的TLI，以在用户查询中找到每个关键字的KSI，然后从这些关键字中获取这些结果，然后从这些关键字中获取这些结果，这些结果将显示给用户。目前，基于CID排序结果的排名，但应开发更复杂的机制。我们允许最多两个关键字的组合结果，这将来会扩展。
当前有三种访问Deece搜索的方法。首先，有使用命令行接口的客户端软件。其次，我们实施了网关服务（www.deece.nl/web/），该服务运行了我们的客户端节点的实例，并允许“ Light客户端”与搜索交互而无需安装其他软件。最后，我们以GO库的形式发布了CLI和Gateway使用的代码。
Deece搜索的初始版本依赖于一个受信任的节点（与我们的网关相同的节点）来更新指向TLI最新版本的IPNS记录。当客户端抓取时，最后一步涉及他们向该服务器发送更新请求。目前，客户将需要在其配置文件中指定一个密码，该密码可以从维护人员那里获得，因为稍后将实施安全措施。
当前，Web用户几乎没有集中搜索引擎的替代方案。这些引擎保持集中控制，政策和信任，这可能导致审查制度，隐私保护和透明度的问题。
此外，这些引擎通常将精力集中在传统的Web内容上（通过DNS访问了Web服务器）。但是，在Web3范式中，预计内容将存储在分散的存储网络（例如IPF）和通过区块链解决方案（例如ENS）进行的名称分辨率，需要替代搜索引擎。
简而言之，需要搜索机制，以搜索分散数据，并以分散的方式进行。
有许多可比的项目，这些项目试图解决Web搜索中的集中化问题。首先，研究了有关当前Web数据的分布式 /分散搜索机制的研究和建议。早期项目包括Yacy，Faroo和寻求者。最近，Presearch旨在使用区块链奖励来创建协作搜索引擎以获得激励措施。
同样，许多作品旨在为P2P存储网络提供分布式搜索。最近，该图已使用加密货币激励措施为区块链数据构建了一个分散的索引协议。
但是，以上项目都没有完全捕获我们的特定用例，以分散搜索分散的Web3数据。
我们的架构依赖于许多客户端节点，这些节点共同维护和添加到索引中，并且能够执行搜索。我们采取了首先完成架构的工作原型的方法，并逐步添加功能。因此，我们当前的版本依靠一个受信任的节点（网关）来更新TLI IPNS记录。由于没有实施添加的安全性或激励性，因此我们使用了一个简单的密码来允许新的客户端节点添加到索引中。尽管将来的安全性可能不足，但我们为早期版本假设一个利他模型。
将来，我们设想有添加的安全性和激励措施，在更新索引时说实话，它们会使节点保持一致。这些可能是加密富国奖励，削减，声誉等的形式。为诚实节点提供资金的一种方法可能是将广告纳入协议中并允许将广告费纳入维护网络的节点。
我们当前的版本仅支持IPF上的PDF文件，以添加到索引中。将来，我们希望将其扩展到更多的文件类型和目录，并支持不同的分散存储网络。最后，我们的目标是将基于区块链的数据（例如智能合约）纳入搜索。
现在，我们概述了我们机制的两个主要操作。
搜索以包含许多搜索词的客户端的查询开始。然后，客户通过解决与相应CID的网关设置的IPN名称来获取最新的TLI。然后将此TLI获取并穿越，以检查关键字是否具有KSI。如果是这种情况，相关的KSI是查询，则返回包含关键字的内容。然后，客户端可以从网络中检索这些文件。
搜索引擎的一个重要方面是排名机制。这通常以集中式的方式发生，而不会受到客户的影响。尽管我们尚未实施复杂的排名机制，但我们设想在结果的客户端将其排名，这使他们具有更大的权力和透明度。这使客户可以控制排名功能，并根据特定需求个性化这些功能。目前，我们的机制根据CID返回结果。当输入两个搜索词时，这两个搜索词都会首先返回，之后返回了仅包含其中一个条款的页面。
任何搜索引擎的一个重要方面是增加索引条目。此过程涉及许多步骤，我们在下面描述。
第一个决定是将哪些内容添加到索引中，我们称之为策划。在传统引擎中，其中包括所有公共网络内容。尽管这实现了高性能，但在分散的网络中执行时可能会增加太多的开销。另一种方法可能是基于重要内容的网络共识进行策划。对于我们当前的系统，我们允许任何认为内容对于将其添加到网络中至关重要的人。内容可以通过CID，DNSLink，ENS或IPNS标识符来解决。
接下来，发生爬行，其中涉及获取和分析文件以提取重要关键字。如上所述，当某人决定添加内容时，我们的系统会爬行，因此手动提交CID被爬行。将来，我们设想在网络上上传或访问内容时会自动发生这种情况。除了提取关键字，还可以添加其他元数据。当前，我们使用文件类型（PDF）和时间戳记时使用时，但将来打算添加标题，计数，大小等。
提取关键字（并产生RWI）后，需要存储索引。对于存储，我们使用IPF，因为这允许分散的协作存储。我们已决定维护两级层次结构。每个关键字将具有关联的索引文件（KSI），节点可以在其中找到包含这些关键字的内容。保留一个单独的索引（TLI），以指向KSI的标识符，并从我们的Gateway Server中发布给IPNS名称。当一个节点在爬行文件后更新KSI时，他们将TLI中的指针更新为这些文件，并请求网关以更新IPNS记录所解决的指针。这样，IPNS的记录指向了TLI的最新版本，进而指出了KSI的最新版本。
目前，如果客户节点拥有密码，则可以更改TLI，可以从该项目的维护者那里获得。这样，潜在的恶意条目就不太可能。用密码的节点可以看作是网络中的“权限”。
在开发和测试中，我们对性能进行了许多观察。由于我们的解决方案在很大程度上依赖IPF，因此我们的性能也是如此。我们发现，当节点没有在他们的同龄人群中添加网关对等时，可能会发生重大延迟。尽管我们将其添加到CLI中，但连接仍然偶尔会下降。尽管这不会破坏系统，但确实会增加延迟。
此外，从网关更新我们的IPNS条目可能非常慢，并且当爬网流量增加时可能会成为性能瓶颈。我们已经开始研究替代方案，但将未来版本的实施留给了。一种选择是使用DNS存储指向最新TLI记录的指针，但这带来了DNS固有的许多其他挑战。尽管频繁更新解析器合同可能会变成巨额费用，但也可以使用基于区块链的名称注册表，例如ENS。
有多种访问Deece搜索的方法：
Client客户端软件可以由运行IPF的任何节点使用，并提供一个简单的命令行接口。
NAME:
Deece - Decentralised search for IPFS
USAGE:
Deece [global options] command [command options] [arguments...]
VERSION:
0.0.1
AUTHORS:
Navin V. Keizer < [email protected] >
Puneet K. Bindlish < [email protected] >
COMMANDS:
search Performs a decentralised search on IPFS
crawl Crawls a page to add to the decentralised index
help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
--help, -h show help (default: false)
--version, -v print the version (default: false)
Gateway为了简化轻巧的访问，我们为搜索客户端实施了网关。可以在以下网址找到：www.deece.nl/web/，并允许基于标识符（CID）在网络上进行搜索和爬网。
注意：升级到版本2时，目前已使用网关。
LibraryCLI和网关都使用我们的Deece搜索软件包运行。我们已经发布了此功能，因为这可以用于简单的集成和扩展。
一旦在不同平台进行测试后，将添加进一步的安装说明。目前，我们根据Linux上的安装提供了说明。
对于Deece搜索工作，有许多要求和依赖关系。要作为客户端运行，需要运行本地的IPFS守护程序，并加快结果加快结果，有助于添加网关维护PEER群中的TLI。要提交TLI作为客户端的更改，需要密码。最后，与加载结果可执行文件相同的目录中需要存在一个配置文件。在此存储库中可以找到一个不完整的配置文件。
要运行客户端，第一个IPFS（测试了版本1.13.7版本，较新版本应适用于次要修改），并且必须安装GIT。
接下来，我们需要从来源安装：
git clone github.com/navinkeizer/Deece接下来需要安装Tesseract-OR，以及其他依赖项。对于Linux，这可能看起来像这样：
sudo apt-get install g++
sudo apt-get install autoconf automake libtool
sudo apt-get install autoconf-archive
sudo apt-get install pkg-config
sudo apt-get install libpng-dev
sudo apt-get install libjpeg8-dev
sudo apt-get install libtiff5-dev
sudo apt-get install zlib1g-dev
wget http://www.leptonica.org/source/leptonica-1.81.1.tar.gz
sudo tar xf leptonica-1.81.1.tar.gz
cd leptonica-1.81.1 &&
sudo ./configure &&
sudo apt install make
sudo make &&
sudo make install
sudo apt-get install tesseract-ocr # or sudo apt install tesseract-ocr
sudo apt install libtesseract-dev然后可以安装其他相关的GO软件包：
$ go get -t github.com/otiai10/gosseract
$ go get github.com/navinkeizer/Deece
$ go get github.com/ipfs/go-ipfs-api
$ go get github.com/wealdtech/go-ens/v3
$ go get github.com/otiai10/gosseract/v2
和CLI建造：
$ sudo go build Deece/CLI/.
并运行：
$ ./CLI [command] [arguments]
该软件包也可以用作库。
go get github.com/navinkeizer/Deece
当前的Deece搜索实施仍是实验性的，因此可能会遇到不稳定性。如本文档中所述，我们做出了简化的假设（利他主义），并专注于有限的功能（仅PDF）。此外，网关提出了一个集中的方面，将来应由分散的网络共识代替，该协议应由激励措施确保。
我们的实施采用了第一个原则方法。我们的目的是从头开始构建，而不是依靠现有的系统组件方法和解决方案。我们认为这是必要的，因为现有的解决方案可能不是分散的Web3内容最佳的。换句话说，有很多工作要做。
目前，由于IPNS的更新计时，我们偶尔会在爬行过程中遇到问题。我们正在通过替代解决方案来解决此问题。
