Пользователь
0,0
рейтинг
16 сентября 2013 в 18:18

Разработка → Рождение магии от духа протокола торрент (cхема организации свободной бесцензурной неразрушимой информационной сети) из песочницы

Постановка задачи

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

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

Вариант сети передачи данных с распределенным источником — всем нам знакомый протокол торрент. Ясно, однако, что он разрабатывался под узкую цель передачи файлов и не позволяет построить полную и самодостаточную систему.

Я предлагаю схему создания такой системы, отталкиваясь от принципа функционирования торрентов.

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

Ключом к ее решению является организация распределенной и децентрализованной системы адресации.

Распределенная децентрализованная система адресации

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

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

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

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

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

Публикация предоставляет второй, косвенный тип адресации атома — через адрес публикации и внутренний адрес, способ построения которого задается форматом публикации.

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

Теперь наша децентрализованная распределенная система адресации практически завершена. Можно назвать ее SRDS (self-representing distributed addressing system). Она отличается тем, что в ней адресуются (специальным образом подготовленные) блоки информации, которые определяются своим содержанием — и более ничем. Содержание каждого атома однозначно соответствует своему адресу и может иметь сколько угодно копий. Принадлежность каждого атома владельцу определенного ключа (издателю) тоже однозначно определяется его содержанием.

Протокол распространения информации Magic Torrent

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

О каких адресах здесь идет речь? Я полагаю, желательно реализовать мультипротокольную работу — т. е. любой участник может присутствовать в системе под тем адресом, под которым ему удобнее, используя либо обычный цифровой TCP-адрес, либо, при желании, адрес в сети tor, i2p и так далее. Первым реализуемым протоколом обмена, ИМХО, разумнее всего сделать https.

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

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

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

Назовем такую систему организации доступа к ресурсам SRDS — протоколом Magic Torrent.



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

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

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

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

Преимущества и применение

Достоинства и недостатки описанной организации, в принципе, очевидны. Она обеспечивает легкое создание ресурсов, возможность бесплатного хранения информации на общественных началах, легкое и естественное масштабирование, а равно, при необходимости, и дупликацию, если возникнет необходимость воспроизвести содержание информационной системы в частично изолированном по техническим (альтернативные протоколы, альтернативные сети), физическим (скажем, на других планетах Солнечной системы) или юридическим причинам сегменте Интернета. Протокол Magic Torrent может быть использован для резервных каналов вещания, устойчивых к ddos-атакам. Адресация SRDS идеально подходит для реализации давней идеи распределенных блогов, и вообще для организации сетевых проектов, судьбу которых нежелательно доверять произволу проприетарного провайдера услуги (скажем, фрилансерских бирж). Но, очевидно, прежде всего напрашивается решение использовать ее для создания сетевых библиотек.

Предложенная система не является альтернативой анонимным сетям — она может дополнить их, при необходимости использовать их возможности, а им предоставить естественный мост для создания общего пространства с традиционным интернетом.

Основной проблемой является необходимость реализации с нуля всех предложенных протоколов и программ — клиентов и серверов сидов, нод и супернод. Отдельной большой темой является организация метафайлов и атомов, способы навигации и просмотра, удобные для работы в Magic Torrent. «Связующей» технологией в обычном вебе является html – но для наших нужд его придется ограничить, модифицировать или чем-то заменить.

Дисклеймер:
1) Насколько мне известно, предложенная мной система принципиально отличается от множества существующих или разрабатываемых, но на полную осведомленность я не претендую и гарантии дать не могу. Если кто-то ткнет пальцем и скажет — «вот то же самое» — думаю, нужно обратить всеобщее внимание на такой проект, потому что он заслуживает большей известности.
2) Ни намерения, ни возможности, ни квалификации реализовывать изложенные идеи у меня нет.

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

ЭЦП
@alexandrli
карма
14,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

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

  • 0
    К сожалению, наличие «единой точки отказа» — критичный момент для такой системы.
    • 0
      Да, именно. Потому-то я и придумывал такую систему, в которой ее не должно быть. Что Вы считаете «единой точкой отказа»?
      • 0
        «Суперноду», конечно.

        Хотя, после более внимательного прочтения понял что не все так плохо. Нужно только внедрить в «суперноду» систему саморегулирования сообществами и может получится вполне неплохо.
        • 0
          Да, я так и предлагаю сделать.
          Кроме того, супернода — это не один компьютер, а кольцо — некоторое количество компьютеров, содержащих идентичные копии актуальной информации. Вывод из сети одного из них на функционировании сети никак не скажется. Я думаю, при аккуратном проектировании протокола обмена — не скажется даже злоумышленный перехват управления.
          • 0
            Как я понимаю, главная проблема такой конфигурации — спам, которым можно забить все мощности «суперноды»?
            • 0
              Да, потому и предлагается на входе к супернодам ставить систему модерации.
              • 0
                Что-бы контент отмодерировать — он уже должен попасть в суперноду. Тут есть некий замкнутый круг.
                • 0
                  ИМХО, нет. Взаимодействие между участниками сети при передаче атомов идет по обычным протоколам. Т.е. издатель должен только получить через адрес SRDN (или иначе) контакт модератора (е-мейл, IM, сайт в обычном интернете с контактной формой и т.д.) и этим способом ему передать файл публикации. Модератор подписывает файл и передает его суперноде.
                  • 0
                    Очень плохо что в системе будут «особые люди». Очень.
                    • 0
                      Я долго думал, как обойтись без них. Пока не вижу способа.
                      Насколько я знаю, они везде так или иначе есть.
                      Кроме того, не предполагается, что эти «особые люди» получают власть над системой через протокол. Любая группа юзеров может организовать кольцо супернод. Так же, как в обычном интернете любая фирма может создать поисковую систему. Но пользоваться реально будут скорее всего двумя-тремя.
                      • 0
                        Особых людей нет например в i2p
                        • +1
                          Я, возможно, ошибаюсь — но, насколько я понимаю, владельцы серверов имен в i2p являются примерно такими же особенными людьми, как в предлагаемой мной схеме владельцы супернод.
                          • 0
                            Вам никто не мешает создать свой сервер имён или вообще не пользоваться ими, записывая у себя соответствия самостоятельно.
                            • 0
                              И в предложенном варианте никто не мешает создать свою суперноду или вообще не пользоваться ими — самостоятельно хранить адреса нодов и пиров.
                    • 0
                      PS Модерация введена для полноты и гарантированной устойчивости. Для начала можно было бы вместо нее использовать простейшие ограничения — например, не принимать публикаций с одного ip чаще, чем раз-два в час и удалять через некоторое время публикации, которые никто не раздает и не качает.

                      Но серьезную спамерускую атаку подобная система, конечно, не выдержит — когда она столкнется с такой проблемой, придется вводить ручную или полуручную модерацию.
                      • 0
                        «не принимать публикаций с одного ip чаще, чем раз-два в час и удалять через некоторое время публикации, которые никто не раздает и не качает»

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

                          Хотя детали этого процесса я не во всех отношениях продумал.
                      • 0
                        Вместо модерации можно ввести namecoin — контейнера:
                        новый пользователь загружает софт и подключается к сети в read-only mode, одновременно запуская майнер. Когда пользователь намайнит коин, он публикует его со своим публичным ключом контейнера и может публиковаться, подписывая публикации этим ключом. База коинов есть на каждой ноде и получая атом, они проверяют квоту контейнера. В результате флуд потребует значительных вычислительных мощностей. Единственная проблема: флуд может затруднить регистрацию новых пользователей.
                        • 0
                          Да, спасибо большое. Отличная мысль.
                          Поскольку единственная цель этих ограничений — защита кольца супернод от перегрузки, я полагаю, можно спокойно сочетать оба механизма — для желающих применять модерацию, для желающих — namecoin
              • 0
                А кто модерировать будет?
                • 0
                  Модерировать будут участники, уполномоченные супернодами. При создании кольца супернод им нужно будет согласовать порядок модерации.

                  В комментариях предложили другой вариант: вместо модерации можно ввести namecoin — контейнер.

                  Можно использовать одновременно ту и другую схему.
  • 0
    да, непонятно, чем это отличается от схемы DNS. Я бы задумался над распределенной поисковой системой, так как традиционная адресация уже не очень актуальна и порождает только, по сути, ту самую «единую точку отказа» — корневыве DNSы
    • +1
      У описанной системы адресации с ДНС нет ничего общего. Адрес ресурса создается генерацией пары ключей, и никакой авторитетный держатель ему не нужен.

      Если Вы видите сходство с ДНС в кольце супернод — у него больше общего с торрент-трекером, чем с ДНС.
      • –1
        Так торрент-трекер и есть «точка отказа», из-за чего и все споры сейчас.
        Но я к тому, что ИМХО актуальнее сейчас наладить распределенный поиск чем адресацию. Мало кто вбивает уже адрес, все спрашивают у надмозгов.
        • 0
          Торрент-трекер — да, а кольцо супернод — нет. Его можно вообще изьять и восстановить заново путем обратной передачи информации с нод на суперноды. Из него можно убрать любой узел — система этого даже не заметит.

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

            DNS действует точно также ))
            • 0
              Тогда вопрос — что произойдет, если безвозвратно уничтожить записи днс у регистраторов доменов?
          • +1
            И как будут резолвиться адреса, после изъятия кольца супернод? Вот я простой пользователь, установил какую-то софтину, в ней были забиты какие-то адреса супернод. Работаю, всё хорошо, но внезапно кольцо блокирует РКН. Откуда я получу новые адреса супернод?
            • 0
              а) блокировать кольцо РКН будет достаточно сложно — это ведь даже не нефиксированное множество IP, у супернод должны быть адреса еще и в анонимных сетях
              б) я полагаю, так: все пиры могут обмениваться информацией о нодах и супернодах, с которыми они работают. Допустим, у нас блокированы или уничтожены все суперноды. Кто-то желающий запускает новый сервер суперноды. Сообщает об этом всем своим пирам. Они передают ему метафайлы всех публикаций, с которыми они работают. (Клиенты делают это в автоматическом режиме, скажем, по факту прекращения работы всех известных им супернод). Далее они сообщают всем своим пирам адрес новой суперноды. Те подключаются к ней и проделывают то же самое.
              Если несколько человек запустили суперноду независимо — они устанавливают контакт и запускают кольцо, если согласны работать вместе. Если не согласны — формируют несколько колец.
              В новое кольцо принимаются метафайлы, подписанные теми же модераторами, которые были в старом. На будущее члены нового кольца могут назначить своих модераторов.
              • 0
                а) причем тут адреса в анонимных сетях, если заблокируют трафик суперноды? Она и от анонимной сети будет отрезана.

                б) не факт, что до конкретного хоста дойдёт информация о новой суперноде. Ему другие узлы в сети могут быть вообще неизвестны.
                • 0
                  а) каким образом? если супернода в РФ и отключена от сети совсем (или не в РФ и уничтожена) — то она, да, будет отрезана и от анонимной сети
                  б) при работе в обычном торренте очень быстро естественным образом образуется база из сотен пиров, так и здесь будет; как-то очень маловероятно, что при таком уровне связности информация о новой суперноде до какого-то сегмента принципиально не дойдет
                  в) если уж шит хеппенд и такое произошло — у пира возникает проблема, аналогичная первоначальному подключению к Magic Torrent сети. Ясно, что в ней должны быть средства, чтобы сообщить новичку адрес какой-то суперноды. Простейший вариант — публиковать их в других сетях (в обычном интернете, в анонимных сетях).
                  • 0
                    а) именно, трафик до суперноды блокируется любой (или этой сети, если он детектится по сигнатурам, хэндшэйпу и т. п.). Да и не ограничиваются блокировки РФ.
                    б) мы заходим на конкретный треккер, который сообщает нам о пирах. Блокируют треккер — инфы о пирах нет.
                    в) противодействие злонамеренным супернодам? ФСБ или АНБ решат создать свои и заспамят списки. Что делать?
                    • 0
                      а) против бейсбольной биты никакая защита не устоит
                      б) учтите еще, что ноды и суперноды, как и любые участники сети, идентифицируются не по ip, а по своей подписи, поэтому они могут ip менять хоть каждый час
                      в) ну создадут, допустим — какие проблемы при этом возникнут? Они могут создать альтернативный Гугль или Яндекс… это сильно затруднит возможности поиска в обычном интернете? И здесь то же самое. Если кольцо супернод работает — оно работает. Если не работает — им никто не пользуется.
                    • 0
                      Ваши вопросы побудили меня придумать полезное дополнение. В клиенте (нижнего уровня, т.е. сидера) нужно предусмотреть опцию выполнения транзитных запросов к супернодам и нодам. Т.о. — допустим, некая страна блокировала доступ ко всем супернодам. Личер в этой стране обнаруживает, что ему к ним не простучаться. Но ему достаточно найти любого пира, у которого включена эта опция и стоит сигнал, что ему суперноды доступны. Вуаля! — никакая блокировка доступа более невозможна, сработает только физическое отключение ВСЕХ супернод (и арест всех их владельцев, каждый из которых, напоминаю, может, сохранив владение своим ключом, легко запустить новую инкарнацию своей суперноды на другом компьютере).
        • 0
          Что касается поиска. Задача поиска для этой сети неспецифична — конечно, нужен поиск; его можно совмещать с системой супернод, можно делать на отдельных ресурсах в этой же сети.

          Преимущество предложенной адресации в том, что она привязана ТОЛЬКО к содержимому информации, поэтому может использоваться как универсальная для объединения любых сетей. Не обязательно организовывать доступ по описанной схеме Magic Torrent. Можно, например, разместить SRDS-ресурсы на обычном сайте в обычном интернете — потребуется только сервер, который будет выдавать контент по SRDS-запросам.
          • 0
            DHT?
            • 0
              Фактически да. Но у меня спроектирована полная система — с ресурсами и атомами внутри этих ресурсов. DHT, насколько я знаю, адресует только сами файлы, и полную сеть на его основе не построить.
              • +1
                DHT в µTorrent действительно адресует только файлы, однако возможности механизма Kademlia, на котором она построена, существенно шире.

                В частности, файлообменная сеть Kad, реализованная в файлообменной программе eMule (которая до сих пор невозбранно работает на компьютерах её любителей, хотя торрентовый файлообмен очень существенно потеснил её за счёт перехвата популярности), имеет возможность внутрисетевого поиска (Koncopd осветил этот вопрос во блогозаписи «Как работает поиск в Kad Network» 22 июля 2013 года — менее двух месяцев тому назад), то есть умеет адресовать и ключевые слова, а не только файлы.

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

                Кольца супернод не нужны — или, во всяком случае, нужность их определяется не необходимостью поиска.
                • 0
                  Спасибо, это интересно, я не знал об этом. Но это другая архитектура, далекая от предложенной здесь.
                  Не подскажете:
                  а) позволяет ли Kademlia создавать ресурсы, как совокупность адресуемых единиц, заведомо принадлежащих одному участнику сети и только ему?
                  б) есть ли в ней механизмы для борьбы с поисковым спамом?
                  Что касается кольца супернод, это просто один из возможных вариантов (ИМХО, самый простой и быстрый) отстроить доступ к ресурсам SRDS. При желании можно использовать другие — например, сделать распределенную таблицу для их поиска.
                  • 0
                    Можно использовать несколько вариантов одновременно. В предложенной схеме сами по себе ресурсы (адресация) абсолютно независимы и самодостаточны и не зависят от системы, обеспечивающей к ним доступ. Что и позволяет делать ее по обратному принципу: участники сети фактически просто заявляют — я раздаю такой-то ресурс, они, в общем, не нуждаются в каком-то авторитете, подтверждающем, что они действительно раздают именно его. Суперноды и ноды — только техническое средство их быстро найти.
                  • –1
                    Позволяет ли Kademlia создавать ресурсы, как совокупность адресуемых единиц, заведомо принадлежащих одному участнику сети и только ему?
                    Насколько я понял, в Вашей идее для этого предусмотрен отдельный механизм, а именно подписывание ресурса электронною подписью автора.

                    Я не вижу тех причин, по которым в Kademlia этот механизм стал бы работать хуже, чем в иерархии с центральным кольцом супернод.

                    Вообще задача публикации (распространения) и задача указания авторства не зависят друг от друга, если только специально не связывать их (например, не возлагать на кольцо супернод одновременно ещё и функции авторизационных центров, подписывающих чужие электронные подписи). А это последнее, я думаю, вовсе не обязательно; единожды встретив чей-либо открытый ключ, впредь можно ведь считать принадлежащим тому же автору и все прочие публикации, подписанные его закрытым ключом.
                    • 0
                      А если закрытый ключ скомпроментирован? В централизованной системе существуют процедуры отзыва.
                      • 0
                        Я хочу вместо процедуры отзыва использовать процедуру форка. Каждый может форкнуть чужой ресурс по какой-то публикации. Если Вы обнаружили, что с Вашим любимым сайтом что-то не так — Вы смотрите, какие у него есть форки.

                        Кто-то может в инициативном порядке делать обзорную базу таких форков: какие были причины, какие основания считать ключ скомпрометированным и т.д.

                        Это позволяет сохранить сеть децентрализованной и анархической на уровне адресации.
                        • 0
                          Я обнаружил, что с моим сайтом что-то не так, что по сети распространяются материалы якобы подписанные мною. Мои действия? Что мне надо сделать, чтобы народ не считал эти материалы моими?
                          • 0
                            А как могут по сети распростряняться материалы, подписанные Вашим ключом, если у Вас его не украли?
                            • 0
                              Так у меня его украли (или иным способом получили способ подписывать материалы от моего имени — например, удаленный доступ — сам ключ неизвестен, но подписать могут). Чо мне делать в этой ситуации?
                              • 0
                                Делаете форк. В метаинформации форка записываете: так и так, украли ключ, доказательства лежат там-то (ну, например, Ваши друзья заявляют от своего имени, что у Вас действительно украли ключ). Мой новый ключ такой-то.

                                Верить Вам или не верить — каждый читатель сам будет решать.
                                • 0
                                  Какова вероятность, что наткнутся на мой форк, подписанный моим новым ключом, а не на оригинал?
                                  • 0
                                    Случайно? Нулевая. Форк поможет, если читатель заподозрил, что что-то не так.

                                    ИМХО, проблему компрометации ключей МОЖНО решить, если накрутить еще пару сервисов и протоколов, но у меня сомнения, что это решение будет востребовано.
                                    • 0
                                      Форк поможет, если читатель заподозрил, что что-то не так.

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

                    Поэтому сообщу только, что Koncopd в июле огласил, что некоторые сведения о защите об атак содержатся в статье Stefan Schmid, Thomas Locher «When KAD meets BitTorrent — Building a Stronger P2P Network».
  • 0
    неразрушимость достигается ценой существенного снижения быстродействия сети, так получается?
    • 0
      Ну, как получится, но вряд ли три прямых запроса, необходимые, чтобы пройти по ссылке (супернода, нода, сид) должны занять много времени. Существующие анонимные сети в этом отношении, насколько я знаю, намного прожорливее.
  • 0
    Кстати, в копилку общую: красивым развитием идеи вижу «распределенный CDN», когда контент забирается из кэшей браузеров пользователей по принципу того же торрента…
    • 0
      • 0
        спасибо, не знал. Но там нет поиска…
        • –1
          А в каких существующих CDN есть поиск?
  • +1
    Следующая потенциальная слабость после атаки на суперноду будет связан с актуальностью информации.
    Для поддержания и распространения актуальной информации рано или поздно придётся ввести понятие версии, что потянет за собой ограниченный список издателей, подписи — и мы возвращаемся к https.
    • 0
      В статье затронут вопрос актуальности информации и введено понятие версии. Подписи же, если посмотрите, там тоже предусматриваются и имеют фундаментальное значение. С версиями предлагается работать через файлы публикаций: в них должна быть, помимо прочей, информация о том, какие атомы являются новыми версиями ранее введенных в систему. Также должна быть информация о порядке версии самого файла публикации. Поскольку файлы публикаций подписываются издателем так же, как и все остальные атомы, надобности ограничивать список издателей при этом не возникает.

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

  • 0
    > свободной бесцензурной неразрушимой
    Количество эпитетов заставляет усомниться в возможности реализации этой идеи…
    • +1
      Сомнения — вещь полезная, особенно когда они приводят к появлению конкретных аргументов. Схему я постарался изложить по возможности полно, это не просто постановка задачи, но и план ее решения. Если Вы видите какие-то уязвимости или нереализуемые моменты — я буду очень признателен, если Вы их укажете.
  • 0
    Со статическим контентом более-менее понятно. Но что делать с динамическим?
    • 0
      Это вопрос интересный и я его до конца не проработал.
      Принципиально подход может быть следующим: умеренная динамика обеспечивается созданием новых публикаций. Если у Вас контент меняется раз в несколько часов — этого достаточно.
      Если же мы хотим создать, скажем, социальную сеть, в которой комментарии появляются каждую секунду и ждать часы, чтобы их прочитать, не хочется — можно поступить примерно следующим образом:
      — создавать метафайл публикации (сложного формата) для всей сети разом
      — хранить его только на уровне нод
      — на уровне суперноды хранить только информацию об уполномоченных модераторах этой сети, которые могут подписывать метафайл публикации, и о времени его последнего обновления (а ноды подают на суперноду информацию о времени последнего обновления файла у каждой из них)
      — читатель обращается к одной из тех нод, время последнего обновления у которых достаточно близко к текущему
      — видимо, чтобы не грузить суперноды общего назначения, нужно будет ввести промежуточный уровень супернод специально для этой социальной сети
      — запросив эту информацию, пир обращается к одной из тех нод,
      • 0
        сбой какой-то
      • 0
        Мне кажется не стоит сразу решить все возможные задачи. Решение для публикации редко изменяемых данных удовлетворит явно больше 80% потребностей.
        А комментарии можно добавлять и через другой протокол, как сейчас это делается через disqus, parse и пр.
        • 0
          Да, Вы правы. Но социальные сети — очень соблазнительный объект для реализации через распределенный протокол.
          • 0
            Ну и http/html в начале не предназначались для создания соцсетей, однако смогли сделать соцсети и на этой основе. Главное дать простой базис. Очень простой.
            А еще был fido, кстати, который сразу был распределенной соцсетью.
        • 0
          Но эти 20% нужны 80% пользователям, которым анонимная распределенная сеть нужна не для того, чтобы авторские права нарушать безнаказанно, а, скажем, критиковать правительство без страха за личную безопасность.
          • 0
            Не факт. И не совсем понятно чем этих товарищей не устраивает tor/i2p?
  • 0
    Правильно ли я понял, что эту сеть предполагается строить поверх Интернета (т.е., используя существующие TCP\IP соединения)? Если так, то это сильно уменьшает ценность сети…

    Предлагаю взглянуть на Hyperboria – оно уже в какой-то степени работает и нуждается в разработчиках.
    • 0
      а) Ее можно строить поверх чего угодно. SRDS-адреса привязаны непосредственно к данным, совершенно неважно, где физически и в какой сети эти данные расположены. Можно хоть на бумажке напечатать.
      В идеале Magic Torrent должен работать так: сид сообщает городу и миру, что у него есть такой-то (адрес в SRDS) атом по такому-то адресу (в любой работающей транспортной сети: хоть TCP/IP, хоть p2p, хоть onion и т.д.) Лич получает эту информацию, смотрит, есть ли у него в клиенте этот транспортный протокол, если есть — запрашивает атом. Если нет — ищет другого сида.
      б) Я понимаю, это нескромно — говорить «уж лучше Вы к нам»… Но я смотрел Hyperboria. Там есть ряд вещей, которые я не понимаю… но суть не в этом. Моя архитектура имеет другие достоинства и недостатки. Про Hyperboria говорится: «Сейчас выбираются программные движки для создания следующих сервисов:
      1) Децентрализованный DNS (скорее всего namecoin / P2P DNS)
      2) Децентрализованный файловый хостинг (Скорее всего TAHOE-LAFS)
      3) Децентрализованная социальная сеть».
      Почему бы не использовать как вариант мою схему? Адресация SRDS делает децентрализованный DNS ненужным (и все проблемы, связанные с ним, неактуальными). Транспорт Magic Torrent будет хорошей альтернативой децентрализованному файловому хостингу: он дает простое и естественное распределенное хранение, при этом не возникает проблемы распределения ресурсов, из-за которой всякий децентрализованный файловый хостинг нуждается в централизованном управлении — квотами и пр.)
      • 0
        А предложите свою концепцию сообществу cjdns, кстати!
        • 0
          А Вы к нему не принадлежите? Может, посодействуете? Если нет — да, попробую сам.
          • 0
            Это же open source, всё открыто :) Я даже затрудняюсь сказать, куда лучше стучать, чтоб обсудить идею… Либо в IRC-чатик, либо попробовать на socialno.de (доступно только из Hyperboria). Ну или на wiki проекта страничку создать.
            • 0
              На форум (http://cjdns.ru/forum/), может быть, написать? Увы, переводить статью на английский и обсуждать на нем — я не потяну.
              • 0
                На этом форуме там просто «интересующиеся», скажем так. Я вот написал небольшую админку для cjdns, но не более. А обсуждать надо, видимо, с каким-то идеологами проекта, естественно, на английском.
                • 0
                  Значит, не судьба пока.
  • 0
    По описанию частично похоже на Osiris-SPS и RetroShare
    • 0
      Да, спасибо, действительно рядом деталей похоже.
      Но я ставил более глобальную задачу — ИМХО, то, что я предлагаю, удобно было бы использовать для построения универсальной сети обмена информацией, через границы несовместимых протоколов и проектов.
      • 0
        Проблема только в реализации идеи. И это действительно проблема. Придумать можно практически что угодно, а вот технически реализовать, да ещё и с таким широким набором параметров — это сложно.

        Мой собственный опыт подсказывает, что проще использовать уже работающие решения (тем более, что и они не стоят на месте и развиваются).

        Тот же Retroshare, например. Но у меня, как у интерфейсника, есть огромное желание его как минимум заредизайнить. То, как там всё устроено сейчас, вызывает желание задать пустоте кучу вопросов, типа: «О, ну зачем это всё так?».

        А в целом, да. Одобряю и поддерживаю.

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