
بحث 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 Search على عقدة موثوقة (نفس العقدة مثل بوابةنا) لتحديث سجل IPNS يشير إلى أحدث إصدار من TLI. عندما يزحف العملاء ، تتضمن الخطوة النهائية لهم إرسال طلب تحديث إلى هذا الخادم. في الوقت الحالي ، سيحتاج العملاء إلى تحديد كلمة مرور في ملف التكوين الخاص بهم ، والتي يمكن الحصول عليها من المشرفين ، حيث سيتم تنفيذ التدابير الأمنية لاحقًا.
حاليًا ، لدى مستخدمي الويب القليل من البدائل لمحركات البحث المركزية . تحافظ هذه المحركات على السيطرة المركزية والسياسة والثقة ، والتي قد تؤدي إلى قضايا في الرقابة وحماية الخصوصية والشفافية.
علاوة على ذلك ، تركز هذه المحركات عمومًا جهودها على محتوى الويب التقليدي (المستضافة في خوادم الويب ، التي يتم الوصول إليها من خلال DNS). ومع ذلك ، في نموذج Web3 ، حيث من المتوقع أن يتم تخزين المحتوى في شبكات التخزين اللامركزية (مثل IPFs) ودقة الأسماء التي يتم من خلال حلول blockchain (على سبيل المثال) ، يلزم محرك بحث بديل.
باختصار ، هناك حاجة إلى آلية البحث التي تبحث عن بيانات لا مركزية ، وتفعل ذلك بطريقة لا مركزية.
هناك عدد من المشاريع المماثلة ، التي حاولت حل مشكلة المركزية في البحث على الويب. بادئ ذي بدء ، هناك تطبيقات ومقترحات من الأبحاث لآليات البحث الموزعة / اللامركزية لبيانات الويب الحالية. تشمل المشاريع المبكرة Yacy و Faroo و SEAND. في الآونة الأخيرة ، يهدف Presearch إلى إنشاء محرك بحث تعاوني باستخدام مكافآت blockchain للحوافز.
وبالمثل ، يهدف عدد من الأعمال إلى توفير البحث الموزع عن شبكات تخزين P2P. في الآونة الأخيرة ، قام الرسم البياني ببناء بروتوكول فهرسة لا مركزية لبيانات blockchain باستخدام حوافز العملة المشفرة.
ومع ذلك ، لا يلتقط أي من المشاريع المذكورة أعلاه تمامًا حالة الاستخدام المحددة للبحث اللامركزي عن بيانات Web3 اللامركزية.
تعتمد بنيةنا على عدد من العقد العميل ، التي تحافظ بشكل جماعي على الفهرس وتضيفها ، وتكون قادرة على إجراء عمليات البحث. لقد اتخذنا نهج الانتهاء من protype العاملة لهندسةنا أولاً ، وإضافة ميزات بشكل تدريجي. لذلك ، يعتمد نسختنا الحالية على عقدة موثوقة (بوابة) لتحديث سجل TLI IPNS. نظرًا لعدم وجود أمان أو تحفيز إضافي يتم تنفيذه ، استخدمنا كلمة مرور بسيطة للسماح لعقد العميل الجديدة بإضافتها إلى الفهرس. على الرغم من أن الأمن قد يكون غير كافٍ في المستقبل ، إلا أننا نفترض نموذجًا إيثارًا لإصدارنا في مرحلة مبكرة.
في المستقبل ، نتصور أن يتم إضافتها إلى الأمان والحوافز المعمول بها ، والتي تتوافق مع العقد لتكون صادقة عند تحديث الفهرس. قد تكون هذه في شكل مكافآت cryptocurreny ، والقطع ، والسمعة ، وما إلى ذلك. يمكن أن تكون إحدى الطرق لتمويل المكافآت للعقد الصادقة من خلال دمج الإعلان في البروتوكول والسماح بتفويض رسوم الإعلان إلى العقد التي تحافظ على الشبكة.
يدعم نسختنا الحالية ملفات PDF فقط على IPFs لإضافتها إلى الفهرس. في المستقبل ، نود توسيع هذا إلى المزيد من أنواع الملفات والأدلة ، ودعم شبكات التخزين اللامركزية المختلفة. أخيرًا ، نهدف إلى دمج البيانات القائمة على blockchain مثل العقود الذكية في البحث.
نقدم الآن نظرة عامة على العمليتين الرئيسيتين في آليتنا.
يبدأ البحث باستعلام من قبل العميل الذي يحتوي على عدد من مصطلحات البحث. يقوم العميل بعد ذلك بإحضار أحدث TLI عن طريق حل اسم IPNS المحدد بواسطة البوابة إلى CID المقابل. يتم بعد ذلك جلب TLI وتجريرها للتحقق مما إذا كانت الكلمات الرئيسية تحتوي على KSI. إذا كان هذا هو الحال ، فإن KSI ذات الصلة هي استفسارات ، لإرجاع المحتوى الذي يحتوي على الكلمات الرئيسية. يمكن للعميل بعد ذلك استرداد هذه الملفات من الشبكة.

