Сценарий «белые списки для всех, VipNet для избранных» звучит как отличный сюжет для антиутопии. Возможно, мы к нему и идём. Но пока Иван Иванов ещё может заказать VPS у хостера и поднять там ретранслятор, статья описывает, как это делать с умом. Когда наступит эра тотального VipNet, мои рекомендации устареют ровно так же, как и всё остальное, написанное про интернет до 2020 года. Я предпочитаю решать инженерные задачи для той реальности, которая есть за окном прямо сейчас, а не для той, что может наступить через пять лет. В конце концов, если завтра отключат электричество во всём городе, мой веб-сервер тоже не выживет — но это не повод не ставить его сегодня.
Спасибо. Про MITM — согласен, децентрализация от него сама по себе не спасает. Я смотрел больше в сторону живучести канала, а не чистоты. Разные задачи — разные инструменты.
Согласен, абсолютной защиты нет. Вопрос в том, сколько времени и бюрократических телодвижений потребуется, чтобы выключить именно вашу систему. В моей архитектуре это число выше, чем в централизованной. Если вам эта разница не важна — спору нет. Я считаю её существенной.
Пожалуй, на этом остановлюсь. Спасибо за дискуссию — она отлично иллюстрирует, почему одни инженеры готовятся к плохой погоде, пока другие надеются, что зонтик всегда будет под рукой. Я отношусь к первой категории. Удачи!
Абсолютно согласен: если регулятор решит выкосить все VPS разом — ляжет всё, и P2P, и централизованный чат. Разница в том, что централизованный сервер — это одна лампочка: щёлкнул выключателем — темно. Сеть ретрансляторов — это гирлянда из сотни лампочек. Чтобы погасить свет полностью, надо выкрутить каждую, причём часть из них висит в разных комнатах с разными хозяевами. Да, комната контролируется не вами. Но пока администратор обходит все углы с отвёрткой, у вас есть свет. Статья не обещает бессмертие. Она предлагает архитектуру, которая растягивает процесс отключения во времени и повышает его стоимость.
Отличный разбор. За исключением одного: вы спорите с лозунгом, которого в статье нет. Я не кричу «всё пропало, юзайте P2P». Я описываю конкретный механизм многослойной доставки, который в условиях белых списков и DPI позволяет хоть как-то сохранить связность. Если ваша критика в том, что это не решит проблему при полном отсутствии VPS и при тотальном запрете любого HTTPS — согласен, не решит. Как и любое другое решение. Но пока VPS существуют и пока HTTPS-трафик пропускают, грамотная архитектура деградации выигрывает у монолита, который ломается целиком. По поводу нейросетки — я автор, и мне странно оправдываться за текст, который писал сам. Но если вас смущает стиль, готов обсудить технические детали, а не литературные достоинства.
Вы описываете сегодняшнюю экономику: дешевле и надёжнее один сервер. Статья — про завтрашнюю архитектуру. Когда привычные трюки перестанут работать, централизованное решение ляжет мгновенно, а распределённая система успеет деградировать до последнего рабочего слоя. L3-фильтрацию действительно не обойти без ретранслятора с белым IP — это данность. Вопрос в том, как именно мы используем этот факт: ставим одну VPS и молимся, что её не тронут, или заранее строим систему, умеющую переползать между сотней таких VPS без участия пользователя. Первое — работает сегодня, второе — нужно, чтобы не остаться без связи завтра. Я пишу про второе.
Ваше замечание — лучшее доказательство того, что статья нужна. Вы описываете идеальный мир одного админа с одним сервером. Реальность же такова, что этот сервер завтра могут выключить за неуплату, а послезавтра — внести его IP в чёрный список. P2P в статье — это не про «сейчас, когда всё хорошо», а про «а что мы будем делать, когда станет плохо и привычные костыли отвалятся». Если вам и вашим собеседникам «плохо» никогда не станет — вы счастливый человек, статья не для вас.
Вы описали ровно ту ситуацию, для которой в статье выделены 4-й и 5-й слои (Relay и Fallback). Hole punching (3-й слой) решает проблему CGNAT, но не L3-фильтрации подсетей. Статья не утверждает, что прямое соединение возможно всегда. Статья утверждает, что архитектура должна уметь вовремя понять, что прямое соединение невозможно, и бесшовно переключиться на маскированный ретранслятор в белом списке. Это и есть переход от P2P к P2R2P (Peer-to-Relay-to-Peer) без потери связности для пользователя.
Справедливое замечание. Но по такой логике можно и веб-сервер не поднимать: ведь если отключат электричество во всем городе, он тоже не заработает. Я исхожу из того, что полное отключение от мира — событие экстраординарное и краткосрочное. А вот жизнь в режиме „DPI режет UDP, а у 90% пользователей серый IP“ — это наша ежедневная реальность прямо сейчас. Вот для нее и нужна система, а не просто еще один протокол.
Вы описали ровно ту ситуацию, ради которой в статье добавлены слои Relay и обфускации. Читайте раздел про hole punching — именно он решает проблему доступа из-под CGNAT к домашней сети без облачного сервера посередине.
Статья не про «победу» над белыми списками. Она про то, чтобы мессенджер не сдох полностью, а перешёл в режим «почтового голубя» через HTTPS. Просто не у всех есть VPS из «белого списка»
Я не буду голословен, так что подкреплю свои выводы материалами!
Репозиторий Pear на GitHub Этот файл доказывает, что экосистема (Pear Runtime) действительно Open Source. Однако в нём нет самого приложения Keet.
Пост TheGuySwann на Nostr Этот пост содержит прямое признание одним из участников сообщества, что именно Keet является закрытым компонентом.
Дискуссия о закрытости Keet на lemmy.ml В этом обсуждении пользователь belit_deg сначала ошибочно называет Keet “свободным и открытым”, но затем исправляется.
Так что Keet как клиентское приложение — это закрытый проект. При этом компания позиционирует экосистему как Open Source, а конкретный продукт, который нужен пользователю, остаётся proprietary. Это и есть та самая “лицензионная нечистоплотность”, о которой я говорю: двойные стандарты, когда платформа открыта, а рабочий клиент — нет.
Я бы вам ответил, но я всё ещё верю что Хабр это скопление умных людей. И если что это сообщение я написал сам! А все ваши претензии я вижу как отрицание печатного текста и признание только рукописного. По сути вы просто ...
Спасибо большое за поддержку и очень точное замечание!
Вы попали в самую суть. Моя цель заключалась именно в том, чтобы инициировать техническую дискуссию о будущем P2P-коммуникаций в существующих сетевых реалиях, а не в том, чтобы соревноваться в способах генерации текста.
Я согласен, что децентрализация — это действительно важный вектор развития, и Jami здесь обладает колоссальным потенциалом. Очень рад, что вы это отметили.
Что касается остальных комментариев — я совершенно спокойно отношусь к критике. Главное, чтобы она была по делу и касалась технической части: архитектуры ICE, проблем CGNAT, предложений по QUIC или libp2p. Если у кого-то есть конструктивные замечания по существу вопроса — я открыт к диалогу. Если же дискуссия сводится к тому, каким инструментом набран текст, то, наверное, это не совсем тот случай, когда мы можем продвинуться в обсуждении инженерных решений.
Ещё раз спасибо, что услышали главное. Будем надеяться, что сообщество разработчиков действительно обратит внимание на проблемы, описанные в статье, и Jami станет тем неубиваемым инструментом, который нам всем нужен.
Keet — это блестящее подтверждение моей правоты. Я описал, каким должен быть идеальный P2P-мессенджер для российских реалий, и оказалось, что такой уже существует. Это значит, что я мыслю абсолютно в правильном направлении.
Однако для сообщества, которое я хочу собрать вокруг идеи "свободного и работающего P2P-мессенджера", Keet не подходит из-за своей лицензионной нечистоплотности.
Про имитацию HTTP — это дельный совет, спасибо. Сложный, но дельный. Именно такие идеи и нужны, чтобы двигаться дальше.
Моя претензия не к критике, а к её тону. Легко прийти и сказать "всё ерунда, QUIC заблокируют". Тяжело — предложить, как именно сделать эту самую "100% имитацию HTTP" в open source P2P-мессенджере с сохранением шифрования и децентрализации. Если у вас есть конкретный инженерный план или ссылки, как это можно провернуть (может, на базе тех же XRay-конфигов) — давайте обсуждать. Я в статье честно написал, что я не программист, и буду рад любой помощи.
А просто обесценивать чужие попытки что-то сделать, не предлагая взамен ничего, кроме сарказма — увольте. Если есть, что сказать по делу — я во внимании. Если нет — удачи.
Справедливо. Приказ «выключить всё» обнуляет любую инженерию. Статья — про жизнь до этого приказа. Спасибо за ёмкое дополнение.
Сценарий «белые списки для всех, VipNet для избранных» звучит как отличный сюжет для антиутопии. Возможно, мы к нему и идём. Но пока Иван Иванов ещё может заказать VPS у хостера и поднять там ретранслятор, статья описывает, как это делать с умом. Когда наступит эра тотального VipNet, мои рекомендации устареют ровно так же, как и всё остальное, написанное про интернет до 2020 года. Я предпочитаю решать инженерные задачи для той реальности, которая есть за окном прямо сейчас, а не для той, что может наступить через пять лет. В конце концов, если завтра отключат электричество во всём городе, мой веб-сервер тоже не выживет — но это не повод не ставить его сегодня.
Спасибо. Про MITM — согласен, децентрализация от него сама по себе не спасает. Я смотрел больше в сторону живучести канала, а не чистоты. Разные задачи — разные инструменты.
Согласен, абсолютной защиты нет. Вопрос в том, сколько времени и бюрократических телодвижений потребуется, чтобы выключить именно вашу систему. В моей архитектуре это число выше, чем в централизованной. Если вам эта разница не важна — спору нет. Я считаю её существенной.
Пожалуй, на этом остановлюсь. Спасибо за дискуссию — она отлично иллюстрирует, почему одни инженеры готовятся к плохой погоде, пока другие надеются, что зонтик всегда будет под рукой. Я отношусь к первой категории. Удачи!
Абсолютно согласен: если регулятор решит выкосить все VPS разом — ляжет всё, и P2P, и централизованный чат.
Разница в том, что централизованный сервер — это одна лампочка: щёлкнул выключателем — темно. Сеть ретрансляторов — это гирлянда из сотни лампочек. Чтобы погасить свет полностью, надо выкрутить каждую, причём часть из них висит в разных комнатах с разными хозяевами.
Да, комната контролируется не вами. Но пока администратор обходит все углы с отвёрткой, у вас есть свет.
Статья не обещает бессмертие. Она предлагает архитектуру, которая растягивает процесс отключения во времени и повышает его стоимость.
Отличный разбор. За исключением одного: вы спорите с лозунгом, которого в статье нет. Я не кричу «всё пропало, юзайте P2P». Я описываю конкретный механизм многослойной доставки, который в условиях белых списков и DPI позволяет хоть как-то сохранить связность.
Если ваша критика в том, что это не решит проблему при полном отсутствии VPS и при тотальном запрете любого HTTPS — согласен, не решит. Как и любое другое решение. Но пока VPS существуют и пока HTTPS-трафик пропускают, грамотная архитектура деградации выигрывает у монолита, который ломается целиком.
По поводу нейросетки — я автор, и мне странно оправдываться за текст, который писал сам. Но если вас смущает стиль, готов обсудить технические детали, а не литературные достоинства.
Вы описываете сегодняшнюю экономику: дешевле и надёжнее один сервер. Статья — про завтрашнюю архитектуру. Когда привычные трюки перестанут работать, централизованное решение ляжет мгновенно, а распределённая система успеет деградировать до последнего рабочего слоя. L3-фильтрацию действительно не обойти без ретранслятора с белым IP — это данность. Вопрос в том, как именно мы используем этот факт: ставим одну VPS и молимся, что её не тронут, или заранее строим систему, умеющую переползать между сотней таких VPS без участия пользователя. Первое — работает сегодня, второе — нужно, чтобы не остаться без связи завтра. Я пишу про второе.
Ваше замечание — лучшее доказательство того, что статья нужна. Вы описываете идеальный мир одного админа с одним сервером. Реальность же такова, что этот сервер завтра могут выключить за неуплату, а послезавтра — внести его IP в чёрный список. P2P в статье — это не про «сейчас, когда всё хорошо», а про «а что мы будем делать, когда станет плохо и привычные костыли отвалятся». Если вам и вашим собеседникам «плохо» никогда не станет — вы счастливый человек, статья не для вас.
Вы описали ровно ту ситуацию, для которой в статье выделены 4-й и 5-й слои (Relay и Fallback). Hole punching (3-й слой) решает проблему CGNAT, но не L3-фильтрации подсетей. Статья не утверждает, что прямое соединение возможно всегда. Статья утверждает, что архитектура должна уметь вовремя понять, что прямое соединение невозможно, и бесшовно переключиться на маскированный ретранслятор в белом списке. Это и есть переход от P2P к P2R2P (Peer-to-Relay-to-Peer) без потери связности для пользователя.
Справедливое замечание. Но по такой логике можно и веб-сервер не поднимать: ведь если отключат электричество во всем городе, он тоже не заработает. Я исхожу из того, что полное отключение от мира — событие экстраординарное и краткосрочное. А вот жизнь в режиме „DPI режет UDP, а у 90% пользователей серый IP“ — это наша ежедневная реальность прямо сейчас. Вот для нее и нужна система, а не просто еще один протокол.
Вы описали ровно ту ситуацию, ради которой в статье добавлены слои Relay и обфускации. Читайте раздел про hole punching — именно он решает проблему доступа из-под CGNAT к домашней сети без облачного сервера посередине.
Статья не про «победу» над белыми списками. Она про то, чтобы мессенджер не сдох полностью, а перешёл в режим «почтового голубя» через HTTPS. Просто не у всех есть VPS из «белого списка»
Я не буду голословен, так что подкреплю свои выводы материалами!
Репозиторий Pear на GitHub Этот файл доказывает, что экосистема (Pear Runtime) действительно Open Source. Однако в нём нет самого приложения Keet.
Пост TheGuySwann на Nostr Этот пост содержит прямое признание одним из участников сообщества, что именно Keet является закрытым компонентом.
Дискуссия о закрытости Keet на lemmy.ml В этом обсуждении пользователь belit_deg сначала ошибочно называет Keet “свободным и открытым”, но затем исправляется.
Так что Keet как клиентское приложение — это закрытый проект. При этом компания позиционирует экосистему как Open Source, а конкретный продукт, который нужен пользователю, остаётся proprietary. Это и есть та самая “лицензионная нечистоплотность”, о которой я говорю: двойные стандарты, когда платформа открыта, а рабочий клиент — нет.
Я бы вам ответил, но я всё ещё верю что Хабр это скопление умных людей. И если что это сообщение я написал сам! А все ваши претензии я вижу как отрицание печатного текста и признание только рукописного. По сути вы просто ...
Мы вроде обсуждали месенджер, а не почту! Давай тогда почту России вспомним? А что! Полный обход БС, ни какой цензуры и т.д.
Спасибо большое за поддержку и очень точное замечание!
Вы попали в самую суть. Моя цель заключалась именно в том, чтобы инициировать техническую дискуссию о будущем P2P-коммуникаций в существующих сетевых реалиях, а не в том, чтобы соревноваться в способах генерации текста.
Я согласен, что децентрализация — это действительно важный вектор развития, и Jami здесь обладает колоссальным потенциалом. Очень рад, что вы это отметили.
Что касается остальных комментариев — я совершенно спокойно отношусь к критике. Главное, чтобы она была по делу и касалась технической части: архитектуры ICE, проблем CGNAT, предложений по QUIC или libp2p. Если у кого-то есть конструктивные замечания по существу вопроса — я открыт к диалогу. Если же дискуссия сводится к тому, каким инструментом набран текст, то, наверное, это не совсем тот случай, когда мы можем продвинуться в обсуждении инженерных решений.
Ещё раз спасибо, что услышали главное. Будем надеяться, что сообщество разработчиков действительно обратит внимание на проблемы, описанные в статье, и Jami станет тем неубиваемым инструментом, который нам всем нужен.
Keet — это блестящее подтверждение моей правоты. Я описал, каким должен быть идеальный P2P-мессенджер для российских реалий, и оказалось, что такой уже существует. Это значит, что я мыслю абсолютно в правильном направлении.
Однако для сообщества, которое я хочу собрать вокруг идеи "свободного и работающего P2P-мессенджера", Keet не подходит из-за своей лицензионной нечистоплотности.
Ещё раз спасибо за информацию!
Не слышал про такой, спасибо за информацию!
Про имитацию HTTP — это дельный совет, спасибо. Сложный, но дельный. Именно такие идеи и нужны, чтобы двигаться дальше.
Моя претензия не к критике, а к её тону. Легко прийти и сказать "всё ерунда, QUIC заблокируют". Тяжело — предложить, как именно сделать эту самую "100% имитацию HTTP" в open source P2P-мессенджере с сохранением шифрования и децентрализации. Если у вас есть конкретный инженерный план или ссылки, как это можно провернуть (может, на базе тех же XRay-конфигов) — давайте обсуждать. Я в статье честно написал, что я не программист, и буду рад любой помощи.
А просто обесценивать чужие попытки что-то сделать, не предлагая взамен ничего, кроме сарказма — увольте. Если есть, что сказать по делу — я во внимании. Если нет — удачи.