The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Выпуск p2p-мессенджера Communist 1.4"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "Выпуск p2p-мессенджера Communist 1.4" +1 +/
Сообщение от Аноним (-), 26-Июн-22, 05:52 
> NIH тут совершенно не причём (до вашего комментария я даже не знал,
> что это такое - пришлось лезть читать).

Это месенджер на основе DHT. Распределенный. Шифрованый. Опенсорсный. С протоколом получше иных открытых потуг на тему (e.g. Jami). До них дошло сделать его как либу. EPIC WIN относительно остальных: так появились довольно разные клиенты и боты.

Судя по протоколу те кто его делал посмотрели вокруг и сначала немного подумали что они делают и зачем. Все не предусмотришь, но у них сразу эквивалент STUN был прямо в их DHT, его не надо конфигурировать, любой узел так умеет. Если конфиг позволяет, клиент может быть TCP-релеем слегка похожим на TURN. Бутстрапы обычно предоставляют это, остальные по желанию, оно умеет аудио-видео так что трафик может быть солидный. Типа суперноды скайпа. TCP делали позже и он базовый и более кривой но лучше чем ничего. По факту TCP и UDP части самодостаточны. Можно гонять узел UDP-only, TCP-only или TCP+UDP. Они реюзают структуру пакетов но в принципе могут по отдельности существовать. А то что не будет прямого конекта - оно умеет минимальный туннелинг, это не tor конечно по приваси, но конект "не напрямую" все же в итоге сможет.

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

Аудио и видео - опция. В либе выбираемо с AV билдить или минимальную, оно даже gcc *.c собирается так то. А если либа собрана с AV, например, системная, с точки зрения программы все определяется повесил кодер handler событие или нет и возиться с аудио можно, но не обязательно. Так что минимальный текстовый бот - даже на си менее страницы кода! Поэтому через 15 минут я пустил основательно пропатченый пример с вики. Через пару дней ботик узнавал мастера и слал в UART микроконтроллера пакеты, щелкая нагрузками. Такой себе IOT. Просто целиком мой. А неплохо для распределенного чата то. В этом месте я все же немного вспоминаю что-то про способности и потребности.

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

Мне оказалось сложно приглядеться к коду из-за его структуры и отсутствия док. Как я знакомлюсь с программой? Понимаю макроуровень, общую структуру, как это концептуально взаимодействует в общем виде. А потом при интересе к той или иной части и желании поменять что-то лезу в микроуровень, поняв по макро-сетке координат куда идти. Деление на core lib и UI этому тоже нехило помогает. Но тут все это не сложилось.

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

У меня на этот счет есть странная теория: имея X ресурсов может быть эффективнее сделать основу 1 раз и 10 раз улучшить нежели 10 раз сделать основу и не иметь ресурсов на ее улучшение, получив 10 паршивых программ. Конечно это утрированное упрощение.

А то что нормальная архитектура протокола, core и апи может появиться сама, сначала накодим, потом подумаем, я не верю. Это как войнаимир vs миллион обезьян примерно. И джун отличается от синьора тем что не понимает это. Иногда даже полный чайник может срубить EPIC WIN, но догадаться о всех нюансах проигнорив чужой опыт все же "очень маловероятно".

> В основном - сама концепция. P2P мессенджер, с использованием UDP hole punch
> и DHT для обмена адресами.

Tox... чем-то похожим и является. Только чуть умнее сделан. DHT более секурный чем майнлайновый torrent: DHT коммуникации шифрованы, основано на том что cryptobox() работает так: shared secret(our privkey, their pubkey) == shared secret(their privkey, our pubkey). Они и сделали DHT по ширине pubkey: DHT ID заодно в лоб "their pubkey". Если мы его знаем, это достаточно для начала защищенных коммуникаций с ними, обмен ключами УЖЕ случился. Это не очень сильная защита если узлы рандомные, от левого вредителя не поможет, он расшифрует но потом может сделать что-то вредное. Но если оба узла мои - ВРЕДИТЕЛИ ПРОЛЕТАЮТ. Прелесть этой схемы в том что key exchange халявен. Если мы знаем DHT ID мы знаем их публичный ключ. С 160-битным DHT ID это не получится, короткий слишком. А такая интеграция крипто и DHT делает комбо с полезными свойствами сильно проще чем это могло бы быть при полной развязке их друг от друга. Тот же bitmessage делает это сильно более дурацки, у них ключи большие и они явно getpubkey протоколом делают. Это дольше, сложнее в коде, кривее и менее надежно. Из минусов - схема шифрования все же прибита на гвозди. С другой стороны, вы все-равно хотите одинаковое крипто по всей сети. Почему-то. Иначе как они комумницировать будут? Полурабочие уродцы юзерам не очень нужны. Туда же выбор крипто алгоритмов и проч.

Неким бонусом является то что так частично рубится атака когда ремота обкладывается узлами атакующего с близким или тем же ID и атакующий начинает сильно контролировать происходящее вокруг цели. В вон том слуае произвольный ID взять нельзя! Надо генерить пару ключей, и публичная часть будет DHT ID. Он уж такой какой получится, а чтобы подогнать близкий ключ надо брутфорсить генерацию пар ключей уже. Идентичный ID? Надо полностью сломать 25519 для этого, сгенерив приватный ключ из публичного, ага. Попытки взять чужой ID ведут к завалу крипто, ведь приватного ключа от этого ID у атакующего нет, он не сможет пакеты шифровать и расшифровывать как тот ID. И даже брутфорс близкого ID не совсем удобен с учетом временности ID у большинства клиентов кроме бутстрапов. Много затрат ресурсов с умеренным результатом. А вот торентовый DHT от этого не защищен вообще никак. Вы не представляете что там водится, совсем его заткнуть никто не смог конечно, но прицельно подпихнуть толпу копирасских шпиков вместо нормальных узлов периодически пытаются с переменным успехом.

У токса DHT ID сам по себе НЕ используется ими как долговременный ключ даваемый в линке. Это "транспортная" сущность, клиенты кроме бутстрапов иногда рандомно меняют для улучшения приваси как я понял (минус: лимитирует годность нестабильных клиентов как бутстрапов). Сам по себе долговременный ключ используется для того чтобы искать нужные ремоты в DHT.

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

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

И все же, видите сколько всего можно узнать просто посмотрев как другие это делают? Я бы до половины таких трюков сам не допер, N голов лучше 1.

> реальном железе. Было несколько моментов, когда я уже хотел плюнуть на
> всё, и заниматься другими вещами.

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

> Вы думаете, у меня было время хоть что-то нормально обдумывать?)) Хотите -
> я вам расскажу, в каких условиях всё это писалось? Я сидел
> в деревне, один. Вокруг - зима. Отопление - на дровах, которые
> нужно самому пилить и колоть, до ближайшего магазина 2 километра по
> никем не очищаемым от снега тропинкам.

Да это кажется типично для многих проектов. Торвальдс писал Linux в свободное время, коментя "wouldn't be as big and professional as hurd". А фултайм занятием он стал как-то сильно потом, когда другие увидели в этом некую ценность.

> температура +13 по Цельсию. Часа через три протопки (т.е. постоянной беготни
> на улицу и обратно за дровами) - +20.

Такое ощущение что дому просто не хватает утепления, если честно.

> почему всё выглядит так, как выглядит. Будет кому-то полезно - отлично.
> Нет - ну значит нет.

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

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

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Выпуск p2p-мессенджера Communist 1.4, opennews, 25-Июн-22, 09:38  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру