18 февраля 2011 в 16:33

ВикиГуглоМетаТрекерная DNS


Одно из главных препятствий к созданию столь желанного многим (и мне тоже) по-настоящему децентрализованного интернета — проблема поиска, классификации, именования и упорядочения сайтов и файлов в сети. Недостаточно создать среду для децентрализованной обработки и хранения информации, надо сделать так, чтобы в этой среде было удобно искать нужные куски данных.

А иначе получается — за что боролись, на то и напоролись. Вместо информационного изобилия получится помойка. Количество информации в сети таково, что невозможность найти нужные данные эквивалентна полному их отсутствию. Сигнал тонет в шуме. И еще ладно, если этот шум белый, но он ведь часто имеет ярко выраженную окраску — политическую или коммерческую.

Сегодня функции поиска и структурирования информации в интернете распределены между несколькими подсистемами. Они очень разные, некоторые из них возникли на заре интернета, некоторые бурно растут прямо сейчас.

Исторический экскурс от Капитана Очевидность


Самая старая из них — DNS. Я часто ловлю себя на том, что путаю понятия «имя» и «адрес» сайта. Хотя адрес отвечает на вопрос «где?», а имя — на вопрос «что?». IP-адрес и доменное имя. DNS — система наименования, а не адресации ресурсов.

На DNS можно посмотреть, как на огромный, но очень лаконичный каталог ресурсов интернета. Все четко разложено по иерархическим полочкам, каждая запись DNS содержит имя сайта, имя и адрес (не факт, что настоящие) владельца и немного служебной информации, которая связывает имя сайта с его адресом. Возможно, это была великолепная идея на заре интернета, когда сайтов было немного, а пользовались ими почти исключительно ученые и программисты, которые, если что, и по IP-адресу могли сориентироваться. Сейчас же, когда счет сайтов идет на десятки и сотни миллионов, а среднестатистический пользователь сети не только не помнит IP-адресов любимых сайтов, но и вообще не знает, что такое IP-адрес, в руках администраторов системы DNS сосредоточилась непозволительно огромная власть. Чик! — и сайта просто нет. Если у сайта отобрать хостинг, при достаточно высокой квалификации админов почти никто ничего не заметит, максимум — несколько часов даунтайма. Потеря домена — катастрофа куда большего масштаба.

Если DNS — предельно лаконичный каталог, то каталоги вроде Yahoo содержали гораздо больше полезной информации. Но это же преимущество и свело их в могилу. Когда сайты стали появляться, как грибы после дождя, поддерживать актуальность и точность каталога стало практически невозможно. Каталоги сменились поисковыми системами. В них громоздкая система разделов, категорий и подкатегорий уступила место поисковому запросу, а заполняемые вручную записи — автоматическому индексу.

Поисковики первого поколения решили проблему масштабирования «картотеки интернета» ценой ухудшения её качества. Хитрые веб-мастера быстро освоили методики обмана поисковых машин путем манипуляций с ключевыми словами на страницах сайта. И вот тут-то на сцене появились первые ласточки децентрализации в виде Page Rank. Гениальная идея использовать для ранжирования результатов поиска не только (и не столько) контент самого сайта, но и поведение пользователей, выраженное в виде ссылок на сайт со сторонних ресурсов, стала основой могущества Google.

Обратите внимание, насколько похожи работа браузера с DNS, и работа пользователя с Google. В обоих случаях на входе есть некая строка, которая отвечает на вопрос «Что?». Эта строка отдается на обработку DNS-серверам или датацентрам Google, и они дают ответ на вопрос «Где?» лежит это самое «Что?»

А что если совместить идеальную чёткость и простоту иерархического каталога с масштабируемостью и самоорганизацией «роевого интеллекта» массы пользователей?.. Так появилась Википедия. Она вроде бы и не предназначена для поиска, но лично я не знаю более удобного способа получить подборку качественных ссылок по любой теме, чем пробежаться по соответствующим разделам Википедии. Один из базовых принципов Википедии — статьи не должны содержать оригинальных исследований и информации без ссылок на источники, прозрачно намекает на то, что Википедия — это именно каталог. Просто он куда более универсальный и содержит описания не только ресурсов интернета, но и объектов реального мира, что маскирует его сходство с DNS и поисковиками.

