Я думаю, что нужно начинать с этим что-то делать.

Для этого я создал репозиторий с документом в котором предлагаю общими усилиями
разработать стандарт обмена личными сообщениями, а так же реализовать PoC сервера(ноды)
и клиента.

Вот этот репозиторий: https://github.com/idec-net/netmail
Давайте обсуждать и дописывать.

+++ At work. idec.el/0.1

Difrex> Я думаю, что нужно начинать с этим что-то делать.

Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)

Закладываю три вещи в это дело:

1. Реализация на python, чтобы любой желающий мог ознакомиться и внести изменения.
2. По возможности максимальная модульность реализации.
3. Настолько лаконичный и простой код, насколько я смогу.

В данный момент реализовано всё, кромен фэх и нет вебморды, но оно уже существенно лучше iing в плане реализации. Кода меньше, он проще и быстрее.

Difrex> Для этого я создал репозиторий с документом в котором предлагаю общими усилиями
Difrex> разработать стандарт обмена личными сообщениями, а так же реализовать PoC сервера(ноды)
Difrex> и клиента.
Difrex> Вот этот репозиторий: https://github.com/idec-net/netmail

Хорошее дело.

Difrex> Давайте обсуждать и дописывать.

Обсуждать готов, а вот писать пока не очень.

Самое главное, с моей точки зрения, оставить шифрование нетмейла опцией. Лучше всего, вообще не делать его частью стандарта. Нужно оставить сам стандарт максимально простым.

> Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)
Это дело хорошее :)

> В данный момент реализовано всё, кромен фэх и нет вебморды
А нужна ли веб-морда в эталонной реализации ноды?

> Обсуждать готов, а вот писать пока не очень.
Присоединяйся в обсуждение этого ПР https://github.com/idec-net/netmail/pull/1

> Самое главное, с моей точки зрения, оставить шифрование нетмейла опцией
Я думал, что без шифрования это все делать. Шифровать можно GPG само тело сообщения.
Так мы вообще никак не переусложним стандарт.

>> Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)
Difrex> Это дело хорошее :)

Нужное как минимум =)

>> В данный момент реализовано всё, кромен фэх и нет вебморды
Difrex> А нужна ли веб-морда в эталонной реализации ноды?

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

>> Обсуждать готов, а вот писать пока не очень.
Difrex> Присоединяйся в обсуждение этого ПР https://github.com/idec-net/netmail/pull/1

Обязательно, но пока занят всякой фигнёй =(

>> Самое главное, с моей точки зрения, оставить шифрование нетмейла опцией
Difrex> Я думал, что без шифрования это все делать. Шифровать можно GPG само тело сообщения.

Да. Всё верно =)

Difrex> Так мы вообще никак не переусложним стандарт.

При случае отпишу туда конь цепцию, которая сложилась в голове на эту тему.

Привет!

Это первое сообщение от G2I - бота слежения за задачами в репозитории на Github.
Сейчас я наблюдаю за проектом https://github.com/idec-net/netmail.

Новые события будут публиковаться в этой теме.

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя vit1-irk
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-13 08:43:24 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472330230

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

Именно. Но при этом надо не давать ноде читать нетмейл поинтов чужих нод. Чтобы пересылать можно было, а читать - нет. Поэтому какое-то подобие шифрования желательно

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-13 09:44:30 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472350243

Напишу бота `github<->idec`, чтобы транслировать стрим, а то не все подключились в обсуждение.

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-12 14:56:50 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472035614

Я за то, чтобы по умолчанию работало без шифрования. Если так хочется шифровать личку, то можно использовать gpg в теле сообщения.
Нода уже может шифровать все у себя внутри.

Я как-то предлагал шифрование на основе публичных ключей нод, но меня не особо поддержали.

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

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-12 14:58:16 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472036264

Я за то, чтобы по умолчанию работало без шифрования. Если так хочется
шифровать личку, то можно использовать gpg в теле сообщения.
Нода уже может шифровать все у себя внутри.

Я как-то предлагал шифрование на основе публичных ключей нод, но меня не
особо поддержали.

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


+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя vit1-irk
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-12 14:11:45 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-472017154

По факту это самая сложная штука для проработки

Ведь нам надо сделать так, чтобы

1. Нетмейл-сообщения ходили между станциями
2. Станция не могла прочитать нетмейл чужих станций
2.1 Но при этом могла отдавать их даунлинкам

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

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Client protocol draft" https://github.com/idec-net/netmail/pull/1.
Оставлен 2019-03-12 12:22:16 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/pull/1#issuecomment-471977969

Как в текущем виде?

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2019-03-16 13:47:14 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-473531586

> Напишу бота github<->idec, чтобы транслировать стрим, а то не все подключились в обсуждение.
Написал. Постит комменты с гитхаба в этот тред: https://dynamic.lessmore.pw/thread/3a6a0226-a22f-475a-82d1-81311e552b3a

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Client protocol draft" https://github.com/idec-net/netmail/pull/1.
Оставлен 2019-03-16 19:28:35 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/pull/1#issuecomment-473577352

Ну, что, мержим?

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

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

Это просто.

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

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

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

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

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

Я не умею пользоваться гитхабом, так что напишу свои мысли тут.

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

То есть выглядеть оно должно примерно так:

Поинт забирает почту: GET /x/m/<authstr>[/слайс].

Поинт отправляет почту: POST /x/m/ (параметры pauth и tmsg).

Нода забирает почту с аплинка: GET /x/n/<password>.

Этого уже достаточно для рабочей лички, в принципе.

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

