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

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

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

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1923664.html. Please comment there using OpenID. Now there are comments

Подкинули ссылку на проект http://www.nncpgo.org (см тажке статью на хабре.

Подкинули под соусом "это же почти чеширнет". Нет, не чеширнет, и рядом не стояло (и ровно поэтому есть надежда что окажется более жизнеспособным).

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

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

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

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

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

При этом про UUCP автор знает (в статье на хабре упоминал), но похоже не слишком интересовался тем как это работало, что такое UUCP maps и что умела uucp кроме доставки почты и ньюсов. То есть что-то я не уверен, что в том виде как оно написано, оно масштабируется за пределы небольшой тусовки друзей.

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

Зато это у него уже работает как транспорт для электронной почты.

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

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1923294.html. Please comment there using OpenID. Now there are comments

Давно я не писал посты о прочитанных книгах, хотя в последнее время удалось прочитать достаточно много книг, которые достойны обзора. Так уж получилось, что в этом году большинство книг по программированию, которые мне попадались, были на английском языке. В этом посте речь пойдет об одной из таких книг Карла Фогеля (Karl Fogel) — «Producing Open […]

Итак, после постановки требований описанной в части 1 можно перейти к проектированию системы.

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