В мире файлообмена эволюция подходов к поиску и фильтрации нужных файлов шла немного по-другому. В доисторическую эпоху царил полнейший бардак. В пределах своего датацентра или компьютера люди иногда поддерживали какой-то порядок в соответствии с личными вкусами или стандартами фирмы. В целом же это была глобальная файлопомойка. Первые попытки навести порядок в масштабе всего интернета натыкались на тот прискорбный факт, что многие файлы были защищены авторским правом, и их хозяева вовсе не горели желанием облегчить свободный доступ к их «прелести»… Так погиб Napster. На его обломках выросли более устойчивые к административному воздействию торрент-трекеры. Полностью децентрализованное хранение и раздача файлов — куда более крепкий орешек для цензуры и вымирающих копирайтозавров. Однако и подход «Мотороллер не мой, я только разместил объяву» не спасает на все сто. Их все равно продолжают давить с помощью тех же DNS и Google (который, хоть и использует децентрализованный подход при расчете PR, но вполне может «подправить» результат выдачи под достаточным давлением правительства или при угрозе крупных исков).

Поисковый полуфабрикат


Итак, если мы хотим создать децентрализованный интернет, недостаточно (а может быть и не так уж необходимо?) делать P2P-версию DNS. Нужен и P2P-поиск, и P2P-каталоги, и P2P-трекеры. На первый взгляд — неподъемная задача. Но есть один маленький нюанс. Создать универсальную и единственно верную систему поиска, классификации и фильтрации контента — не просто неподъемная, а вообще неразрешимая задача. Такой системе просто никто не будет доверять. В децентрализованной среде не может быть «единственно верных» решений. Нужна конкуренция, чтобы развивались алгоритмы, нужен выбор, чтобы пользователи не чувствовали себя «под колпаком». Как ни парадоксально звучит, это сильно облегчает задачу.

Подробности реализации алгоритмов разных поисковиков могут довольно сильно отличаться, но все они пользуются примерно одинаковыми исходными данными. Типичные поисковые запросы, грамматика языка, глобальный граф ссылающихся друг на друга страниц, статистика посещений — все это не зависит от конкретного движка. Или, если взять сообщества и социальные сети с системой рейтинга или кармы — социальный граф и история всех плюсиков и минусиков в системе. Или у торрент-трекеров — количество скачиваний, сидов и личей у каждой раздачи, объемы закачки-отдачи каждого участника. На базе этих сухих необработанных данных можно по-разному считать PR, ТИЦ, рейтинг, бонусы, рекомендации и многое другое.

Как в боксе, когда при одинаковых базовых правилах и технике есть множество версий и форматов соревнований — все эти WBA, WBO и WBC, так и в децентрализованном интернете можно предусмотреть некий базовый формат метаданных, на основе которых будут конкурировать друг с другом разные алгоритмы поиска, ранжирования и фильтрации. И, так же, как в боксе могут проводиться объединительные бои чемпионов разных версий, надо дать возможность пользователю выбирать, какой алгоритм использовать для обработки общедоступных базовых метаданных. Тогда сразу будет видно, кто есть кто. Будет здоровая конкуренция между алгоритмами. Все алгоритмы будут открытыми, ведь если код будет выполнятся распределенно на машинах клиентов, обфусцировать и прятать его — сизифов труд. А значит не будет почвы для подозрений, что кто-то считает нечестно или несправедливо. Всё равно сомневаешься? Зайди в настройки, переключись на другой алгоритм и проверь.

Такая модульная архитектура систем поиска, рейтингов или рекомендаций удобна и в другом случае. Если в качестве исходных данных мы используем множество субъективных мнений пользователей системы, не важно, в косвенном виде — считая ссылки, покупки, френдов, загрузки, или в прямом — считая плюсики и минусики в карму и рейтинг, то неизбежно столкнемся с ситуацией, когда система выдаст результат, основываясь на мнениях, которые абсолютно не относятся к делу. Например, я изучаю Ruby. И где-то здесь некий хабраюзер, который хорошо знает Ruby, пишет интересную мне статью. Но при этом у него мерзкий характер и плохие манеры. Он влезает в холивар в топике про PHP, приходит в ярость, обзывает всех быдлокодерами и кроет матом. Конец немного предсказуем. Его статья так и не будет опубликована. Конечно, он сам виноват, но мне какое дело до его манер? Меня интересует Ruby, а система заблокировала публикацию статьи, основываясь на плохом воспитании и отсутствии выдержки у хабраюзера.

