# 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
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
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?
Никаких соображений. Всё замечательно. Так я это себе и представлял =)
Я тут немного выпадаю из сети. Не теряйте. Рано или поздно я отвечу =)
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?
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> На счёт протокола получения лички клиентом возражений нет? Мержим?
У меня вообще возражений нет. Только соображения. Что ни примите, я или сделаю это у себя или забью.
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> Второй вариант гарантирует приватность, но при этом ограничивает возможности построения разных топологий станций. Здесь мы либо ограничиваемся схемой "звезда", либо нетмейл на некоторых узлах принципиально не поддерживается.
Второй вариант неприемлемый, потому что или гарантировано усложняет топологию сети или делает нетмейл бесполезным.
>> Читать далее
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 есть ваще везде.
+++ картошки хватит на всех
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
На счёт протокола получения лички клиентом возражений нет? Мержим?
+++ картошки хватит на всех
Difrex (dynamic,1) → Andrew Lobanov – 14:48:28 2019-03-20
На счёт протокола получения лички клиентом возражений нет? Мержим?
+++ картошки хватит на всех
# Re: IDEC Mobile
Difrex (dynamic,1) → vit01 – 14:49:53 2019-03-20
Ура, у меня заработали уведомления о новой почте!
+++ картошки хватит на всех
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 не соединена напрямую с node3
Если поинты на node1 захотят написать нетмейл для node3 или наоборот, то у нас есть два взаимоисключающих варианта:
1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM
>> Читать далее
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> Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?
Не надо каждому с каждым. Просто весь нетмейл ходит по всем узлам. То есть это такой подвид эхомейла, которым ноды обмениваются по паролю, а клиенты получают только свою часть от этой эхи.
Но это всего лишь мои мысли.
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
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> В принципе, если личка будет вся синхронизироваться нормально, то можно и своей ноды ее тянуть.
Ну я предлагаю хождение лички организовать как обмен данными между узлами, которые доверяют друг другу. То есть не отдавать кому попало. Но в случе, если сисопы договорились, оно работать должно без проблем.
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
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
если согласен, то давай межить этот ПР.
> В гитхаб пока так и не заглядывал, но не проще ли обсуждать здесь?
Так я для того, чтобы и тут и там обсуждать можно было бота написал.
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> Шифрование открытым ключом станции всех сообщений, которые ей должны принадлежать?
>> Читать далее
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.
Difrex (dynamic,1) → All – 07:42:49 2019-03-17
Сегодня буду обновлять основной хост динамика с Debian oldstable до stable.
Возможно все приляжет до завтра. Бэкапы льются на DO, так что все восстановимо будет, если что.
Так же буду переводить сеть между виртуалками с OpenVPN на Wireguard.