А не попытаться ли...

[vitus_wagner]

... Оживить проект cheshirenet?

Три года назад как-то ни у кого не возникло желания поучаствовать в проекте. Потрепались, обсудили почти согласовали протокол, и успокоились на этом.

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

Базовых идей в cheshirenet было три

1. Оффлайновый веб - то есть каждое устройство несет в себе копию интеренсного владелцу контента, внутренне провязанную гиперссылками, и по возможности синхронизирует ее с другими копиями - можно через интернет, можно через ad-hoc wi-fi между двумя мобильными устройствами и вообще как угодно.

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

3. Ключ подписи представляет только самого себя. Т.е. сгенерировав новый ключ подписи, пользователь создает новую сетевую "личность", псевдоним. Никнеймы пользователи себе не придумывают, они алгоритмически выводятся из открытого ключа. (но сгенерированное имя вам не понравилось, вы можете сгенерировать себе другой ключ подписи).
Про сетевую личность известен только массив контента, подписанный этим ключом. (можно и рекомендуется иметь "двойника" - альтернативный пароль, при вводе которого в ваш узел чеширнета возникает другая сетевая идентичность, ни в чем кроме постинга фоточек котиков не замеченная).

Comments

[qkowlew]

Я лично за.
И готов обсуждать и тестировать любые аспекты.
Я бы решительно был ещё за форму обмена пакетами вида "выложил .tar.gz или .rar на http на произвольный сервер", "поместил текстовое сообщение в форум и дал на него http ссылку" и тому подобное.

[vitus_wagner]

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

Поэтому основной механизм - это именно синхронизация, и два узла вступив во взаимодействие, договариваются "а вот что у тебя есть из вот этого?" "есть это, это и это" "это и это давай сюда, а вот того - не надо".

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

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

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

[qkowlew]

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

Какой бы онлайн протокол ни был создан.

[vitus_wagner]

От того что в современной электронной почте 90% траффика спам, почта не становится менее полезной.
От того что в чеширнете 90% траффика будут представлять собой лайки и сиюминутный контент, он не перестанет обладать способностью распространятть вечные ценности.

А закон Старджона вообще-то никто не отменял.

[qkowlew]

Если система оптимизирована под онлайн обмен в динамике - вопрос о простоте-оптимальности обмена вечными ценностями - не праздный.

глюки поиска по ЖЖ и силь фейсбука "всё уплыло вниз" тому яркие примеры.

[vitus_wagner]

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

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

Интерес представляют промежуточные явления, вроде тех же сайтов игр.

Которые вообще-то сайты, но до проведения игры крайне интересны свежие обновления на них. Мне не совсем очевидно, как это следует делать.

А глюки с поиском в ЖЖ это глюки с поиском. Это исключительно нежелание и хозяев сервиса и поисковиков. У меня с тех пор как я делаю поиск в локальном бэкапе своего ЖЖ, причем чаще обычным grep-ом, даже не xapian-ом (хотя xapian-овский индекс строится), никаких проблем с поиском по своему ЖЖ нет.

[yurikhan]

Интерес представляют промежуточные явления, вроде тех же сайтов игр.

Которые вообще-то сайты, но до проведения игры крайне интересны свежие обновления на них. Мне не совсем очевидно, как это следует делать.

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

[legolegs]

>Тут принципиально то, что мы разделяем то, что видит пользователь, и то, чем обмениваются узлы.

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

[vitus_wagner]

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

[legolegs]

>и два узла вступив во взаимодействие, договариваются

Меня немножко сильно пугают накладные расходы на это договаривание, особенно если каждый лайк пересылать.

[vitus_wagner]

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

И вообще не в мире SOAP-а over TLS переживать по поводу наклакдных расходов.

[legolegs]

Т.е. bundling будет.

[vitus_wagner]

Разница в том, что в ньюсах и фидо бандлы формируются заранее. Узел помнит кто из его пиров чем интересуется. Здесь этот процесс более динамичен.
У узла есть пул фильтров, полученных с разных peer-ов, к которым он добавляет свои фильтры. И выдает это в качестве набора того, что ему интересно.

Здесь сильная ориентация не на постоянные линки а на хаотические ad hoc связи. Которые в общем имеют смысл и в интернете, где узлов много и можно, рандомизируя связи, балансировать нагрузку,
и, тем более, когда интернета нет и передача контента осуществляется через "личный контакт" между устройствами. Тогда встретив случайного peer-а хочется обменяться с ним возможно большим количеством свежих новостей.

[avnik]

Кстати в нормальном случае -- у большинства будет именно несколько постоянных линков скоре всего, +ad-hoc периодически -- когда нет связи/возбудилась цензура/etc.

[vitus_wagner]

Более того, когда нет связи, все равно будут скорее всего более-менее постоянные линки. Допустим, есть район в котором связи нет, и долго не будет. И есть некто, допустим местный лавочник, который систематически мотается туда-сюда. Скорее всего пиром его мобильника будет (имеющий связь) узел на оптовой базе, где он закупается и узел Wi-fi роутера его лавки. А весь остальной город будет к нему в лавку ходить за новостями.

Возможность "неразборчивых" связей важна для быстрого перестроения топологии сети в случае если что-то быстро и неприятно поменялось.

[avnik]

Все равно это потребует некоторых действий владельцев узлов -- а именно разрешение большего объема транзита (то есть "неинтересного" лавочнику и его аплинку)