В модульной системе я бы смог выбрать, какой набор исходных данных скормить алгоритму. Например, с помощью тэгов я бы ограничился кругом пользователей, чьи интересы, знания и навыки релевантны моему запросу. Сейчас такое возможно только путем перегораживания интернета непроницаемыми переборками на маленькие куски, где в целом все имеют общие интересы. Например, наш гипотетический невоспитанный рубист не схлопотал бы пачку минусов, находись он в узком сообществе Ruby-программистов. Но маленькие сообщества менее жизнеспособны и варятся в собственном соку. При модульном подходе я бы мог посмотреть на один и тот же материал глазами разных людей, оставаясь при этом в одной и той же привычной среде.

Как может выглядеть универсальный формат метаданных?


Как объединить файлы, людей, сообщества и сайты в единую структуру? Очевидно, что нужно залезть на уровень абстракции повыше. Что общего у всех этих сущностей? Как минимум то, что это ресурсы, которые находятся в интернете. Ну, или, по крайней мере, они представлены в интернете. Ничего не напоминает? Например, ресурсы и их представления в модели REST? Лежит, скажем, в файлообменной сети фильм “The Delta Force” с Чаком Норрисом и гнусавым одноголосным переводом. Собственно фильм, как и любой ресурс REST — понятие абстрактное, он существует только в виде своих представлений. Например, обычная, режиссерская и порезанная цензурой версии. Или оригинал, дубляжи и переводы на разные языки. Или файлы с разным разрешением и битрейтом. Всё это — представления одного и того же ресурса. Ресурс отвечает на вопрос “Что?”, его представления — на вопрос “Какой?”

Эта схема позволяет выводить из таких базовых технических метаданных, как количество скачиваний определенных файлов, популярность ресурса в целом — достаточно сложить показания счетчиков по всем представлениям ресурса. Она позволяет гибко оценивать ресурсы — например, я ставлю +1 ресурсу и одному из его представлений («отличное кино!») и -1 другому представлению («режиссерская версия чересчур затянута»). Или, еще пример: +1 ресурсу («интересная статья») и -1 представлению («вырвиглазная верстка»).

При появлении в сети нового объекта — для определенности, пусть пока это будет фильм, автоматически создается файл метаданных с информацией о предаствлении. Если представление существует в единственном экземпляре (мы выложили в сеть нечто абсолютно уникальное), то создается второй метафайл уровня ресурса. Если же в сети уже существовали другие представления этого ресурса, то информация о новом представлении заносится в соответствующий метафайл ресурса.

Между объектом и его метафайлом существует неразрывная связь. Например, метафайл хранит хэш объекта, а имя метафайла выводится из хэша объекта заранее известным стандартным способом, скажем путем повторного скармливания хэш-функции хэша объекта. Таким образом, имея абсолютно неопознанный файл, когда-то скачанный из интернета и несколько раз переименованный, можно вычислить его хэш и получить все метаданные о нем. Или убедиться, что этот файл уникален, и другого точно такого же скорее всего нет нигде в открытом доступе.

Что должно храниться в таком метафайле? Размер, тип, дата публикации, хэш самого файла, ссылка на вышестоящий метафайл ресурса… что еще? Так как речь идет о распределенной сети, то очень неплохо было бы хранить информацию об узлах, на которых есть копии или фрагменты этого файла, счетчик числа скачиваний, оценку доступности файла, примерную скорость, с которой он может быть скачан и так далее, чтобы каждый файл был самому себе трекером. Еще, конечно же, нужна будет история оценок представления и список внешних ссылок (в случае анонимной публикации и тайного распространения файла, эти две секции, естественно, будут почти пустыми). Если файл не предназначен для всеобщего обозрения — нужен список контроля доступа. В случае текстового файла не помешает индекс или сгенерированное автоматически облако тегов. Плюс дополнительное облако тегов, созданное на основании реакции людей.

На уровне ресурса, кроме оценок, общей статистики и ссылок на нижележащие метафайлы — почти чистая семантика: теги и оценки, общие для всех представлений, и поля, сильно зависящие от типа файла: имя, название, пол, возраст, автор, жанр, и т.д… Уровень ресурса — мост между семантической паутиной с её онтологиями и логическим выводом и более техническими и стихийными вещами, такими, как оценки, ссылки и счетчик обращений. Движение по этому мосту — двухстороннее. Зная хэш — можно получить всю информацию о файле, поднявшись по цепочке до семантического уровня. Имея лишь самый общий поисковый запрос, можно спуститься до конкретного представления файла.