За основу формата сообщений предлагаю взять существующий формат:

ii/ok[/reply/<msgid>]
<адрес получателя>
<время>
<имя отправителя>
<адрес отправителя>
<имя получателя>
<тема>

<тело сообщения>

И для отправки тоже:

<адрес получателя>
<имя получателя>
<тема>

[@repto:<msgid>]
<тело сообщения>

В гитхаб пока так и не заглядывал, но не проще ли обсуждать здесь?

ЗЫЖ Я за любую движуху, но без излишнего усложнения протокола.

Посмотри пожалуйста 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

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

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

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

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

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

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

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

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

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

Но это всего лишь мои мысли.

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

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

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

node1 ---- node2 ---- node3

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

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

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

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

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

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

+++ картошки хватит на всех

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


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

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

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

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

+++ картошки хватит на всех

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

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

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

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?

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> 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
к задаче "Описание 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

Новый комментарий от пользователя Difrex
к задаче "Описание формата бандла" https://github.com/idec-net/netmail/issues/6.
Оставлен 2019-07-21 07:43:30 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/6#issuecomment-513531557

Вроде, как описание в мастере. Возражений нет.

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Описание формата сообщения на отправку" https://github.com/idec-net/netmail/issues/7.
Оставлен 2019-07-21 07:43:48 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/7#issuecomment-513531576

В мастере.

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя Difrex
к задаче "Node 2 node initial" https://github.com/idec-net/netmail/pull/8.
Оставлен 2019-07-21 09:51:13 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/pull/8#issuecomment-513539603

В таком виде ок?

Не уверен только на счет нужности получения колличества сообщений.

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

Новый комментарий от пользователя abolychev
к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
Оставлен 2020-03-05 11:02:24 +0000 UTC.
Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-595169462

Мне кажется для netmail лучше push модель.
point1 ---push---> node1 ---push---> node2 ---pull---> poin2
Тогда письмо будут видеть только src и dst ноды. Но нужен будет nodelist с адресами нод.

+++ G2I: https://github.com/idec-net/github2idec. GPLv3

G2I> Новый комментарий от пользователя abolychev
G2I> к задаче "Описание node2node API" https://github.com/idec-net/netmail/issues/5.
G2I> Оставлен 2020-03-05 11:02:24 +0000 UTC.
G2I> Ссылка на комментарий: https://github.com/idec-net/netmail/issues/5#issuecomment-595169462

G2I> Мне кажется для netmail лучше push модель.
G2I> point1 ---push---> node1 ---push---> node2 ---pull---> poin2
G2I> Тогда письмо будут видеть только src и dst ноды. Но нужен будет nodelist с адресами нод.

Я тут отвечу пока. Вообще, доля здравого смысла в этом есть. Плюсы очевидны. Опять таки, если оглядываться на фидонет, то там нетмейл тоже сбоку от эхомейла. И даже маршруты прохождения почты разные зачастую. Может, попробуем такой вариант? Хотя, сейчас мне надо iing уже выкинуть на свалку и на базе idec (который моя реализация) запилить новую таверну. А там уже можно и экспериментировать.

Лично мне определённо нравится что не надо ничего сбоку прикручивать типа того же PGP, что нет необходимости прохождения нетмейла по лишним нодам. Заодно будет повод актуализировать нодлист :)

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

> Заодно будет повод актуализировать нодлист :)
Давайте стандартизируем его :)

G2I>> Мне кажется для netmail лучше push модель.
G2I>> point1 ---push---> node1 ---push---> node2 ---pull---> poin2
G2I>> Тогда письмо будут видеть только src и dst ноды. Но нужен будет nodelist с адресами нод.
AL> Я тут отвечу пока. Вообще, доля здравого смысла в этом есть. Плюсы очевидны. Опять таки, если оглядываться на фидонет, то там нетмейл тоже сбоку от эхомейла. И даже маршруты прохождения почты разные зачастую. Может, попробуем такой вариант? Хотя, сейчас мне надо iing уже выкинуть на свалку и на базе idec (который моя реализация) запилить новую таверну. А там уже можно и экспериментировать.
AL> Лично мне определённо нравится что не надо ничего сбоку прикручивать типа того же PGP, что нет необходимости прохождения нетмейла по лишним нодам. Заодно будет повод актуализировать нодлист :)

Продолжу тут тоже.
У этой схемы нашел один минус - кто угодно может напушить что угодно на ноду. Нужна аутентификация нод.
Я подумал над простым способом аутентификации нод и вот что придумал.
srcnode при наличии почты для dstnode генерирует рамдомную строку(secret), сохраняет ассоциацию dstnode - secret и делает запрос на dstnode с параметрами nodename=srcnode, secret=secret. dstnode после запроса смотрит адрес srcnode в нодлисте и делает запрос на srcnode с параметрами nodename=dstnode, secret=secret, на что srcnode проверив свою ассоциацию отдает бандл сообщений для этой ноды.

Хотя есть еще более простой способ.
srcnode делает запрос на dstnode со списком msgid для dstnode. dstnode запрашивает в обратном запросе по нодлистовому адресу srcnode эти msgid и получает сообщения.

mirage> Продолжу тут тоже.
mirage> У этой схемы нашел один минус - кто угодно может напушить что угодно на ноду. Нужна аутентификация нод.

У нас есть уже в стандарте авторизация для ноды. Можно её и использовать.

Смотри тут https://ii-net.tk/idec-doc/?p=extensions про push.

+++ картошки хватит на всех