Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 82
К сожалению, наличие «единой точки отказа» — критичный момент для такой системы.
Да, именно. Потому-то я и придумывал такую систему, в которой ее не должно быть. Что Вы считаете «единой точкой отказа»?
«Суперноду», конечно.
Хотя, после более внимательного прочтения понял что не все так плохо. Нужно только внедрить в «суперноду» систему саморегулирования сообществами и может получится вполне неплохо.
Хотя, после более внимательного прочтения понял что не все так плохо. Нужно только внедрить в «суперноду» систему саморегулирования сообществами и может получится вполне неплохо.
Да, я так и предлагаю сделать.
Кроме того, супернода — это не один компьютер, а кольцо — некоторое количество компьютеров, содержащих идентичные копии актуальной информации. Вывод из сети одного из них на функционировании сети никак не скажется. Я думаю, при аккуратном проектировании протокола обмена — не скажется даже злоумышленный перехват управления.
Кроме того, супернода — это не один компьютер, а кольцо — некоторое количество компьютеров, содержащих идентичные копии актуальной информации. Вывод из сети одного из них на функционировании сети никак не скажется. Я думаю, при аккуратном проектировании протокола обмена — не скажется даже злоумышленный перехват управления.
Как я понимаю, главная проблема такой конфигурации — спам, которым можно забить все мощности «суперноды»?
Да, потому и предлагается на входе к супернодам ставить систему модерации.
Что-бы контент отмодерировать — он уже должен попасть в суперноду. Тут есть некий замкнутый круг.
ИМХО, нет. Взаимодействие между участниками сети при передаче атомов идет по обычным протоколам. Т.е. издатель должен только получить через адрес SRDN (или иначе) контакт модератора (е-мейл, IM, сайт в обычном интернете с контактной формой и т.д.) и этим способом ему передать файл публикации. Модератор подписывает файл и передает его суперноде.
Очень плохо что в системе будут «особые люди». Очень.
Я долго думал, как обойтись без них. Пока не вижу способа.
Насколько я знаю, они везде так или иначе есть.
Кроме того, не предполагается, что эти «особые люди» получают власть над системой через протокол. Любая группа юзеров может организовать кольцо супернод. Так же, как в обычном интернете любая фирма может создать поисковую систему. Но пользоваться реально будут скорее всего двумя-тремя.
Насколько я знаю, они везде так или иначе есть.
Кроме того, не предполагается, что эти «особые люди» получают власть над системой через протокол. Любая группа юзеров может организовать кольцо супернод. Так же, как в обычном интернете любая фирма может создать поисковую систему. Но пользоваться реально будут скорее всего двумя-тремя.
PS Модерация введена для полноты и гарантированной устойчивости. Для начала можно было бы вместо нее использовать простейшие ограничения — например, не принимать публикаций с одного ip чаще, чем раз-два в час и удалять через некоторое время публикации, которые никто не раздает и не качает.
Но серьезную спамерускую атаку подобная система, конечно, не выдержит — когда она столкнется с такой проблемой, придется вводить ручную или полуручную модерацию.
Но серьезную спамерускую атаку подобная система, конечно, не выдержит — когда она столкнется с такой проблемой, придется вводить ручную или полуручную модерацию.
«не принимать публикаций с одного ip чаще, чем раз-два в час и удалять через некоторое время публикации, которые никто не раздает и не качает»
Хорошая мысль. Но, такая защита, как вы и описали, будет срабатывать только если мощность атаки будет слабее мощности суперноды. Тем не менее, если суперноду сделать легко распределяемой и наращиваемой, этого может хватить.
Хорошая мысль. Но, такая защита, как вы и описали, будет срабатывать только если мощность атаки будет слабее мощности суперноды. Тем не менее, если суперноду сделать легко распределяемой и наращиваемой, этого может хватить.
Хочется, чтобы распределяемым был любой участник сети распространения — я предполагал, что любой участник должен отдавать в открытый доступ все, что необходимо для запуска функциональной копии данного участника. Форматы данных должны быть удобными для копирования и переноса.
Хотя детали этого процесса я не во всех отношениях продумал.
Хотя детали этого процесса я не во всех отношениях продумал.
Вместо модерации можно ввести namecoin — контейнера:
новый пользователь загружает софт и подключается к сети в read-only mode, одновременно запуская майнер. Когда пользователь намайнит коин, он публикует его со своим публичным ключом контейнера и может публиковаться, подписывая публикации этим ключом. База коинов есть на каждой ноде и получая атом, они проверяют квоту контейнера. В результате флуд потребует значительных вычислительных мощностей. Единственная проблема: флуд может затруднить регистрацию новых пользователей.
новый пользователь загружает софт и подключается к сети в read-only mode, одновременно запуская майнер. Когда пользователь намайнит коин, он публикует его со своим публичным ключом контейнера и может публиковаться, подписывая публикации этим ключом. База коинов есть на каждой ноде и получая атом, они проверяют квоту контейнера. В результате флуд потребует значительных вычислительных мощностей. Единственная проблема: флуд может затруднить регистрацию новых пользователей.
А кто модерировать будет?
да, непонятно, чем это отличается от схемы DNS. Я бы задумался над распределенной поисковой системой, так как традиционная адресация уже не очень актуальна и порождает только, по сути, ту самую «единую точку отказа» — корневыве DNSы
У описанной системы адресации с ДНС нет ничего общего. Адрес ресурса создается генерацией пары ключей, и никакой авторитетный держатель ему не нужен.
Если Вы видите сходство с ДНС в кольце супернод — у него больше общего с торрент-трекером, чем с ДНС.
Если Вы видите сходство с ДНС в кольце супернод — у него больше общего с торрент-трекером, чем с ДНС.
Так торрент-трекер и есть «точка отказа», из-за чего и все споры сейчас.
Но я к тому, что ИМХО актуальнее сейчас наладить распределенный поиск чем адресацию. Мало кто вбивает уже адрес, все спрашивают у надмозгов.
Но я к тому, что ИМХО актуальнее сейчас наладить распределенный поиск чем адресацию. Мало кто вбивает уже адрес, все спрашивают у надмозгов.
Торрент-трекер — да, а кольцо супернод — нет. Его можно вообще изьять и восстановить заново путем обратной передачи информации с нод на суперноды. Из него можно убрать любой узел — система этого даже не заметит.
Кроме того, не предполагается, что кольцо супернод должно быть единственным. Ресурс может подавать информацию на любое из существующих или на все разом.
Кроме того, не предполагается, что кольцо супернод должно быть единственным. Ресурс может подавать информацию на любое из существующих или на все разом.
. Его можно вообще изьять и восстановить заново путем обратной передачи информации с нод на суперноды.
DNS действует точно также ))
И как будут резолвиться адреса, после изъятия кольца супернод? Вот я простой пользователь, установил какую-то софтину, в ней были забиты какие-то адреса супернод. Работаю, всё хорошо, но внезапно кольцо блокирует РКН. Откуда я получу новые адреса супернод?
а) блокировать кольцо РКН будет достаточно сложно — это ведь даже не нефиксированное множество IP, у супернод должны быть адреса еще и в анонимных сетях
б) я полагаю, так: все пиры могут обмениваться информацией о нодах и супернодах, с которыми они работают. Допустим, у нас блокированы или уничтожены все суперноды. Кто-то желающий запускает новый сервер суперноды. Сообщает об этом всем своим пирам. Они передают ему метафайлы всех публикаций, с которыми они работают. (Клиенты делают это в автоматическом режиме, скажем, по факту прекращения работы всех известных им супернод). Далее они сообщают всем своим пирам адрес новой суперноды. Те подключаются к ней и проделывают то же самое.
Если несколько человек запустили суперноду независимо — они устанавливают контакт и запускают кольцо, если согласны работать вместе. Если не согласны — формируют несколько колец.
В новое кольцо принимаются метафайлы, подписанные теми же модераторами, которые были в старом. На будущее члены нового кольца могут назначить своих модераторов.
б) я полагаю, так: все пиры могут обмениваться информацией о нодах и супернодах, с которыми они работают. Допустим, у нас блокированы или уничтожены все суперноды. Кто-то желающий запускает новый сервер суперноды. Сообщает об этом всем своим пирам. Они передают ему метафайлы всех публикаций, с которыми они работают. (Клиенты делают это в автоматическом режиме, скажем, по факту прекращения работы всех известных им супернод). Далее они сообщают всем своим пирам адрес новой суперноды. Те подключаются к ней и проделывают то же самое.
Если несколько человек запустили суперноду независимо — они устанавливают контакт и запускают кольцо, если согласны работать вместе. Если не согласны — формируют несколько колец.
В новое кольцо принимаются метафайлы, подписанные теми же модераторами, которые были в старом. На будущее члены нового кольца могут назначить своих модераторов.
а) причем тут адреса в анонимных сетях, если заблокируют трафик суперноды? Она и от анонимной сети будет отрезана.
б) не факт, что до конкретного хоста дойдёт информация о новой суперноде. Ему другие узлы в сети могут быть вообще неизвестны.
б) не факт, что до конкретного хоста дойдёт информация о новой суперноде. Ему другие узлы в сети могут быть вообще неизвестны.
а) каким образом? если супернода в РФ и отключена от сети совсем (или не в РФ и уничтожена) — то она, да, будет отрезана и от анонимной сети
б) при работе в обычном торренте очень быстро естественным образом образуется база из сотен пиров, так и здесь будет; как-то очень маловероятно, что при таком уровне связности информация о новой суперноде до какого-то сегмента принципиально не дойдет
в) если уж шит хеппенд и такое произошло — у пира возникает проблема, аналогичная первоначальному подключению к Magic Torrent сети. Ясно, что в ней должны быть средства, чтобы сообщить новичку адрес какой-то суперноды. Простейший вариант — публиковать их в других сетях (в обычном интернете, в анонимных сетях).
б) при работе в обычном торренте очень быстро естественным образом образуется база из сотен пиров, так и здесь будет; как-то очень маловероятно, что при таком уровне связности информация о новой суперноде до какого-то сегмента принципиально не дойдет
в) если уж шит хеппенд и такое произошло — у пира возникает проблема, аналогичная первоначальному подключению к Magic Torrent сети. Ясно, что в ней должны быть средства, чтобы сообщить новичку адрес какой-то суперноды. Простейший вариант — публиковать их в других сетях (в обычном интернете, в анонимных сетях).
а) именно, трафик до суперноды блокируется любой (или этой сети, если он детектится по сигнатурам, хэндшэйпу и т. п.). Да и не ограничиваются блокировки РФ.
б) мы заходим на конкретный треккер, который сообщает нам о пирах. Блокируют треккер — инфы о пирах нет.
в) противодействие злонамеренным супернодам? ФСБ или АНБ решат создать свои и заспамят списки. Что делать?
б) мы заходим на конкретный треккер, который сообщает нам о пирах. Блокируют треккер — инфы о пирах нет.
в) противодействие злонамеренным супернодам? ФСБ или АНБ решат создать свои и заспамят списки. Что делать?
а) против бейсбольной биты никакая защита не устоит
б) учтите еще, что ноды и суперноды, как и любые участники сети, идентифицируются не по ip, а по своей подписи, поэтому они могут ip менять хоть каждый час
в) ну создадут, допустим — какие проблемы при этом возникнут? Они могут создать альтернативный Гугль или Яндекс… это сильно затруднит возможности поиска в обычном интернете? И здесь то же самое. Если кольцо супернод работает — оно работает. Если не работает — им никто не пользуется.
б) учтите еще, что ноды и суперноды, как и любые участники сети, идентифицируются не по ip, а по своей подписи, поэтому они могут ip менять хоть каждый час
в) ну создадут, допустим — какие проблемы при этом возникнут? Они могут создать альтернативный Гугль или Яндекс… это сильно затруднит возможности поиска в обычном интернете? И здесь то же самое. Если кольцо супернод работает — оно работает. Если не работает — им никто не пользуется.
Ваши вопросы побудили меня придумать полезное дополнение. В клиенте (нижнего уровня, т.е. сидера) нужно предусмотреть опцию выполнения транзитных запросов к супернодам и нодам. Т.о. — допустим, некая страна блокировала доступ ко всем супернодам. Личер в этой стране обнаруживает, что ему к ним не простучаться. Но ему достаточно найти любого пира, у которого включена эта опция и стоит сигнал, что ему суперноды доступны. Вуаля! — никакая блокировка доступа более невозможна, сработает только физическое отключение ВСЕХ супернод (и арест всех их владельцев, каждый из которых, напоминаю, может, сохранив владение своим ключом, легко запустить новую инкарнацию своей суперноды на другом компьютере).
Что касается поиска. Задача поиска для этой сети неспецифична — конечно, нужен поиск; его можно совмещать с системой супернод, можно делать на отдельных ресурсах в этой же сети.
Преимущество предложенной адресации в том, что она привязана ТОЛЬКО к содержимому информации, поэтому может использоваться как универсальная для объединения любых сетей. Не обязательно организовывать доступ по описанной схеме Magic Torrent. Можно, например, разместить SRDS-ресурсы на обычном сайте в обычном интернете — потребуется только сервер, который будет выдавать контент по SRDS-запросам.
Преимущество предложенной адресации в том, что она привязана ТОЛЬКО к содержимому информации, поэтому может использоваться как универсальная для объединения любых сетей. Не обязательно организовывать доступ по описанной схеме Magic Torrent. Можно, например, разместить SRDS-ресурсы на обычном сайте в обычном интернете — потребуется только сервер, который будет выдавать контент по SRDS-запросам.
DHT?
Фактически да. Но у меня спроектирована полная система — с ресурсами и атомами внутри этих ресурсов. DHT, насколько я знаю, адресует только сами файлы, и полную сеть на его основе не построить.
DHT в µTorrent действительно адресует только файлы, однако возможности механизма Kademlia, на котором она построена, существенно шире.
В частности, файлообменная сеть Kad, реализованная в файлообменной программе eMule (которая до сих пор невозбранно работает на компьютерах её любителей, хотя торрентовый файлообмен очень существенно потеснил её за счёт перехвата популярности), имеет возможность внутрисетевого поиска(Koncopd осветил этот вопрос во блогозаписи «Как работает поиск в Kad Network» 22 июля 2013 года — менее двух месяцев тому назад), то есть умеет адресовать и ключевые слова, а не только файлы.
Следовательно, и ресурсы, и атомы могут распределённо публиковаться в распределённой DHT и без того, чтобы формировать иерархию участников.
Кольца супернод не нужны —или, во всяком случае, нужность их определяется не необходимостью поиска.
В частности, файлообменная сеть Kad, реализованная в файлообменной программе eMule (которая до сих пор невозбранно работает на компьютерах её любителей, хотя торрентовый файлообмен очень существенно потеснил её за счёт перехвата популярности), имеет возможность внутрисетевого поиска
Следовательно, и ресурсы, и атомы могут распределённо публиковаться в распределённой DHT и без того, чтобы формировать иерархию участников.
Кольца супернод не нужны —
Спасибо, это интересно, я не знал об этом. Но это другая архитектура, далекая от предложенной здесь.
Не подскажете:
а) позволяет ли Kademlia создавать ресурсы, как совокупность адресуемых единиц, заведомо принадлежащих одному участнику сети и только ему?
б) есть ли в ней механизмы для борьбы с поисковым спамом?
Что касается кольца супернод, это просто один из возможных вариантов (ИМХО, самый простой и быстрый) отстроить доступ к ресурсам SRDS. При желании можно использовать другие — например, сделать распределенную таблицу для их поиска.
Не подскажете:
а) позволяет ли Kademlia создавать ресурсы, как совокупность адресуемых единиц, заведомо принадлежащих одному участнику сети и только ему?
б) есть ли в ней механизмы для борьбы с поисковым спамом?
Что касается кольца супернод, это просто один из возможных вариантов (ИМХО, самый простой и быстрый) отстроить доступ к ресурсам SRDS. При желании можно использовать другие — например, сделать распределенную таблицу для их поиска.
Можно использовать несколько вариантов одновременно. В предложенной схеме сами по себе ресурсы (адресация) абсолютно независимы и самодостаточны и не зависят от системы, обеспечивающей к ним доступ. Что и позволяет делать ее по обратному принципу: участники сети фактически просто заявляют — я раздаю такой-то ресурс, они, в общем, не нуждаются в каком-то авторитете, подтверждающем, что они действительно раздают именно его. Суперноды и ноды — только техническое средство их быстро найти.
Позволяет ли Kademlia создавать ресурсы, как совокупность адресуемых единиц, заведомо принадлежащих одному участнику сети и только ему?Насколько я понял, в Вашей идее для этого предусмотрен отдельный механизм, а именно подписывание ресурса электронною подписью автора.
Я не вижу тех причин, по которым в Kademlia этот механизм стал бы работать хуже, чем в иерархии с центральным кольцом супернод.
Вообще задача публикации (распространения) и задача указания авторства не зависят друг от друга, если только специально не связывать их (например, не возлагать на кольцо супернод одновременно ещё и функции авторизационных центров, подписывающих чужие электронные подписи). А это последнее, я думаю, вовсе не обязательно; единожды встретив
А если закрытый ключ скомпроментирован? В централизованной системе существуют процедуры отзыва.
Я хочу вместо процедуры отзыва использовать процедуру форка. Каждый может форкнуть чужой ресурс по какой-то публикации. Если Вы обнаружили, что с Вашим любимым сайтом что-то не так — Вы смотрите, какие у него есть форки.
Кто-то может в инициативном порядке делать обзорную базу таких форков: какие были причины, какие основания считать ключ скомпрометированным и т.д.
Это позволяет сохранить сеть децентрализованной и анархической на уровне адресации.
Кто-то может в инициативном порядке делать обзорную базу таких форков: какие были причины, какие основания считать ключ скомпрометированным и т.д.
Это позволяет сохранить сеть децентрализованной и анархической на уровне адресации.
Я обнаружил, что с моим сайтом что-то не так, что по сети распространяются материалы якобы подписанные мною. Мои действия? Что мне надо сделать, чтобы народ не считал эти материалы моими?
А как могут по сети распростряняться материалы, подписанные Вашим ключом, если у Вас его не украли?
Так у меня его украли (или иным способом получили способ подписывать материалы от моего имени — например, удаленный доступ — сам ключ неизвестен, но подписать могут). Чо мне делать в этой ситуации?
Делаете форк. В метаинформации форка записываете: так и так, украли ключ, доказательства лежат там-то (ну, например, Ваши друзья заявляют от своего имени, что у Вас действительно украли ключ). Мой новый ключ такой-то.
Верить Вам или не верить — каждый читатель сам будет решать.
Верить Вам или не верить — каждый читатель сам будет решать.
Какова вероятность, что наткнутся на мой форк, подписанный моим новым ключом, а не на оригинал?
Случайно? Нулевая. Форк поможет, если читатель заподозрил, что что-то не так.
ИМХО, проблему компрометации ключей МОЖНО решить, если накрутить еще пару сервисов и протоколов, но у меня сомнения, что это решение будет востребовано.
ИМХО, проблему компрометации ключей МОЖНО решить, если накрутить еще пару сервисов и протоколов, но у меня сомнения, что это решение будет востребовано.
Форк поможет, если читатель заподозрил, что что-то не так.
Большой недостаток коль скоро идентификация одна из основных функций.
Я бы сказал, что это неизбежная (и небольшая) цена за равенство прав участников.
Если у каких-то людей будет власть отозвать Ваш ключ — власть над Вашим ресурсом будет у них, а не у Вас. О бесцензурности в этом случае говорить не придется.
А так — храните ключ бережно. Для крупных проектов — о компрометации ключа неизбежно станет широко известно. Для мелких — ну, кому нужно ваш ключ красть?
Если у каких-то людей будет власть отозвать Ваш ключ — власть над Вашим ресурсом будет у них, а не у Вас. О бесцензурности в этом случае говорить не придется.
А так — храните ключ бережно. Для крупных проектов — о компрометации ключа неизбежно станет широко известно. Для мелких — ну, кому нужно ваш ключ красть?
«Насколько я понял, в Вашей идее для этого предусмотрен отдельный механизм, а именно подписывание ресурса электронною подписью автора.»
Да.
«А это последнее, я думаю, вовсе не обязательно; единожды встретив чей-либо открытый ключ, впредь можно ведь считать принадлежащим тому же автору и все прочие публикации, подписанные его закрытым ключом.»
Да, я именно так и предлагаю сделать.
Да.
«А это последнее, я думаю, вовсе не обязательно; единожды встретив чей-либо открытый ключ, впредь можно ведь считать принадлежащим тому же автору и все прочие публикации, подписанные его закрытым ключом.»
Да, я именно так и предлагаю сделать.
Есть ли в ней механизмы для борьбы с поисковым спамом?К сожалению, сам я не могу ещё с уверенностью ответить на этот вопрос.
Поэтому сообщу только,
неразрушимость достигается ценой существенного снижения быстродействия сети, так получается?
Кстати, в копилку общую: красивым развитием идеи вижу «распределенный CDN», когда контент забирается из кэшей браузеров пользователей по принципу того же торрента…
Следующая потенциальная слабость после атаки на суперноду будет связан с актуальностью информации.
Для поддержания и распространения актуальной информации рано или поздно придётся ввести понятие версии, что потянет за собой ограниченный список издателей, подписи — и мы возвращаемся к https.
Для поддержания и распространения актуальной информации рано или поздно придётся ввести понятие версии, что потянет за собой ограниченный список издателей, подписи — и мы возвращаемся к https.
В статье затронут вопрос актуальности информации и введено понятие версии. Подписи же, если посмотрите, там тоже предусматриваются и имеют фундаментальное значение. С версиями предлагается работать через файлы публикаций: в них должна быть, помимо прочей, информация о том, какие атомы являются новыми версиями ранее введенных в систему. Также должна быть информация о порядке версии самого файла публикации. Поскольку файлы публикаций подписываются издателем так же, как и все остальные атомы, надобности ограничивать список издателей при этом не возникает.
Возникает другая проблема: никто не гарантирует достоверности этой информации. Издатель может устанавливать порядок версий, как хочет.
Здесь предлагается следующий подход:
а) издатель — барин, его право
б) по записям супернод желающие могут установить реальный хронологический порядок появления файлов публикаций
в) если кому-то не нравится, что делает с ресурсом его издатель (или злоумышленник, завладевший его ключом) — он может сделать форк ресурса на какой-то момент времени, подписать его своим ключом поверх (т.е. с сохранением и старой подписи) и распространять именно как копию чужого ресурса.
Возникает другая проблема: никто не гарантирует достоверности этой информации. Издатель может устанавливать порядок версий, как хочет.
Здесь предлагается следующий подход:
а) издатель — барин, его право
б) по записям супернод желающие могут установить реальный хронологический порядок появления файлов публикаций
в) если кому-то не нравится, что делает с ресурсом его издатель (или злоумышленник, завладевший его ключом) — он может сделать форк ресурса на какой-то момент времени, подписать его своим ключом поверх (т.е. с сохранением и старой подписи) и распространять именно как копию чужого ресурса.
> свободной бесцензурной неразрушимой
Количество эпитетов заставляет усомниться в возможности реализации этой идеи…
Количество эпитетов заставляет усомниться в возможности реализации этой идеи…
Сомнения — вещь полезная, особенно когда они приводят к появлению конкретных аргументов. Схему я постарался изложить по возможности полно, это не просто постановка задачи, но и план ее решения. Если Вы видите какие-то уязвимости или нереализуемые моменты — я буду очень признателен, если Вы их укажете.
Со статическим контентом более-менее понятно. Но что делать с динамическим?
Это вопрос интересный и я его до конца не проработал.
Принципиально подход может быть следующим: умеренная динамика обеспечивается созданием новых публикаций. Если у Вас контент меняется раз в несколько часов — этого достаточно.
Если же мы хотим создать, скажем, социальную сеть, в которой комментарии появляются каждую секунду и ждать часы, чтобы их прочитать, не хочется — можно поступить примерно следующим образом:
— создавать метафайл публикации (сложного формата) для всей сети разом
— хранить его только на уровне нод
— на уровне суперноды хранить только информацию об уполномоченных модераторах этой сети, которые могут подписывать метафайл публикации, и о времени его последнего обновления (а ноды подают на суперноду информацию о времени последнего обновления файла у каждой из них)
— читатель обращается к одной из тех нод, время последнего обновления у которых достаточно близко к текущему
— видимо, чтобы не грузить суперноды общего назначения, нужно будет ввести промежуточный уровень супернод специально для этой социальной сети
— запросив эту информацию, пир обращается к одной из тех нод,
Принципиально подход может быть следующим: умеренная динамика обеспечивается созданием новых публикаций. Если у Вас контент меняется раз в несколько часов — этого достаточно.
Если же мы хотим создать, скажем, социальную сеть, в которой комментарии появляются каждую секунду и ждать часы, чтобы их прочитать, не хочется — можно поступить примерно следующим образом:
— создавать метафайл публикации (сложного формата) для всей сети разом
— хранить его только на уровне нод
— на уровне суперноды хранить только информацию об уполномоченных модераторах этой сети, которые могут подписывать метафайл публикации, и о времени его последнего обновления (а ноды подают на суперноду информацию о времени последнего обновления файла у каждой из них)
— читатель обращается к одной из тех нод, время последнего обновления у которых достаточно близко к текущему
— видимо, чтобы не грузить суперноды общего назначения, нужно будет ввести промежуточный уровень супернод специально для этой социальной сети
— запросив эту информацию, пир обращается к одной из тех нод,
сбой какой-то
Мне кажется не стоит сразу решить все возможные задачи. Решение для публикации редко изменяемых данных удовлетворит явно больше 80% потребностей.
А комментарии можно добавлять и через другой протокол, как сейчас это делается через disqus, parse и пр.
А комментарии можно добавлять и через другой протокол, как сейчас это делается через disqus, parse и пр.
Да, Вы правы. Но социальные сети — очень соблазнительный объект для реализации через распределенный протокол.
Но эти 20% нужны 80% пользователям, которым анонимная распределенная сеть нужна не для того, чтобы авторские права нарушать безнаказанно, а, скажем, критиковать правительство без страха за личную безопасность.
Правильно ли я понял, что эту сеть предполагается строить поверх Интернета (т.е., используя существующие TCP\IP соединения)? Если так, то это сильно уменьшает ценность сети…
Предлагаю взглянуть на Hyperboria – оно уже в какой-то степени работает и нуждается в разработчиках.
Предлагаю взглянуть на Hyperboria – оно уже в какой-то степени работает и нуждается в разработчиках.
а) Ее можно строить поверх чего угодно. SRDS-адреса привязаны непосредственно к данным, совершенно неважно, где физически и в какой сети эти данные расположены. Можно хоть на бумажке напечатать.
В идеале Magic Torrent должен работать так: сид сообщает городу и миру, что у него есть такой-то (адрес в SRDS) атом по такому-то адресу (в любой работающей транспортной сети: хоть TCP/IP, хоть p2p, хоть onion и т.д.) Лич получает эту информацию, смотрит, есть ли у него в клиенте этот транспортный протокол, если есть — запрашивает атом. Если нет — ищет другого сида.
б) Я понимаю, это нескромно — говорить «уж лучше Вы к нам»… Но я смотрел Hyperboria. Там есть ряд вещей, которые я не понимаю… но суть не в этом. Моя архитектура имеет другие достоинства и недостатки. Про Hyperboria говорится: «Сейчас выбираются программные движки для создания следующих сервисов:
1) Децентрализованный DNS (скорее всего namecoin / P2P DNS)
2) Децентрализованный файловый хостинг (Скорее всего TAHOE-LAFS)
3) Децентрализованная социальная сеть».
Почему бы не использовать как вариант мою схему? Адресация SRDS делает децентрализованный DNS ненужным (и все проблемы, связанные с ним, неактуальными). Транспорт Magic Torrent будет хорошей альтернативой децентрализованному файловому хостингу: он дает простое и естественное распределенное хранение, при этом не возникает проблемы распределения ресурсов, из-за которой всякий децентрализованный файловый хостинг нуждается в централизованном управлении — квотами и пр.)
В идеале Magic Torrent должен работать так: сид сообщает городу и миру, что у него есть такой-то (адрес в SRDS) атом по такому-то адресу (в любой работающей транспортной сети: хоть TCP/IP, хоть p2p, хоть onion и т.д.) Лич получает эту информацию, смотрит, есть ли у него в клиенте этот транспортный протокол, если есть — запрашивает атом. Если нет — ищет другого сида.
б) Я понимаю, это нескромно — говорить «уж лучше Вы к нам»… Но я смотрел Hyperboria. Там есть ряд вещей, которые я не понимаю… но суть не в этом. Моя архитектура имеет другие достоинства и недостатки. Про Hyperboria говорится: «Сейчас выбираются программные движки для создания следующих сервисов:
1) Децентрализованный DNS (скорее всего namecoin / P2P DNS)
2) Децентрализованный файловый хостинг (Скорее всего TAHOE-LAFS)
3) Децентрализованная социальная сеть».
Почему бы не использовать как вариант мою схему? Адресация SRDS делает децентрализованный DNS ненужным (и все проблемы, связанные с ним, неактуальными). Транспорт Magic Torrent будет хорошей альтернативой децентрализованному файловому хостингу: он дает простое и естественное распределенное хранение, при этом не возникает проблемы распределения ресурсов, из-за которой всякий децентрализованный файловый хостинг нуждается в централизованном управлении — квотами и пр.)
А предложите свою концепцию сообществу cjdns, кстати!
А Вы к нему не принадлежите? Может, посодействуете? Если нет — да, попробую сам.
Это же open source, всё открыто :) Я даже затрудняюсь сказать, куда лучше стучать, чтоб обсудить идею… Либо в IRC-чатик, либо попробовать на socialno.de (доступно только из Hyperboria). Ну или на wiki проекта страничку создать.
По описанию частично похоже на Osiris-SPS и RetroShare
Да, спасибо, действительно рядом деталей похоже.
Но я ставил более глобальную задачу — ИМХО, то, что я предлагаю, удобно было бы использовать для построения универсальной сети обмена информацией, через границы несовместимых протоколов и проектов.
Но я ставил более глобальную задачу — ИМХО, то, что я предлагаю, удобно было бы использовать для построения универсальной сети обмена информацией, через границы несовместимых протоколов и проектов.
Проблема только в реализации идеи. И это действительно проблема. Придумать можно практически что угодно, а вот технически реализовать, да ещё и с таким широким набором параметров — это сложно.
Мой собственный опыт подсказывает, что проще использовать уже работающие решения (тем более, что и они не стоят на месте и развиваются).
Тот же Retroshare, например. Но у меня, как у интерфейсника, есть огромное желание его как минимум заредизайнить. То, как там всё устроено сейчас, вызывает желание задать пустоте кучу вопросов, типа: «О, ну зачем это всё так?».
А в целом, да. Одобряю и поддерживаю.
Мой собственный опыт подсказывает, что проще использовать уже работающие решения (тем более, что и они не стоят на месте и развиваются).
Тот же Retroshare, например. Но у меня, как у интерфейсника, есть огромное желание его как минимум заредизайнить. То, как там всё устроено сейчас, вызывает желание задать пустоте кучу вопросов, типа: «О, ну зачем это всё так?».
А в целом, да. Одобряю и поддерживаю.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рождение магии от духа протокола торрент (cхема организации свободной бесцензурной неразрушимой информационной сети)