+++ At work. idec.el/0.1

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

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

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

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

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

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

> Самое главное, с моей точки зрения, оставить шифрование нетмейла опцией

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.

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

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

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

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

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

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