Comments 26
КМК любительские поисковые движки должны являть собой «добровольный ботнет», где несколько участников отвечают за каждое ключевое слово, и есть какой-то хэш, позволяющий быстро выяснить, кто это и как у него запросить список страниц, где оное есть.
А, и система рейтингов, чтобы быстро давить поисковый спам, внедрившийся под видом «своих».
ИМХО в такой системе самый сложный вопрос - надёжность работы ботнета в условиях, что каждый узел может быть недоступен (комп/телефон/итп выключен/вне сети)
От ботнета же чего хотим? распределённого хранения индекса/инфы (чтобы каждый не хранил свою копию)
От поиска чего хотим? Устойчивой работы.
И здесь противоречие для добровольного ботнета на десктопах/телефонах пользователей
Да, там надо изрядно дублировать, поэтому же, кстати, какие-то узлы будут в курсе каких-то сайтов, а какие-то — не очень, и в зависимости от числа их онлайн будут постоянно плавать результаты выдачи.
Ещё сложная штука там — приватность vs рейтинг. Зашли мы на какой-то сайт, бот собрал ключевые слова, зашифровал и отправил по цепочке узлов так, что на приёмном конце фиг поймёшь, кто реально заходил на этот сайт, а кто просто промежуточное звено (непонятно, где зародилось начало). Легко.
Но теперь стали приходить жалобы, что такое-то соответствие «слово + сайт» — фейковое. Как организовать обратную цепочку, чтобы все соседи поискового спамера знали, что он — поисковый спамер? Найти, от кого исходила цепочка N, но не говорить, что в ней было?
UPD: там ещё как-то надо различать невинных жертв, попавших на поисковый спам методом «лучший, новый, главный, самый, секс, Москва и реферат» ®©™, и злонамеренных спамеров, которые эти ключевые слова сами выдумали. В первом случае надо понижать страничку, вплоть до блэклиста, во втором — рейтинг узла, вплоть до бана.
По моему мнению, централизованные решения проблем (вроде глобального рейтинга узлов, чёрных списков, всеобщего бана) в распределённых системах имеют характерные для централизованных систем недостатки и снижают преимущества распределённых систем на порядок.
Вместо этого, почему бы не вести распределённый реестр источников/краулеров с пометкой «доверенный/спам-бот». Версионировать его в распределённой СКВ (подходит ли git для этого?). Когда обнаружится, что «слово + сайт» — фейковое, можно посмотреть цепочку: кто краулер, кто добавил его в реестр.
Как вы понимаете, у меня proof-of-concept нет, всё это пустые слова на настоящий момент, но я сторонник мнения, что децентрализацию нужно проводить до конца.
Проблему распределенного хранения данных от части решили, например в Storj. IPFS так же может подойти для этих целей. На основе их решений вполне себе можно создать что-то подобное.
«добровольный ботнет», где несколько участников отвечают за каждое ключевое слово
Обычно люди ищут не по одному слову. а по нескольким. И в индексированном тексте не одно слово, а тысячи.
А, и система рейтингов
А тут нужна какая-то организация, назначающая рейтинги.
Ну как, если человек кликнул ссылку, увидел, что там, и ломанулся назад тут же — вот уже повод усомниться… а если нажал репорт — то сразу можно снимать балл, не изучая массовые реакции :)
Тут крайняя степень опенсорса нужна, потому что такой поисковик по определению ооочень много знает о браузере, в который интегрирован. И нужны сложные гарантии того, что он не поделится этим ни с кем.
как-то под пиво прокрастинировали с одним коллегой на тему поисковика на базе блокчейна, где майнер=краулер а поисковый запрос утекает в цепочку 100% проверенных ссылок. но пришли к выводу что за пару лет использования (при условии что он станет популярным) размер блокчейна перевалит за петабайт и станет неюзабельным для масс..
Значит делайте распереденный блокчейн, чтоб на каждой ноде по 100 мегабайт хранилось, разумеется с многократным дублированием.
А зачем для этого блокчейн? Какие он свойства системе добавляет?
Повысит вероятность найти инвестора.
поисковики хостящиеся "у дяди" имеют несколько недостатков:
1) спонсорские выдачи которые всегда наверху независимо от того а подходят ли они вообще под поисковый запрос
2) реклама
3) безполезные интеграции с прочими сервисами "дяди"
4) единственный web ui который невозможно подкрутить под себя и который имеет свойство меняться (зачастую не в лучшую сторону) по воле того самого "дяди"
5) чистку от неугодных выдач по запросу непойми кого из страны в которой этот самый "дядя" обитает
децентрализованный неподвластный законом одной страны поиск эти проблемы решает, как это сделать без блокчейна я не знаю.. если вы знаете предложите.
Без "дяди", следящего за контентом, весь этот блокчейновый поиск будет завален спамом, да и искаться всё будет с жуткими тормозами. А "дядя" за свою работу захочет денег (в т.ч. в форме рекламы, привязки к своим сервисам и т.п.). И за "дядей" будет следить другой "дядя" - в штатском, но со званием.
тут в проли следящего за контентом было предложено задействовать майнеров-краулеров, их задачи конечно до конца так и не были продуманы, там много, поиск и каталогизация, тегирование, проверка на актуальность, проверка на время появления и ещё куча всего.. но в целом да, я понимаю что идея гавно, просто и лучше идей нет.
Распределенная база данных и блокчейн - разные вещи.
Задача блокчейка - хранить историю в неизменном виде, за счет того, что изменить что-то в блокчейне практически невозможно по вычислительным ресусрам. Блокчейн не обязательно распределенный, он может храниться "у дяди".
То, что вы говорите это распределенная БД, где тоже используется криптография для валидации и аутентификации данных. Но решается как раз ваша задача.
Мёртвые ссылки в файле pages.txt значительно замедляют процесс сбора содержимого. Мне нужно найти способ исключить попадание таких ссылок в этот файл или наладить их удаление из него.
Ссылки могут быть мертвыми временно. Надо просто использовать много экземпляров wget. Пусть некоторые из них ждут (это ничего не стоит) другие будут работать.
Какой же бред в контексте современного веба.
Идея то хорошая - часто пытаешься вспомнить что-то, что видел в интернете, но не помнишь где. Но через wget качать страницы с истории браузинга при условии, что и так все было локально отрендерено в момент чтения, очень тупо. Учитывая, что современный интернет весь завешан пейволами, авторизациями, защитами от ботов, необходимостью надеть впн конкретной страны, да и, кроме того, даже пробившись через все эти защитные сооружения, с учетом повсеместного испольбзования ajax, не факт, что страница будет прямо соответствовать урлу, а, если и будет, что контент выйдет загрузить без исполнения js.
В принципе, проект оносительно несложно можно сделать и, чтобы он работал как надо, а именно - не читать базу истории и парсить заново, а написать свое расширение браузера, и дампить текущий dom при значительных обновлениях контента. Тогда сохраняться будет именно то, что пользователь видел, и в том виде, как пользователь его видел. Включая, например, такой бесячий случай, как интересный пост в алгоритмической ленте соцсети, который увидел мельком, уже кликнув куда-то, и не увидев его на месте, нажав undo, ибо лента перегенерилась.
Самое забавное, что где-то даже видел информацию о стартапе, который делает технологию, сохраняющую и индексирующую всю историю взаимодействия пользователя и компьютера, включая посещенные сайты, переписки, расшифровки звонков, чтобы всегда можно было вспомнить, но как он называется, я таки забыл, и пару минут гуглежа тоже не помогли)
где-то даже видел информацию о стартапе, который делает технологию, сохраняющую и индексирующую всю историю взаимодействия пользователя и компьютера, включая посещенные сайты, переписки, расшифровки звонков
стартап называется «Товарищ майор»?
В принципе, проект оносительно несложно можно сделать и, чтобы он работал как надо, а именно - не читать базу истории и парсить заново, а написать свое расширение браузера, и дампить текущий dom при значительных обновлениях контента. Тогда сохраняться будет именно то, что пользователь видел, и в том виде, как пользователь его видел.
Уже. Подобное реализовано в расширение ArchiveWeb.page (только Chromium-браузеры). Но:
По названию понятно, что акцент на архивацию, а не поиск.
Дампит не DOM, а запросы и ответы, если я правильно понимаю, как оно опирается на WARC-файлы - в общем, даже лучше.
По ключевым словам "WARC MITM proxy" можно найти близкие проекты вроде warcprox, но среди нет самодостаточных, поэтому ими не интересовался.
В контексте современного веба, как мне кажется, полезнее делать краудсорсинг сбор серпов гугла по какому-то срезу ключевых слов. Собственно, серпы гугла собирает куча компаний, но они тратят свои деньги и ресурсы на это и жертвовать в интересах сообщества не горят. А гугл, в свою очередь, активно с этим борется
Немного не по теме, но Yacy
Мой первый прототип поискового движка