أحد الجوانب المهمة في محركات البحث هو آلية الترتيب. يحدث هذا بشكل عام بطريقة مركزية ، دون تأثير كبير من العملاء. على الرغم من أننا لم ننفذ آليات تصنيف متطورة ، إلا أننا نتصور أن يكون هناك ترتيب في عملاء النتائج ، مما يمنحهم قوة وشفافية أكبر. يسمح ذلك للعملاء بالتحكم في وظائف الترتيب وتخصيصها بناءً على الاحتياجات المحددة. في الوقت الحاضر ، تعيد آليتنا النتائج المطلوبة على أساس CID. عند إدخال مصطلحين للبحث ، يتم إرجاع الصفحات التي تحدث فيها كلاهما أولاً ، وبعد ذلك يتم إرجاع الصفحات التي تحتوي على واحدة فقط من المصطلحات.
جانب مهم من أي محرك بحث هو إضافة إدخالات إلى الفهرس. تتضمن هذه العملية عددًا من الخطوات ، التي نصفها أدناه.
القرار الأول الذي يتم اتخاذه هو ما الذي سيتم إضافته إلى الفهرس ، والذي نسميه Curation . في المحركات التقليدية ، يتضمن ذلك جميع محتوى الويب العام. على الرغم من أن هذا يحقق أداءً عاليًا ، إلا أنه قد يضيف الكثير من النفقات العامة عند تنفيذه في شبكة لا مركزية. قد يكون هناك نهج آخر هو تنظيم بناء على إجماع الشبكة على المحتوى المهم. بالنسبة لنظامنا الحالي ، نسمح لأي شخص يعتقد أن المحتوى مهم لإضافة هذا إلى الشبكة. يمكن معالجة المحتوى بواسطة معرفات CID أو DNSLink أو ENS أو IPNS.
بعد ذلك ، يحدث الزحف ، والذي يتضمن جلب الملفات وتحليلها لاستخراج الكلمات الرئيسية المهمة. كما ذكر أعلاه ، يزحف نظامنا عندما يقرر شخص ما إضافة المحتوى ، وبالتالي يقدم يدويًا CID ليتم زحفه. في المستقبل ، نتصور أن هذا يحدث تلقائيًا عند تحميل المحتوى أو زيارته على الشبكة. إلى جانب استخراج الكلمات الرئيسية ، يمكن إضافة بيانات تعريف أخرى. نستخدم حاليًا نوع الملف (PDF) والطابع الزمني عند الزحف ، ولكن في المستقبلية القصد من إضافة العنوان أو العد والحجم وما إلى ذلك.

بعد استخراج الكلمات الرئيسية (وإنتاج RWI) ، يجب تخزين الفهرس. بالنسبة للتخزين ، نستخدم IPFs ، لأن هذا يسمح بتخزين تعاوني لا مركزي. لقد قررنا الحفاظ على تسلسل هرمي من مستويين. سيكون لكل كلمة رئيسية ملف فهرس مرتبط (KSI) حيث يمكن للعقد أن تجد المحتوى الذي يحتوي على تلك الكلمات الرئيسية. يتم الاحتفاظ بفهرس منفصل (TLI) للإشارة إلى معرفات KSI ، ويتم نشر هذا باسم IPNS من خادم Gateway الخاص بنا. عندما تقوم عقدة بتحديث KSI بعد الزحف إلى ملف ، فإنها تقوم بتحديث المؤشر في TLI إلى هذه الملفات ، ويطلبون البوابة لتحديث المؤشر الذي يحل سجل IPNS إليه. وبهذه الطريقة ، يشير سجل IPNS إلى أحدث إصدار من TLI ، والذي يشير بدوره إلى أحدث إصدارات KSI.
في الوقت الحاضر ، يمكن لعقد العميل تغيير TLI إذا كانت تمتلك كلمة مرور ، والتي يمكن الحصول عليها من مشرفي هذا المشروع. بهذه الطريقة ، تكون الإدخالات الخبيثة المحتملة أقل احتمالًا. يمكن اعتبار العقد التي تحتوي على كلمات المرور "سلطات" في الشبكة.
أثناء التطوير والاختبار ، قمنا بعمل عدد من الملاحظات فيما يتعلق بالأداء. نظرًا لأن حلنا يعتمد اعتمادًا كبيرًا على IPFs ، فإن أدائنا كذلك. لقد وجدنا أن التأخيرات الكبيرة قد تحدث عندما لا تضيف العقد نظير البوابة في سرب من أقرانهم. بينما أضفنا هذا إلى CLI ، لا يزال الاتصال يسقط من حين لآخر. في حين أن هذا لا يكسر النظام ، إلا أنه يضيف تأخيرات.
علاوة على ذلك ، يمكن أن يكون تحديث إدخال IPNS الخاص بنا من البوابة بطيئًا للغاية ، وقد يصبح عنق الزجاجة في الأداء عند زيادة حركة المرور. لقد بدأنا في النظر في بدائل ، لكن ترك التنفيذ للإصدارات المستقبلية. يتمثل أحد الخيارات في استخدام DNS لتخزين مؤشر لأحدث سجل TLI ، ولكن هذا يجلب عددًا من التحديات الإضافية الكامنة في DNS. يمكن أيضًا استخدام سجل الاسم القائم على blockchain مثل 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's).

ملاحظة: يتم حاليًا البوابة أثناء الترقية إلى الإصدار 2.
Libraryيقوم كل من CLI و Gateway Run باستخدام حزمة البحث 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. نحن نعمل على حل هذا مع حلول بديلة.