Так как набор метаданных может сильно отличаться для разных типов ресурсов, то нет смысла стандартизировать формат метафайла в целом. Достаточно согласовать стандартные названия для разных типов метаданных, а поисковый алгоритм будет просто игнорировать файлы, в которых нет нужных ему полей. Примерно как в языках программирования без строгой типизации важен не столько тип объекта, сколько набор методов, которые он реализует.

Кто же будет заполнять эти метафайлы информацией? Да все понемногу. Стоит подчеркнуть, что метафайлы не принадлежат владельцу ресурса, он может влиять на их содержание очень ограниченно. В его полной власти только списки контроля доступа. Многие вещи, такие, как статистика, размер файла, дата публикации, список пиров, индекс или облако тегов могут заполняться и модифицироваться автоматически. Другие — такие как ссылки на выше- и нижестоящие метафайлы или созданные вручную теги первоначально заполняются владельцем при публикации, но потом их содержание может меняться под влиянием пользователей. Третьи — например оценки, изначально закрыты для хозяина файла и целиком контролируются сообществом.

Если формат метафайлов жестко не задан, и любой, имеющий доступ, может вносить в них информацию, то как уберечь их от естественного или злонамеренного засорения? Если речь идет о модификации уже существующих полей, то правильность информации гарантируется консенсусом нескольких узлов сети, которые будут перепроверять друг друга.

А если кто-то придумал алгоритм поиска или ранжирования, для которого надо учитывать совершенно новые характеристики ресурса? Можно, конечно, ввести некий авторитетный орган, который будет утверждаять стандартные наборы метаданных для каждого типа ресурсов. Но как раз от подобных схем мы и хотим уйти, не правда ли? Как же всё-таки определить, какие записи в метафайле полезны и востребованы, а какие устарели или вообще никогда не были нужны?

Смоделируем эту ситуацию. Пусть мы храним в метафайлах музыкальных ресурсов следующую информацию:
  • Название трека, альбом, исполнитель, дата выпуска и т.д.
  • Технические характеристики — формат, битрейт, хронометраж
  • Статистика скачиваний
  • Доступность ресурса (например, количество активных сидов, если воспользоваться терминологией BitTorrent)
  • Облако тэгов
Допустим, некто решает, что неплохо было бы хранить в метафайле информацию о темпе музыки в Beats Per Minute. Он не может просто так взять и начать добавлять в музыкальные метафайлы по всему интернету новое поле. Но он может попытаться доказать, что эта информация востребована. Например, создать систему поиска музыки с учетом BPM. На первых порах ему придется собирать и хранить метаданные своими силами. Если людям понравится новая возможность, то они все чаще будут запрашивать информацию о темпе и она будет оседать в их кэшах. Если информация о темпе некого произведения наберет пороговое число запросов (нам легко это узнать, ведь такая информация пока не входит в метафайл, а значит сама по себе является ресурсом, и сеть хранит статистику доступа к ней) — мы включаем её в метафайл. Каждое такое включение — свидетельство того, что информация востребована, и мы можем постепенно снижать порог, вплоть до того, что начнем требовать указать темп музыки непосредственно при публикации ресурса. BPM становится de facto стандартным полем метафайла.

Точно так же можно и удалять ненужные метаданные. Если очень долгое время никто их не запрашивал, то можно начать чистку метафайлов.

Таким образом, большая часть неспецифической информации может собираться и храниться независимо от каких-либо поисковых движков или систем учета репутации. С одной стороны, мы освобождаем создателей алгоритмов поиска или выдачи рекомендаций от кучи предварительной работы по сбору информации и её хранению, с другой не забиваем себе голову созданием и отладкой этих самых алгоритмов, ограничиваясь лишь механическим заполнением метафайлов сырыми данными.

От файлов к сайтам и людям


Каждый сайт — это составной ресурс, который содержит коллекцию вложенных ресурсов. Его рейтинг или репутация должна зависеть от совокупности показателей подчиненных ресурсов. Само понятие сайта сильно размывается в такой схеме — децентрализация же!

