Deece
1.0.0
Pencarian Deece adalah mekanisme pencarian yang terbuka, kolaboratif, dan terdesentralisasi untuk IPF. Node apa pun yang menjalankan klien dapat merangkak konten pada IPF dan menambahkan ini ke indeks, yang dengan sendirinya disimpan dengan cara yang terdesentralisasi pada IPF. Ini memungkinkan pencarian terdesentralisasi pada konten yang terdesentralisasi.
Implementasi saat ini masih sangat eksperimental. Kami sedang mengerjakan versi masa depan tanpa gateway pusat dan sedang mengeksplorasi mekanisme pencarian alternatif. Server kami saat ini sedang down, dan proyek belum dipertahankan.
ClientGatewayLibraryPencarian Deece memungkinkan pencarian terdesentralisasi pada data IPFS. Ini dicapai oleh jaringan node IPFS yang berpartisipasi dalam merangkak dan pengindeksan data pada jaringan. Indeks disimpan pada IPFS, dan dibagi menjadi hierarki dua lapis, yang pertama adalah indeks tingkat atas (TLI) dan yang kedua adalah indeks spesifik kata kunci (KSI). TLI berisi pengidentifikasi (CID) untuk KSI untuk setiap kata kunci, dan terus diperbarui ketika sebuah simpul mengirimkan crawl. Saat merangkak, node menambahkan KSI saat ini daftar pengidentifikasi file yang berisi kata kunci itu.
Pencarian Deece memungkinkan dua tindakan spesifik: search dan crawl . Cari kueri TLI terbaru untuk menemukan KSI untuk setiap kata kunci dalam kueri pengguna, dan kemudian mengambil hasil dari ini, yang ditampilkan kepada pengguna. Saat ini peringkat hasil diperintahkan berdasarkan CID, tetapi mekanisme yang lebih canggih harus dikembangkan. Kami memungkinkan hasil gabungan hingga dua kata kunci, yang akan diperpanjang di masa depan.
Saat ini ada tiga cara untuk mengakses pencarian deece. Pertama, ada perangkat lunak klien yang menggunakan antarmuka baris perintah. Kedua, kami telah menerapkan layanan gateway (www.deece.nl/web/), yang menjalankan instance dari node klien kami dan memungkinkan "klien ringan" untuk berinteraksi dengan pencarian tanpa menginstal perangkat lunak lain. Akhirnya, kami telah merilis kode kami yang digunakan oleh CLI dan gateway dalam bentuk perpustakaan go.
Versi awal pencarian Deece bergantung pada simpul tepercaya (simpul yang sama dengan gateway kami) untuk memperbarui catatan IPN yang menunjuk ke versi terbaru dari TLI. Saat klien merangkak, langkah terakhir melibatkan mereka mengirim permintaan pembaruan ke server ini. Saat ini, klien perlu menentukan kata sandi dalam file konfigurasi mereka, yang dapat diperoleh dari pengelola, karena langkah -langkah keamanan akan diimplementasikan nanti.
Saat ini, pengguna web memiliki beberapa alternatif untuk mesin pencari terpusat . Mesin -mesin ini mempertahankan kontrol, kebijakan, dan kepercayaan terpusat, yang dapat menyebabkan masalah dalam penyensoran, perlindungan privasi, dan transparansi.
Selain itu, mesin ini umumnya memfokuskan upaya mereka pada konten web tradisional (di -host di server web, diakses melalui DNS). Namun, dalam paradigma Web3, di mana konten diharapkan disimpan di jaringan penyimpanan terdesentralisasi (misalnya IPF) dan resolusi nama dilakukan melalui solusi blockchain (misalnya ENS), diperlukan mesin pencari alternatif.
Singkatnya, mekanisme pencarian diperlukan yang mencari data terdesentralisasi, dan melakukannya dengan cara yang terdesentralisasi.
Ada sejumlah proyek yang sebanding, yang telah berusaha menyelesaikan masalah sentralisasi dalam pencarian web. Pertama -tama, ada implementasi dan proposal dari penelitian untuk mekanisme pencarian terdistribusi / terdesentralisasi untuk data web saat ini. Proyek awal termasuk Yacy, Faroo, dan mencari. Baru -baru ini, Presearch bertujuan untuk membuat mesin pencari kolaboratif menggunakan penghargaan blockchain untuk insentif.
Demikian pula, sejumlah karya yang bertujuan untuk menyediakan pencarian terdistribusi untuk jaringan penyimpanan P2P. Baru -baru ini, grafik telah membangun protokol pengindeksan terdesentralisasi untuk data blockchain menggunakan insentif cryptocurrency.
Namun, tidak ada proyek di atas yang sepenuhnya menangkap kasus penggunaan spesifik kami dari pencarian terdesentralisasi untuk data Web3 yang terdesentralisasi.
Arsitektur kami bergantung pada sejumlah node klien, yang secara kolektif memelihara dan menambah indeks, dan dapat melakukan pencarian. Kami telah mengambil pendekatan menyelesaikan protype yang berfungsi dari arsitektur kami terlebih dahulu, dan menambahkan fitur secara bertahap. Oleh karena itu, versi kami saat ini bergantung pada simpul tepercaya (gateway) untuk memperbarui catatan IPN TLI. Karena tidak ada keamanan tambahan atau insentivisasi yang diterapkan, kami telah menggunakan kata sandi sederhana untuk memungkinkan node klien baru ditambahkan ke indeks. Sementara keamanan mungkin tidak mencukupi di masa depan, kami mengasumsikan model altruistik untuk rilis tahap awal kami.
Di masa depan kami membayangkan di sana untuk ditambahkan keamanan dan insentif di tempat, yang menyelaraskan node jujur saat memperbarui indeks. Ini mungkin dalam bentuk imbalan cryptocurreny, pemotongan, reputasi, dll. Salah satu cara untuk mendanai hadiah ke node yang jujur adalah dengan memasukkan iklan ke dalam protokol dan memungkinkan biaya iklan didelegasikan ke node yang mempertahankan jaringan.
Versi kami saat ini hanya mendukung file PDF pada IPF yang akan ditambahkan ke indeks. Di masa depan, kami ingin memperluas ini ke lebih banyak jenis file dan direktori, dan mendukung berbagai jaringan penyimpanan yang terdesentralisasi. Akhirnya, kami bertujuan untuk memasukkan data berbasis blockchain seperti kontrak pintar ke dalam pencarian.
Kami sekarang menyajikan gambaran dua operasi utama dalam mekanisme kami.
Pencarian dimulai dengan kueri oleh klien yang berisi sejumlah istilah pencarian. Klien kemudian mengambil TLI terbaru dengan menyelesaikan nama IPNS yang ditetapkan oleh gerbang ke CID yang sesuai. TLI ini kemudian diambil dan dilalui untuk memeriksa apakah kata kunci memiliki KSI. Jika ini masalahnya, KSI yang relevan adalah pertanyaan, untuk mengembalikan konten yang berisi kata kunci. Klien kemudian dapat mengambil file -file ini dari jaringan.
Salah satu aspek penting dalam mesin pencari adalah mekanisme peringkat. Ini umumnya terjadi secara terpusat, tanpa banyak pengaruh dari klien. Meskipun kami belum menerapkan mekanisme peringkat yang canggih, kami membayangkan ada peringkat pada klien hasil, yang memberi mereka kekuatan dan transparansi yang lebih besar. Ini memungkinkan klien untuk mengendalikan fungsi peringkat dan untuk mempersonalisasikannya berdasarkan kebutuhan spesifik. Saat ini, pengembalian mekanisme kami memesan hasil berdasarkan CID. Ketika dua istilah pencarian dimasukkan, halaman -halaman di mana kedua terjadi keduanya dikembalikan terlebih dahulu, setelah itu halaman dikembalikan yang hanya berisi satu istilah.
Aspek penting dari setiap mesin pencari adalah penambahan entri ke indeks. Proses ini melibatkan sejumlah langkah, yang kami jelaskan di bawah ini.
Keputusan pertama yang akan dibuat adalah konten apa yang akan ditambahkan ke indeks, yang kami sebut kurasi . Dalam mesin tradisional ini mencakup semua konten web publik. Meskipun ini mencapai kinerja tinggi, ini dapat menambah terlalu banyak overhead saat dieksekusi dalam jaringan yang terdesentralisasi. Pendekatan lain mungkin kurasi berdasarkan konsensus jaringan konten penting. Untuk sistem kami saat ini, kami mengizinkan siapa saja yang percaya konten menjadi penting untuk menambahkan ini ke jaringan. Konten dapat diatasi oleh CID, DNSLink, ENS, atau IPNs Identifiers.
Selanjutnya, merangkak terjadi, yang melibatkan mengambil dan menganalisis file untuk mengekstrak kata kunci penting. Seperti disebutkan di atas, sistem kami merangkak ketika seseorang memutuskan konten harus ditambahkan, dan dengan demikian secara manual mengirimkan CID untuk dirangkak. Di masa depan, kami membayangkan ini terjadi secara otomatis ketika konten diunggah atau dikunjungi di jaringan. Selain mengekstraksi kata kunci, metadata lain dapat ditambahkan. Kami saat ini menggunakan jenis file (PDF) dan cap waktu saat merangkak, tetapi di masa depan niat untuk menambahkan judul, hitungan, ukuran, dll.
Setelah mengekstraksi kata kunci (dan memproduksi RWI), indeks perlu disimpan. Untuk penyimpanan kami menggunakan IPF, karena ini memungkinkan penyimpanan kolaboratif yang terdesentralisasi. Kami telah memutuskan untuk mempertahankan hierarki dua tingkat. Setiap kata kunci akan memiliki file indeks terkait (KSI) di mana node dapat menemukan konten mana yang berisi kata kunci tersebut. Indeks terpisah disimpan (TLI) untuk menunjuk ke pengidentifikasi KSI, dan ini diterbitkan ke nama IPNS dari server gateway kami. Ketika sebuah simpul memperbarui KSI setelah merangkak file, mereka memperbarui pointer di TLI ke file -file ini, dan meminta gateway untuk memperbarui pointer yang diselesaikan oleh catatan IPNS. Dengan cara ini, rekaman IPNs menunjuk ke versi terbaru dari TLI, yang pada gilirannya menunjuk ke versi terbaru dari KSI.
Saat ini, node klien dapat mengubah TLI jika mereka memiliki kata sandi, yang dapat diperoleh dari pengelola proyek ini. Dengan cara ini, entri berbahaya yang potensial lebih kecil kemungkinannya. Node dengan kata sandi dapat dilihat sebagai 'otoritas' di jaringan.
Selama pengembangan dan pengujian kami telah melakukan sejumlah pengamatan sehubungan dengan kinerja. Karena solusi kami sangat bergantung pada IPF, begitu pula kinerja kami. Kami menemukan bahwa penundaan yang signifikan dapat terjadi ketika node belum menambahkan rekan gateway di segerombolan rekan mereka. Sementara kami telah menambahkan ini ke CLI kami, koneksi masih turun sesekali. Meskipun ini tidak merusak sistem, itu menambah penundaan.
Selain itu, memperbarui entri IPN kami dari gateway bisa sangat lambat, dan dapat menjadi hambatan kinerja ketika lalu lintas merangkak meningkat. Kami telah mulai mencari alternatif, tetapi meninggalkan implementasi untuk rilis di masa mendatang. Salah satu opsi adalah menggunakan DNS untuk menyimpan pointer ke catatan TLI terbaru, tetapi ini membawa sejumlah tantangan tambahan yang melekat pada DNS. Registri nama berbasis blockchain seperti ENS juga dapat digunakan, meskipun seringnya pembaruan untuk kontrak resolver dapat menjadi biaya besar.
Ada sejumlah cara untuk mengakses pencarian deece:
ClientPerangkat lunak klien dapat digunakan oleh node apa pun yang menjalankan IPF, dan menyediakan antarmuka baris perintah sederhana.
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)
GatewayUntuk akses yang mudah dan ringan, kami telah menerapkan gateway untuk klien pencarian kami. Ini dapat ditemukan di: www.deece.nl/web/, dan memungkinkan pencarian dan perayapan di jaringan berdasarkan pengidentifikasi (CID).
CATATAN: Gateway saat ini dijual saat meningkatkan ke versi 2.
LibraryBaik CLI dan Gateway menggunakan Paket Pencarian Deece kami untuk GO. Kami telah merilis ini, karena ini dapat digunakan untuk integrasi dan ekstensi yang mudah.
Instruksi instalasi lebih lanjut akan ditambahkan setelah diuji di berbagai platform. Untuk saat ini kami telah memberikan instruksi berdasarkan instalasi kami di Linux.
Agar pencarian deece berfungsi ada sejumlah persyaratan dan dependensi. Untuk berjalan sebagai klien, daemon IPFS lokal perlu dijalankan, dan untuk mempercepat hasil, ini membantu untuk menambahkan gateway mempertahankan TLI di segerombolan rekan. Untuk mengirimkan perubahan pada TLI sebagai klien, diperlukan kata sandi. Akhirnya, file konfigurasi harus ada di direktori yang sama dengan yang dapat dieksekusi untuk memuat hasil. File konfigurasi yang tidak lengkap dapat ditemukan di repositori ini.
Untuk menjalankan klien, IPF pertama, GO (diuji untuk versi 1.13.7, versi yang lebih baru harus bekerja dengan modifikasi kecil), dan git harus diinstal.
Selanjutnya kita perlu menginstal dari sumber:
git clone github.com/navinkeizer/DeeceTesseract-ORCR berikutnya perlu diinstal, serta ketergantungan lainnya. Untuk Linux ini mungkin terlihat seperti ini:
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-devPaket GO lainnya yang relevan kemudian dapat diinstal:
$ 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
dan CLI dibangun:
$ sudo go build Deece/CLI/.
dan jalankan:
$ ./CLI [command] [arguments]
Paket ini juga dapat digunakan sebagai perpustakaan.
go get github.com/navinkeizer/Deece
Implementasi pencarian deece saat ini masih eksperimental, dan karenanya mungkin mengalami ketidakstabilan. Seperti yang dijelaskan dalam dokumen ini, kami telah membuat asumsi penyederhanaan (altruisme) dan berfokus pada fungsionalitas terbatas (hanya PDF). Selain itu, gateway menyajikan aspek terpusat, yang di masa depan harus digantikan oleh konsensus jaringan yang terdesentralisasi, dan protokol harus diamankan dengan insentif.
Implementasi kami mengambil pendekatan prinsip pertama. Kami bertujuan untuk membangun dari bawah ke atas, daripada mengandalkan pendekatan dan solusi yang ada untuk komponen sistem. Kami percaya ini diperlukan karena solusi yang ada mungkin tidak optimal untuk konten Web3 yang terdesentralisasi. Dengan kata lain, ada banyak pekerjaan yang harus dilakukan.
Saat ini kami kadang -kadang mengalami masalah dalam proses merangkak karena waktu pembaruan IPN. Kami sedang berupaya menyelesaikan ini dengan solusi alternatif.
