Deece
1.0.0
Поиск Deece - это открытый, совместный и децентрализованный механизм поиска для IPFS. Любой узел, работающий с клиентом, способен ползти содержимого на IPFS и добавлять его в индекс, который сам по себе хранится децентрализованным образом на IPFS. Это позволяет выполнять децентрализованный поиск по децентрализованному контенту.
Текущая реализация по -прежнему экспериментальна. Мы работаем над будущими версиями без центральных шлюзов и изучаем альтернативные механизмы поиска. Наш текущий сервер не работает, и проект не поддерживается.
ClientGatewayLibraryПоиск DEECE позволяет выполнять децентрализованный поиск по данным IPFS. Это достигается сетью узлов IPFS, которые участвуют в ползании и индексации данных в сети. Индекс хранится на IPFS и разделен на двухслойную иерархию, первым является индекс верхнего уровня (TLI), а вторым являются ключевые индексы (KSI). TLI содержит идентификаторы (CID) для KSI для каждого ключевого слова и постоянно обновляется, когда узел подчиняется ползунке. При ползании узлы добавляют в текущий KSI список идентификаторов файлов, которые содержат это ключевое слово.
Поиск Deece допускает два конкретных действий: search и crawl . Поиск запросов последним TLI, чтобы найти KSI для каждого ключевого слова в пользовательском запросе, а затем получает результаты из них, которые отображаются пользователю. В настоящее время ранжирование результатов упорядочено на основе CID, но должны быть разработаны более сложные механизмы. Мы допускаем комбинированные результаты до двух ключевых слов, которые будут расширены в будущем.
В настоящее время есть три способа доступа к поиску Deece. Во -первых, есть клиентское программное обеспечение, которое использует интерфейс командной строки. Во -вторых, мы внедрили службу шлюза (www.deece.nl/web/), которая запускает экземпляр нашего клиентского узла и позволяет «легким клиентам» взаимодействовать с поиском без установки другого программного обеспечения. Наконец, мы выпустили наш код, используемый CLI и Gateway в виде библиотеки GO.
Первоначальная версия поиска Deece полагается на надежный узел (тот же узел, что и наш шлюз), чтобы обновить запись IPNS, указывающую на последнюю версию TLI. Когда клиенты ползут, окончательный шаг включает в себя отправку запроса на обновление на этот сервер. На данный момент клиентам необходимо будет указать пароль в своем файле конфигурации, который можно получить от сопровождающих, поскольку меры безопасности будут реализованы позже.
В настоящее время веб -пользователи имеют несколько альтернатив централизованным поисковым системам. Эти двигатели поддерживают централизованный контроль, политику и доверие, что может привести к вопросам цензуры, защиты конфиденциальности и прозрачности.
Кроме того, эти двигатели, как правило, фокусируют свои усилия на традиционном веб -контенте (размещенном на веб -серверах, доступны через DNS). Тем не менее, в парадигме Web3, где ожидается, что контент будет храниться в децентрализованных сетях хранения (например, IPFS) и разрешения имени, чтобы проходить через Blockchain Solutions (например, ENS), требуется альтернативная поисковая система.
Короче говоря, необходим механизм поиска, который ищет децентрализованные данные и делает это децентрализованным образом.
Существует ряд сопоставимых проектов, которые пытались решить проблему централизации в поиске в Интернете. Прежде всего, существуют реализации и предложения из исследований для распределенных / децентрализованных механизмов поиска для текущих веб -данных. Ранние проекты включают Yacy, Faroo и ищет. Совсем недавно Presearch стремится создать совместную поисковую систему с использованием вознаграждений Blockchain для стимулов.
Аналогичным образом, ряд работ, направленных на предоставление распределенного поиска сетей хранения P2P. Совсем недавно график создал децентрализованный протокол индексации для данных блокчейна с использованием стимулов криптовалюты.
Тем не менее, ни один из вышеперечисленных проектов полностью не отражает наш конкретный случай использования децентрализованного поиска децентрализованных данных Web3.
Наша архитектура зависит от ряда узлов клиента, которые в совокупности поддерживают и добавляют в индекс и способны выполнять поиск. Мы сначала приняли подход к завершению рабочей профиля нашей архитектуры и постепенно добавили функции. Поэтому наша текущая версия полагается на доверенный узел (шлюз), чтобы обновить запись IPNS TLI. Поскольку не реализована дополнительная безопасность или стимулирование, мы использовали простой пароль, чтобы позволить новым клиентским узлам добавлять в индекс. Хотя безопасности может быть недостаточной в будущем, мы предполагаем альтруистическую модель для нашего выпуска ранней стадии.
В будущем мы предполагаем, что там будет добавлено безопасность и стимулы, которые выравнивают узлы, чтобы быть честными при обновлении индекса. Это может быть в форме вознаграждений за криптокурению, сокращений, репутации и т. Д. Один из способов финансирования вознаграждений на честные узлы может заключаться в том, чтобы включить рекламу в протокол и позволить делегировать рекламные сборы в узлы, поддерживающие сеть.
Наша текущая версия поддерживает только PDF -файлы на IPFS для добавления в индекс. В будущем мы хотели бы расширить это до большего количества типов файлов и каталогов, а также поддерживать различные децентрализованные сети хранения. Наконец, мы стремимся включить данные на основе блокчейна, такие как интеллектуальные контракты в поиск.
Теперь мы представляем обзор двух основных операций в нашем механизме.
Поиск начинается с запроса клиента, содержащего несколько терминов поиска. Затем клиент получает последнюю TLI, разрешив имя IPNS, установленное шлюзом в соответствующий CID. Этот TLI затем получает и пересекается, чтобы проверить, имеют ли ключевые слова KSI. Если это так, соответствующие KSI являются запросами, чтобы вернуть контент, который содержит ключевые слова. Затем клиент может извлечь эти файлы из сети.
Одним из важных аспектов в поисковых системах является механизм ранжирования. Обычно это происходит централизованным образом, без особого влияния со стороны клиентов. Несмотря на то, что мы не внедрили сложные механизмы ранжирования, мы предполагаем, что есть рейтинг у клиентов результатов, что дает им большую мощность и прозрачность. Это позволяет клиентам контролировать функции ранжирования и персонализировать их на основе конкретных потребностей. В настоящее время наш механизм возвращает упорядоченные результаты на основе CID. Когда вводится два поисковых термина, сначала возвращаются страницы, в которых возвращаются страницы, которые содержат только один из терминов.
Важным аспектом любой поисковой системы является добавление записей к индексу. Этот процесс включает в себя ряд шагов, которые мы описываем ниже.
Первое решение, которое будет принято, - это то, что контент будет добавлен в индекс, который мы называем курацией . В традиционных двигателях это включает в себя весь общедоступный веб -контент. Хотя это достигает высокой производительности, это может добавить слишком много накладных расходов при выполнении в децентрализованной сети. Другим подходом может быть курирование, основанное на консенсусе сети важного контента. Для нашей текущей системы мы позволяем любому, кто считает контентом, важен добавить это в сеть. Контент может быть устранен с помощью идентификаторов CID, DNSLINK, ENS или IPN.
Затем происходит ползание, которое включает в себя извлечение и анализ файлов для извлечения важных ключевых слов. Как упоминалось выше, наша система ползает, когда кто -то решает, что контент должен быть добавлен, и, таким образом, вручную подчиняется CID для ползания. В будущем мы предполагаем, что это произойдет автоматически, когда контент загружается или посещается в сети. Помимо извлечения ключевых слов, могут быть добавлены другие метаданные. В настоящее время мы используем тип файла (PDF) и TimeStamp при ползании, но в будущем намерение добавить заголовок, подсчет, размер и т. Д.
После извлечения ключевых слов (и производства RWI) индекс должен храниться. Для хранения мы используем IPFS, так как это позволяет иметь децентрализованное совместное хранилище. Мы решили сохранить двухуровневую иерархию. Каждое ключевое слово будет иметь связанный индексный файл (KSI), где узлы могут найти, какое содержание содержит эти ключевые слова. Отдельный индекс сохраняется (TLI), чтобы указывать на идентификаторы KSI, и это публикуется на имя IPN с нашего сервера шлюза. Когда узел обновляет KSI после ползания файла, они обновляют указатель в TLI в эти файлы и просит шлюз обновить указатель, к которому разрешается запись IPNS. Таким образом, запись IPNS указывает на последнюю версию TLI, которая, в свою очередь, указывает на последние версии KSI.
В настоящее время клиентские узлы могут изменить TLI, если они обладают паролем, который может быть получен от сопровождающих этого проекта. Таким образом, потенциальные вредоносные записи менее вероятны. Узлы с паролями можно рассматривать как «власти» в сети.
Во время разработки и тестирования мы сделали ряд наблюдений в отношении производительности. Поскольку наше решение в значительной степени зависит от IPFS, наша производительность. Мы обнаружили, что значительные задержки могут возникнуть, когда узлы не добавили сверстников ворот в их рой сверстников. В то время как мы добавили это в наш CLI, соединение по -прежнему падает время от времени. Хотя это не сломает систему, это добавляет задержки.
Кроме того, обновление нашей записи IPNS от шлюза может быть очень медленным и может стать узким местом производительности, когда трафик увеличивается. Мы начали изучать альтернативы, но оставляем реализацию в будущие выпуски. Одним из вариантов является использование DNS для хранения указателя на последнюю запись TLI, но это вызывает ряд дополнительных проблем, присущих DNS. Реестр имен, основанный на блокчейне, такой как ENS, также может использоваться, хотя частые обновления контракта с разрешением могут стать большими расходами.
Есть несколько способов получить доступ к поиску Deece:
ClientКлиентское программное обеспечение может использоваться любым узлом, работающим на IPFS, и предоставляет простой интерфейс командной строки.
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.
LibraryИ CLI, и шлюз работают, используя наш поисковый пакет Deece для Go. Мы выпустили это, так как это можно использовать для легких интеграций и расширений.
Дальнейшие инструкции по установке будут добавлены после тестирования на разных платформах. На данный момент мы предоставили инструкции на основе нашей установки на Linux.
Для поиска Deece для работы есть ряд требований и зависимостей. Чтобы работать как клиент, локальный демон IPFS должен работать, и чтобы ускорить результаты, он помогает добавить шлюз, поддерживая TLI в сверстником рое. Чтобы отправить изменения в TLI в качестве клиента, требуется пароль. Наконец, файл конфигурации должен присутствовать в том же каталоге, что и исполняемый файл для загрузки результатов. Неполный файл конфигурации можно найти в этом репозитории.
Чтобы запустить клиента, первое IPFS, GO (проверка на версию 1.13.7, новые версии должны работать с незначительными модификациями), и GIT должен быть установлен.
Далее нам нужно установить из источника:
git clone github.com/navinkeizer/DeeceСледующий Tesseract-OCR должен быть установлен, а также другие зависимости. Для 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. Мы работаем над разрешением этого с помощью альтернативных решений.