Но пока что сайты — основной способ структурирования интернета. И в обозримом будущем мало что изменится. А для сайта очень остро стоит вопрос имени. Если имя файла где-то в сети мало кого волнует, то простое и легко запоминающееся имя сайта очень важно. Существующая система доменных имен худо-бедно работает. Что можно предложить взамен?

Запись с именем сайта в метафайле уровня ресурса? Вполне может быть. Ведь в чем главная проблема системы DNS? В том, что запись сервера имен не несет практически никакой полезной информации. По имени сайта совершенно невозможно узнать, соответствует ли название содержимому, насколько популярен сайт, кому он принадлежит. В наших же метафайлах все это есть. И поэтому нельзя будет ввести кого-либо в заблуждение, присвоив своему сайту имя «microsoft.com» Ни один из клонов не сможет и близко подобраться к тому уровню репутации, который есть у оригинала. А если сможет — то это означает наличие у оригинала проблем, которые не лечатся простыми методами.

Так же потеряет всякий смысл и киберсквоттерство. Живой, активно развивающийся ресурс, или официальный сайт известной компании очень быстро уделает сквоттера по всем показателям.

В то же время имена с омонимами, или локальные сайты с одним и тем же именем, вроде «такси» смогут вполне мирно существовать, если поисковая система будет в явном виде сообщать пользователю о неоднозначных результатах, и просить уточнить запрос (или делать это самостоятельно, руководствуясь контекстом, например, географическим).

Как насчет общих имен, вроде «пиво» или «авто»? Тут принцип тот же, что и с доменами — кто первый встал, того и тапки. Только отсчет начинается не с момента создания метафайла, а с начала реального наполнения и раскрутки сайта. И, в отличие от ситуации с доменами, когда первый шустрый счастливчик может закрепить за собой имя навечно и стать собакой на сене, любой более активный и толковый веб-мастер сможет перетянуть на себя поток трафика.

Ну и конечно же, никакими силами невозможно отобрать, заблокировать или передать другому сайту хорошо раскрученное имя. Потомки Викиликс будут довольны.

В целом ситуация с именами сайтов очень напоминает оную с именами людей. Вам никто не запретит поменять паспорт и стать Чаком Норрисом. Но бить ногой с разворота вы от этого не научитесь. Скорее всего, настоящий Чак Норрис даже не узнает о вашей возне с бумажками в паспортном столе.

Между прочим, стирание границ между DNS и поисковиками уже началось. В Chrome нет отдельной строки поиска или адреса, и многим, в том числе и мне, это страшно удобно. Если я не помню точное имя сайта, то набираю примерно что-то похожее в той же самой строке, и, как правило, быстро попадаю, куда мне нужно. Это значит, что старая система DNS и новый формат метаданных могут мирно сосуществовать. Официально зарегистрированное доменное имя просто будет одним из полей в метафайле сайта.

Semantic web?


Придумывая и описывая формат метафайлов, я не мог избавиться от ощущения, что переизобретаю семантическую паутину. Чтобы убедить себя (а заодно и вас) в обратном, я рассмотрю сходства и отличия.

И там, и тут присутствуют метаданные. Но в семантической паутине кто-то должен эти данные вбивать вручную. Казалось бы, в чем проблема? Вон, целую Википедию написали вручную, бесплатно и анонимно! А вот и нет! Написание или правка энциклопедической статьи — работа сложная и творческая, а значит сам процесс доставляет удовольствие и служит вознаграждением автору. Работа с метаданными — по сути заполнение формы — нудное и тупое занятие. Это одна из причин, по которым “веб 3.0“ пока так слабо развит.

Однако наши метафайлы почти целиком состоят из информации, генерируемой автоматически на основании содержимого ресурса или реакции пользователей на него. Если позаботиться о правильном дизайне, так чтобы те немногие действия над метаданными, которые надо делать вручную, производились не более, чем в один — два щелчка, или одно — два слова в маленьком поле ввода, без смены контекста и лишнего визуального шума (никаких перенаправлений на отдельную страничку с формой, или всплывающего посередине экрана окна!) — то люди будут работать с системой. Например, на Хабре большинство людей активно жмет на плюсики и минусики. Если бы кроме абстрактных “+1” и “-1” можно было щелкать по тегам в небольшом облачке, то это бы не слишком утяжелило интерфейс, и позволило бы уточнять семантику ресурса. Как-то так:



