#  Re: Netmail
G2I (dynamic,2) → All  –  11:37:37 2019-04-03

Новый комментарий от пользователя Difrex
к задаче "Описание client API" https://github.com/idec-net/netmail/issues/4.
Оставлен 2019-04-03 07:08:09 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/4#issuecomment-479367180

Сделано в рамках #1

+++ G2I: https://github.com/idec-net/github2idec. GPLv3
#  Re: Netmail
Difrex (dynamic,1) → Andrew Lobanov  –  07:06:30 2019-04-03

AL> Difrex> Какие есть соображения по этому: https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19e52f117f8993/README.org#%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82-client-api?
AL> Никаких соображений. Всё замечательно. Так я это себе и представлял =)
Ок. Я мержу тогда.

+++ At work. idec.el/0.1
#  Re: Netmail
Andrew Lobanov (tavern,1) → Difrex  –  06:39:53 2019-04-03

Difrex> Какие есть соображения по этому: https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19e52f117f8993/README.org#%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82-client-api?

Никаких соображений. Всё замечательно. Так я это себе и представлял =)

Я тут немного выпадаю из сети. Не теряйте. Рано или поздно я отвечу =)
#  Re: Netmail
Difrex (dynamic,1) → Andrew Lobanov  –  05:20:30 2019-03-21

Какие есть соображения по этому: https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19e52f117f8993/README.org#%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82-client-api?
#  Re: Netmail
Andrew Lobanov (tavern,1) → Difrex  –  04:28:01 2019-03-21

Difrex> На счёт протокола получения лички клиентом возражений нет? Мержим?

У меня вообще возражений нет. Только соображения. Что ни примите, я или сделаю это у себя или забью.
#  Re: Netmail
Andrew Lobanov (tavern,1) → vit01  –  04:27:53 2019-03-21

vit01> Предположим, у нас есть 3 станции по такой схеме:
vit01> ====
vit01> node1 ---- node2 ---- node3
vit01> ====
vit01> node1 не соединена напрямую с node3
vit01> Если поинты на node1 захотят написать нетмейл для node3 или наоборот, то у нас есть два взаимоисключающих варианта:
vit01> 1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM
vit01> 2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов
vit01> Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

Для этого есть PGP, например. Если уж параноишь в сети друзей, то делай это правильно. Шифрование на уровне стандарта это бессмысленное переусложнение. IDEC должен всего лишь носить почту, а остальное - не его забота.

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

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

>> Читать далее
#  Re: Netmail
Difrex (dynamic,1) → vit01  –  14:47:28 2019-03-20

vit01> 1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM


vit01> 2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов

vit01> Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

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

Можно обменяться ключами нод. Ну, шифровать ими личку с армором, тогда всё остаётся в plain text, но усложняет стандарт.
С другой стороны gpg есть ваще везде.

+++ картошки хватит на всех
#  Re: Netmail
Difrex (dynamic,1) → Andrew Lobanov  –  14:48:28 2019-03-20

На счёт протокола получения лички клиентом возражений нет? Мержим?

+++ картошки хватит на всех
#  Re: IDEC Mobile
Difrex (dynamic,1) → vit01  –  14:49:53 2019-03-20

Ура, у меня заработали уведомления о новой почте!

+++ картошки хватит на всех
#  Re: Netmail
vit01 (mira, 1) → Andrew Lobanov  –  12:45:16 2019-03-20

AL>>> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
vit01>> Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?

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

Предположим, у нас есть 3 станции по такой схеме:

====
node1 ---- node2 ---- node3
====


node1 не соединена напрямую с node3
Если поинты на node1 захотят написать нетмейл для node3 или наоборот, то у нас есть два взаимоисключающих варианта:

1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM

>> Читать далее
#  Re: Netmail
Andrew Lobanov (tavern,1) → vit01  –  09:26:56 2019-03-20

AL>> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
vit01> Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?

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

Но это всего лишь мои мысли.
#  Re: Netmail
vit01 (mira, 1) → Andrew Lobanov  –  08:33:51 2019-03-20

AL> 1. Между узлами сети личные сообщения ходят как простая эха, но по паролю.
AL> 2. Клиент забирает со своего узла свои сообщения по паролю. То есть не получит чужих сообщений никак.
AL> 3. Шифрование не является частью протокола.

AL> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.

Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?

Это и правда упрощает реализацию, хотя и теряется гибкость.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
#  Re: Netmail
Andrew Lobanov (tavern,1) → Difrex  –  07:42:01 2019-03-20

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

Ну я предлагаю хождение лички организовать как обмен данными между узлами, которые доверяют друг другу. То есть не отдавать кому попало. Но в случе, если сисопы договорились, оно работать должно без проблем.
#  Re: Netmail
Difrex (dynamic,1) → Andrew Lobanov  –  08:31:31 2019-03-18

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


+++ At work. idec.el/0.1
#  Re: Netmail
Difrex (dynamic,1) → Andrew Lobanov  –  07:20:48 2019-03-18

Посмотри пожалуйста https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19e52f117f8993/README.org#%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82-client-api

если согласен, то давай межить этот ПР.

> В гитхаб пока так и не заглядывал, но не проще ли обсуждать здесь?
Так я для того, чтобы и тут и там обсуждать можно было бота написал.
#  Re: Netmail
Andrew Lobanov (tavern,1) → G2I  –  04:04:39 2019-03-18

G2I> Ведь нам надо сделать так, чтобы
G2I> 1. Нетмейл-сообщения ходили между станциями

Это просто.

G2I> 2. Станция не могла прочитать нетмейл чужих станций

Почему? Если нужно шифрование, то оно должно быть на стороне клиента, а не на стороне ноды.

G2I> 2.1 Но при этом могла отдавать их даунлинкам

Это совсем просто.

G2I> Шифрование открытым ключом станции всех сообщений, которые ей должны принадлежать?


>> Читать далее
#  Апгрейд на dynamic
Difrex (dynamic,1) → All  –  07:42:49 2019-03-17



Сегодня буду обновлять основной хост динамика с Debian oldstable до stable.
Возможно все приляжет до завтра. Бэкапы льются на DO, так что все восстановимо будет, если что.
Так же буду переводить сеть между виртуалками с OpenVPN на Wireguard.