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

[vitus_wagner]

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

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

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

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

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

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

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

Comments

[avnik]

cid мне не нравится ровно одним, оно подразумевает засовывание всего в mime, включая габаритные картинки, и простигосподи видео. Я не уверен, что мы хотим base64 или еще что-то подобное в этом месте (хотя для вcяких мелких картинок типа "голов" юзеров в той же жежешечке -- cid ок).

Я бы предложил использовать cheshire:article:$hash:$mime/$type для статей (постов), cheshire:reply:$articleHash:$hash:$mime/$type (hash -- sha256 от контента), для низкоуровневого хранилища sha256 от этих урлов (но это уже детали реализации)

Для файлов cheshire:fixed:$hashAlgo:$hash (например cheshire:fixed:sha256:hash-of-some-file)

(Хотя может имеет смысл завести свои mime types и не употреблять article и reply, возможно даже верхним объектом в mime должен быть машиночитаемый файл (json?) с подписями, cid "основного" контента, и какие-то еще важные вещи, типа ссылки на ключ автора, авторский выбор для рубрикатора, etc)

Узел должен иметь возможность запросить у хранилища (и другого узла разумеется) список child'ов статьи (плоский или рекурсивный -- вопрос открытый)

[vitus_wagner]

Вообще говоря, cid не обязательно использовать вместе с MIME. Хотя дизайнился он именно для этого.
Нужно чтобы был какой-то формат, который будет позволять собрать multipart-message и назначить идентификаторы некоторым его частям.

Вообще-то я собираюсь TLV использовать, причем даже не ASN.1, хотя формат поля длины имеет смысл брать именно оттуда.

[avnik]

Ой, не надо ASN.1, это ужасно, больно и отпугивает.

Я вообще не вижу, зачем там бинарные форматы где-то кроме криптографии (где лучше взять что-то максимально готовое)
Собственно предложеную мной репликой выше конструкцию можно вообще собрать на стандартной библиотеке питона (email.MimeParser, json, hashlib, что нибудь для парсинга html и переписывания урлов в нем, и все в общем-то) или любого другого языка.

[vitus_wagner]

Затем что 90% контента по объему все равно бинарная - картинки и видео. Поэтому все линки все равно 8-bit-clean.
А оставшаяся часть все равно должна быть подписана. Поэтому криптография там везде.

TLV на питоне реализовать - это будет гораздо меньше кода, чем MIME. У меня в свое время 70 строк получилось.

[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 бод, у нас поедут только тексты и метаданные. А видео с котиками приедут через неделю, когда прилетит новый спутник.

[legolegs]

>cheshire:article:$hash:$mime/$type

Хэш-алгоритм однажды придётся поменять, поэтому название алгоритма разумно указать в ссылке. Далее, может быть полезно иметь возможность указать несколько хешей сразу. Ну и если хешей несколько, то пригодится всегда указывать и самую простую "хеш-сумму" - размер объекта.

Даже стандарт похожий есть: https://ru.wikipedia.org/wiki/Magnet-ссылка

[vitus_wagner]

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

А то у нас слишком много на завязано на этот хэш - и content addressable storage, и электронная подпись всех документов и алгоритм генерации никнеймов из открытого ключа.

[zaharchenko]

А что можно делать, если появится эффективный генератор?

[vitus_wagner]

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

[zaharchenko]

Я правильно понимаю, идея для борьбы с подбором коллизий, заменить часто применяемую ф-ию, своей которая является первой примененной два раза с разными ключами?

[vitus_wagner]

Неправильно полностью. Рекомендую букватиь почитать. В смысле Applied Crypthography Шнайера.п

[avnik]

Я кстати думаю что нафиг генератор никнеймов.
Я хочу свой никнейм, а не abracadabra.generated.

То есть он может быть, а может быть и well known псевдоним, или реальное паспортное имя -- как угодно держателю ключа.

[vitus_wagner]

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

[legolegs]

Вот кстати да, вы не один такой. Уверен, если завтра выкатит чеширнет своей мечты с рандомными никами послезавтра появится неофициальное, но популярное расширение протокола, привязывающее к сгенерёному нику произвольный+аваратки+ссылка на линкедин и фсбук. Это просто неизбежно.

[avnik]

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

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

[vitus_wagner]

Сидючи в Вильнюсе это может быть и можно себе позволить.

В Москве, Дамаске и Тегеране - нет.

[avnik]

Между нами девочками -- у меня ушло больше 10 лет на "сидеть в Вильнюсе а не в Москве". И приличное количество нервов и денег. И это при том, что я в общем не активист, и никому в общем-то не нужен.

Такие дела.

[vitus_wagner]

Вот по-моему потратить десять лет на то, чтобы променять один фашистский режим на другой, это такой же идиотизм. как использовать веб-сервисы и Rest Api там где можнно сделать обычный line-oriented-протокол на TCP-сокете.

[vitus_wagner]

Вы считаете, что 51 стаятья часть 1 зря в Конституцию вписана?

[avnik]

Я это не то чтобы совсем сам придумал -- аналогичный алгоритм используется в nix/nixos для формирования хешей пакетов.

base32(sha256(f)) по моему достаточно, но в принципе ничто не мешает включить его (хеш) и в строку (для fixed файлов это и так предлагается сделать)