Второе отличие — семантическая паутина пытается упорядочить связи между сущностями, создать онтологию, разложить все по полочкам. Это титанический труд. И это абсолютно противоестественно. Хаос, постоянные ошибки, несоответствия, многозначность присущи человеческой природе. Мы отлично ориентируемся в условиях, немыслимых для компьютера. И мы создаем ресурсы в интернете без оглядки на их место в семантической сети. Поэтому гораздо больше толку от метаданных, приспособленных для хранения ассоциативных связей между ресурсами, эмоциональной реакции на них, сбора статистики, а не только рациональной структурной информации. Впрочем, никто не мешает включить в метафайлы описание семантики в том виде, в котором оно существует сечас, и продолжать создание семантической паутины. Может быть когда-нибудь она “выстрелит”.

Веб и сейчас хранит гигантские объемы метаданных. Но они образуют не слишком удобный для жизни ландшафт с высокими горами и глубокими пропастями. Высочайшие пики современного интернета напоминают незыблимые горные вершины только внешне. Они проявляют исключительную гибкость и мягкость, избегая столкновения с местными законами и потери рынков. А те, кто не хочет проявить гибкость, рискуют быть растоптанными правительствами и конкурентами. И мы внезапно обнаруживаем, что легко доступная ещё вчера информация куда-то исчезла.

Список источников и интересностей


Коллективный интеллект

Один из подходов к созданию распределенной DNS

Попытки хранить метаданные в пириногвых сетях:
Magnet-ссылки,
Коллекции Shareaza,
Metalink,
Magnet-manifest (Magma).

Рсапределенные поисковые системы:
Majestic-12,
Всеиск,
Grub.
Илья Сименко @ilya42
карма
469,7
рейтинг 0,0
full stack javascript developer
Самое читаемое

