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

[vitus_wagner]

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

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

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

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

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

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

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

Comments

[avnik]

json.loads(...) это одна строка, не 70.
Аналог есть в 99% современных языков в стандартной библиотеке.

MIME на питоне УЖЕ написан. Предлагаю им пользоваться где надо, и не пользоваться где не надо.
(то есть сделать поддержку опциональной). Для совсем первого прототипа сойдет и mime encoded html c css и юзерпиком внутри.

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

[vitus_wagner]

json.loads c гигабайтным AVI внутри одного из полей?
ну и задача канонизации json-представления (чтобы после десериализации-сериализации хэш сошелся) тоже та еще.

Кстати S к S/MIME вот-та-а-а-кенными гвоздями прибито и то все время оторваться норовит. У всех текстовых форматов огромные проблемы с электронной подписью.

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

TLV - это тоже готовый кусок. Применяется в куче мест, например, в сотовой телефонии и Smart Card API.

Нужно просто расширять свою эрудицию. Простой и тривиальный ASN.1 ему боль, а git - не боль.

[avnik]

Зачем гигабайтный avi то пихать внутрь?
Блобы оставить блобами в виде fixed хешей, пусть будут видны по http прямо из хранилища.

Зачем сериализовывать обратно десериализованое?
я json вспомнил исключительно на случай если мы хотим внутрь положить какие-то хорошо структурированые метаданные.
Впрочем десяток килобайт текста с разметкой я тоже не думая сунул бы json.
Если хочется чтобы сериализовалось -- aterm сериализуется обратно с удалением незначащих пробелов.

Я когда-то имел дело с ip телефонией, и ASN.1 в частности, втч с кишками парсеров, и спецификациями под мегабайт.
Так что с эрудицией касательно этого у меня все ок, просто хочу чтобы это конкретное изделие ITU-T похоронили.

Но я готов обсудить вариант с TLV, и посмотреть на вашу (и другие) реализации, вдруг это так же просто и удобно как json и/или mime.

[vitus_wagner]

Затем что мы сейчас обсуждаем формат сообщений cheshirenet. Сообщения это то что передается между узлами при синхронизации. Между узлами нет http, и не факт, что есть TCP/IP. Есть только какой-то 8bit-clean двунаправленный канал.

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

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

Опять же, необходимость работать с объектами, длина которых превосходит 2³²байтов в сочетании с тем, что длина большинства объектов менее 2¹⁶, а длина большинства полей - меньше 2⁷.

У меня была идея испоьзовать в качестве поля длины не BER-длину а utf-8. Т.е. считать что поля тэга и длины представляют собой UTF-8 символы. Но текущий стандарт UTF-8 поддерживает только коды от 0 до 2³¹. Для размера видео в байтах этого мало. Вот 36 бит, пожалуй бы хватило. Но 7-байтовые последовательнности, начинающиеся с 0xFE валидным utf-8 не являются. И ядро питона их обрабатывать не будет. Вообще максимальный символ юникода, с которым у меня питон справился это
0x0010ffff. Поэтому придется все-таки длину брать как в BER.

[avnik]

Ок, предложите свой вариант с BER, рассмотрим.

[avnik]

Насчет 8bit clean двунаправленого канала -- уже можно какой нибудь тупой вебсервис сделать. Вот не нужно делать свой протокол на таком низком уровне (по крайней мере на таком раннем этапе).

На этапе раннего прототипа я бы считал что мы можем показать все хранилище на FS через http, или дать rest api к нему (идеальным я бы считал прямой RO доступ, и RW чере апи)

Случаи когда есть только двунаправленый линк без http (или даже tcp) я бы рассматривал отдельно. Возможно там имеет смысл гонять бандлы (которые вообще transport agnostic)

Синхронизатор должен уметь работать с двумя хранилищами (либо на fs/fs+http, либо через апи). Потом можно будет добавить и свой протокол (для тех кому хочется/надо), и бандлы.

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


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


Вот по моему -- 1 файл на сообщение -- это тоже самоцель, во первых мы теряем возможность (дешевой) дедупликации аттачей/медиаконтента. 50 человек решат сделать пост с гигабайтным видео с котиком, и мы имеем 50 гиг трафика на ровном месте.
И 50гиг на хранилищах у всех в эпсилон окрестности. (дедупликация на том же zfs -- это очень дорого по CPU и памяти, ОЧЕНЬ, я пробовал этот кактус на вкус)

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

[vitus_wagner]

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

ASN.1 ему сложна. а рест прост! Диплом почетного гражданина города Вращенцы второй степени с правом несения Чуши по вам плачет.

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

Опыт Netnews показал что придумать единый формат хранилища на все случаи жизни нельзя.

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

piggibacking на http имеет только одну положительную сторону - он может просачиваться через некоторые корпоративные прокси. Но очень через некоторые, поскольку корпоративные прокси в наше время имеют привычку содержать в себе intrusion detection, устраивать
MiTM TLS-у и в общем есть большие шансы, что человек, пытающийся держать узел чеширнета на работе в такой конторе все равно работать через прокси не сможет.

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

[avnik]

Коллега, если ты хочешь чтобы это взлетело -- общаться с сервисом должно быть просто. Хоть curl из шеллскриптов, хоть из питонов, хоть прости г-споди из дотнета. Ничего проще http get/post для клиента (да и для сервера) нету. Можно полететь на всем готовом, практически на любом языке.

piggibacking на http имеет только одну положительную сторону

ага, можно поговорить с сервисом из любого языка/фреймворка практически не приходя в сознание.
Если выбирать между line oriented (или тем более бинарным) stateful протоколом, и возможностью послать json (или даже well-formed xml) через http post и получить аналогичный ответ -- я выберу его. Потому что это просто, весь код кроме моего обработчика ответа УЖЕ отлажен и вылизан поколениями.

Адрес для посылания диплома нужен? ;)

Мы не enterprise решение пишем. Мы пишем решение для людей. Которое должно работать в условиях дефицита процессорной мощности и дискового простраства


Вы уже определитесь -- или у нас дохрена мощности и пространства, или мы лимитированы всем
(в реальной жизни у нас будет 95% времени пофиг и то и то, и 5% времени или какая-то засада типа аварии, или 10 баксов за мегабай


PS Почитайте что ли спеку на H.225 там unaligned PER, в котором в отдельных полях DER в виде блобов (H.245). Может вас перестанет тянуть на ASN.1?

[avnik]

(в реальной жизни у нас будет 95% времени пофиг и то и то, и 5% времени или какая-то засада типа аварии, или 10 баксов за мегабай


(в реальной жизни у нас будет 95% времени пофиг и то и то, и 5% времени или какая-то засада типа аварии, или 10 баксов за мегабайт, и хочется поэкономить)

Что-то у меня запись ушла раньше чем я ее дописал