Комментарии (39)

  • +1
    Утопично, увы.

    … и на миллиардном китайце боте сервер облако согласится, что паролем является «Мао Цзэдун» microsoft.com должен указывать на ZeuS.
    • 0
      Вовсе необязательно делать настолько тупое облако. Придумано довольно много способов борьбы с флэш-мобами, виртуалами и ботнетами. Википедия ведь как-то существует. Максимум, на что способен ботнет — DDoS-атака.
      • 0
        Вот у вас ошибка в рассуждениях, кажется. Сначала вы говорите, что википедия ненужный ручной труд, при это аргументируете свой тезис опираясь на ее существование. Тут либо надо признать что без массовой ручной работы никуда, либо мириться с существованием мириадов автоматических спамеров.
        • 0
          Боюсь, что вы кое-что пропустили, когда читали. Я писал как раз обратное —
          Написание или правка энциклопедической статьи — работа сложная и творческая, а значит сам процесс доставляет удовольствие и служит вознаграждением автору. Работа с метаданными — по сути заполнение формы — нудное и тупое занятие.


    • +2
      Хозяин microsoft.com грубо говоря создаёт торрент и задаёт его md5 (или другой) хеш.
      Всё остальное подделка.
      Сеть ботов-китайцев не сможет подтвердить Zeus (Мао Цзэдуна), т.к. их хешсумма оттличается от оригинальной.
      • 0
        А где в таком случае брать оригинальный хэш?

        Допустим, хозяин задаёт хэш microsoft.com и китаец задаёт хэш microsoft.com

        Как узнать, кто из них хозяин, а кто китаец?
        • 0
          Если microsoft и китаец сферические и в вакууме — то нигде. А если нет, то у microsoft есть куча способов доказать, кто круче — репутация, ссылки с официального сайта с традиционным доменным именем и т.п.
    • +2
      рейтинг доверия ботам и китайцам у приичного человека — чуть менее, чем 0.
      почему же у облака должно быть иначе?
      количество «навторитетных источников» в качество не перейдёт,
      при наличии упомянутой в статье «модульной архитектуры систем поиска, рейтингов или рекомендаций»
  • +2
    А у меня та же помойка на компе. Причем скачать такой же файл из интернета всё еще проще чем найти его на компе.
    • +2
      Отож! Представляете, если бы вы могли вместо файлов, которые не особо и нужны, а удалить жалко, хранить только метаданные, причем обновляемые в реальном времени. Это дало бы много интересных возможностей. Например, если доступность файла падает ниже определенного предела (когда много людей удалили у себя этот файл) — он автоматически скачивается, и вы не зависите от интернета. Если доступность высокая, можно спокойно удалить локальную копию. Эдакая глобальная автоматическая дедупликация.
      • 0
        >> и вы не зависите от интернета.
        Почему-то от этой фразы в голову влетела фраза «ё-моё, какие же жесткие должны быть у простых пользователей, что бы не зависеть от интернета?!»

        Потом правда вчитался, и понял о чем вы, но в так случае видимо нужен не слабый канал?
        • +2
          Ну а куда сейчас без неслабого канала? По сути дела, как раньше кэшировались веб-страницы, так сейчас уже в принципе можно кэшировать файлы, вообще не скачивая их явным образом. Нажал кнопку «смотреть», и через пять минут садись на диван, смотри, и еще несколько месяцев видео в кэше, раздается потихоньку. Как торренты, только меньше лишних телодвижений.
  • 0
    Концепция очень правильная. Децентрализация — процесс необратимый, более того — эволюционно обоснованный. Это как экономики СССР и США — единый контроль за всеми процессами против налаженного механизма конкуренции
    • 0
      А вы сначала почитайте что-нибудь про экономику США.
      Если бы не доллар, то она давно бы уже рухнула.
      • 0
        Согласен, но пока держится — а вот экономика СССР не выдержала, хоть и основана была не на долларе, а на нефти. Тут вопрос скорее регулирования, а не основы экономической
        • 0
          Согласен. Виновата не экономическая модель сама по себе, а её конкретное воплощение.
          Собственно как и сам коммунзим — идея вроде ничего, а реализация подкачала.
  • 0
    Я два года назад носился с идеей стартапа, очень созвучной с тем, о чем Вы тут написали. Очень интересно было бы в оффлайне пообщаться…
    • 0
      Ответил в личку.
    • 0
      А я группой в 4 человека пытаюсь написать магистерскую диссертацию по созданию ОС с похожими элементами.
  • 0
    > о в семантической паутине кто-то должен эти данные вбивать вручную.
    Кто вас так обманул? Семантический веб как раз создан для автоматической работы с данными. В том числе и для создания новых.
    Смотрите, например, dbpedia.org
    • 0
      Я знаю, что многие вещи можно выводить автоматически. Но загвоздка прежде всего в первичных данных. Когда на входе — неструктурированный текст (или, тем более, звук, картинки и видео) на естественном языке. У dbpedia на входе страницы Википедии — это промежуточный вариант, текст на естественном языке, но есть четкая структура и разметка, на которую может опереться экстрактор dbpedia.
      • 0
        Я как-то упустил описание того, почему ваши метафайлы можно получать из неструктурированного текста, а RDF-нет. Поясните?
        • 0
          Вы ничего не упустили, чудесного способа научить компьютер читать и понимать прочитанное я, увы, не знаю. Текст — это только один из многих источников метаинформации. Я не пытаюсь заменить или улучшить семантическую паутину, а лишь использовать метаданные, которые уже сейчас активно и успешно собираются автоматически — статистика загрузок, внешние ссылки, реакция пользователей. Мои метафайлы можно использовать не вместо, а вместе с семантическими.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    p2p (DNS, Web) это не разу не утопия все кому надо уже себе «сделали».
    Другим не надо или им лень этим заниматься.
  • +2
    Кстати по поводу поиска по p2p в песочнице была статья про btdigg.org, который ищет по метаинформации торрентов в DHT.
  • –6
    простите, но у Вас масса свободного времени.
  • 0
    Воооот, это уже больше похоже на правду и ближе практике. Очень много интересных идей.
    Спасибо за вашу (и Вашу) работу!
  • 0
    Отличная статья! Вопрос: каким образом защититься от целенаправленной попытки изменить метаданные, направленные например на накрутку (копирасты, бот-сети и т.д.)?
    • 0
      Об этом более подробно написано (и накомментировано) здесь: habrahabr.ru/blogs/p2p/112491/ В принципе, все сводится к защите целостности распределенной базы данных. Это довольно обширная тема. Вкратце — репутация + консенсус + контроль версий + арбитраж в самых сложных случаях.
  • 0
    Оценки конечно вещь хорошая, но в Вашем рассуждении не учитывает человеческий фактор. А именно не каждый будет выставлять оценки по 5-10 критериям (в приведенном примере озвучка, качество видео, языки, титры и пр.) иногда достаточно сложно стимулировать пользователя вообще поставит оценку. Делать это принудительно, это напрягать пользователя и создавать ощущения колпака. Да и в децентрализованной модели практически не возможно добиться актуальных оценок.

    Второй нюанс практически не возможно однозначно идентифицировать множество одинаковых объектов. Продолжая пример фильма (он один) берем к примеру название — его можно написать по разному (регистр не принимаем во внимание) т.е. в итоге у нас в каталоге будут много результатов ссылающихся на одно и тоже. Бардак остался, а если еще принять во внимание что оригинальное название можно перевести по разному и в итоге получаем рост мусора в поисковом дереве.
    • +1
      Ваш комментарий навел меня на интересную мысль. Видели такую штуку — vark.com/? Сервис вопросов и ответов. Ставится в виде, например, контакта в jabber-клиенте. Я иногда даже отвечаю на вопросы. Точно так же сама сеть может задавать вопросы об уточнении метаданных вроде ваших одинаковых фильмов. Тут как раз психологическая фишка. Если я что-то ищу в сети, то не хочу отвлекаться на оценки. А если у меня есть время глянуть, кто там чего спрашивает, то и ответить время найдется. А нет — я просто проигнорирую запрос. Важен еще тот момент, что сеть ведет себя, как живой человек — висит в списке контактов, задает вопросы, благодарит за ответы. Если вы пробовали Google Wave, помните, там были такие роботы в чате, aunt Rosy — переводчик, и другие. Прикольная штука.
      • +1
        Вы продвинутый пользователь и соответственно представляете как нужно искать т.е. вы ищете по нескольким словам/фраз которые могут указывать на один и тот же объект. А обыкновенные пользователи, к чему в частности и подвигает нас сама статья, может понятия не иметь что в инете одно и тоже могут назвать по разному и искать нужно по другому. Одна из идей статьи это уменьшит энтропию т.е. навести порядок и уменьшить время поиска, а так мы получаем те же «яйца» только в профиль.

        А всякие ухищрения в виде общяка и советов это не решение проблемы. Вспомнилась фраза Хауса — «Все врут».
        • 0
          Ну, насчет продвинутых и нет — в жизни всегда так, пассивное большинство пользуется плодами работы активного меньшинства. Будет достаточно, если всего несколько процентов людей будут хоть изредка помогать сети навести порядок. «Все врут» тут не применимо, потому что у Хауса в сериале всякие драмы и трагедии заставляют пациентов врать. А тут абсолютно обыденные вещи. Врать будут только патологические вандалы или материально заинтересованные (спамеры). Это, конечно, проблема, но она есть и сейчас, и с ней, хоть и не всегда успешно, справляются.

          Но у меня еще другая мысль родилась вчера перед сном. В отличие от таких вещей, как распознавание образов, поиск дубликатов фильма в любых разрешениях и с разными переводами может быть вполне тривиальной задачей для компьютера. Последовательность монтажных склеек, там где картинка меняется очень резко, и где кодеки обычно вынуждены вставлять полный ключевой кадр, легко распознается компьютером и является уникальной для каждого фильма. То есть если в двух разных файлах совпадают длинные последовательности интервалов между склейками — то с большой вероятностью можно утверждать, что это один и тот же фильм. Не может быть, чтобы до меня никто до этого не додумался — надо будет погуглить…
          • 0
            Тут есть один нюанс: есть множество кодеков, используемых для сжатия как видео- так и аудиопотоков.

            Ну, допустим, ключевой кадр получен. А как соотнести подобный ключевой кадр с другим ключевым кадром при другом разрешении, например?

            И как быть со звуковыми потоками (коих, кстати, может быть больше одного)?
            • 0
              Да не надо ничего соотносить, в том и фишка — мы преобразуем видеопоток в последовательность чисел, которые обозначают интервал между двумя склейками. Создаем как бы «монтажный лист» файла, который вообще никак не зависит от разрешения, звука, кодека… Сравниваем не кадры, а последовательности цифр.
            • 0
              Вот, уже нашёл что-то — teemoon.name/videoid/
            • 0
              И ещё:

              www.copymotion.com/video_matching_algorithm.php

              Копирасты, оказывается, такими штуками Youtube сканят.
      • 0
        Варк отличная штука, как-то я совсем упустил из виду.
        Благодарю за невольное напоминание!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.