subject: Netmail
12.03.2019 12:29
Difrex (dynamic,1)
Я думаю, что нужно начинать с этим что-то делать.
Для этого я создал репозиторий с документом в котором предлагаю общими усилиями
разработать стандарт обмена личными сообщениями, а так же реализовать PoC сервера(ноды)
и клиента.
Вот этот репозиторий: https://github.com/idec-net/netmail
Давайте обсуждать и дописывать.
+++ At work. idec.el/0.1
--------------------------------------------------------------------------------
subject: Re: Netmail
12.03.2019 15:07
Andrew Lobanov (tavern,1) => hOxZjLmgYv3Qwb32vJIK
Difrex> Я думаю, что нужно начинать с этим что-то делать.
Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)
Закладываю три вещи в это дело:
1. Реализация на python, чтобы любой желающий мог ознакомиться и внести изменения.
2. По возможности максимальная модульность реализации.
3. Настолько лаконичный и простой код, насколько я смогу.
В данный момент реализовано всё, кромен фэх и нет вебморды, но оно уже существенно лучше iing в плане реализации. Кода меньше, он проще и быстрее.
Difrex> Для этого я создал репозиторий с документом в котором предлагаю общими усилиями
Difrex> разработать стандарт обмена личными сообщениями, а так же реализовать PoC сервера(ноды)
Difrex> и клиента.
Difrex> Вот этот репозиторий: https://github.com/idec-net/netmail
Хорошее дело.
Difrex> Давайте обсуждать и дописывать.
Обсуждать готов, а вот писать пока не очень.
Самое главное, с моей точки зрения, оставить шифрование нетмейла опцией. Лучше всего, вообще не делать его частью стандарта. Нужно оставить сам стандарт максимально простым.
--------------------------------------------------------------------------------
subject: Re: Netmail
12.03.2019 15:27
Difrex (dynamic,1) => AlSz3bFtGoQYYRerAmGl
> Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)
Это дело хорошее :)
> В данный момент реализовано всё, кромен фэх и нет вебморды
А нужна ли веб-морда в эталонной реализации ноды?
> Обсуждать готов, а вот писать пока не очень.
Присоединяйся в обсуждение этого ПР https://github.com/idec-net/netmail/pull/1
> Самое главное, с моей точки зрения, оставить шифрование нетмейла опцией
Я думал, что без шифрования это все делать. Шифровать можно GPG само тело сообщения.
Так мы вообще никак не переусложним стандарт.
--------------------------------------------------------------------------------
subject: Re: Netmail
13.03.2019 12:34
Andrew Lobanov (tavern,1) => KtkAKSVHs1jOmQe7q3xj
>> Нужно, но я пока попиливаю между делом кандидата в эталонную реализацию idec =)
Difrex> Это дело хорошее :)
Нужное как минимум =)
>> В данный момент реализовано всё, кромен фэх и нет вебморды
Difrex> А нужна ли веб-морда в эталонной реализации ноды?
В реализации ноды, может, и не нужна. А клиент хочу с вебмордой сделать. Это потребует меньше кода и усилий для создания удобоваримого интерфейса. А от морды клиента до морды узла один шаг =)
>> Обсуждать готов, а вот писать пока не очень.
Difrex> Присоединяйся в обсуждение этого ПР https://github.com/idec-net/netmail/pull/1
Обязательно, но пока занят всякой фигнёй =(
>> Самое главное, с моей точки зрения, оставить шифрование нетмейла опцией
Difrex> Я думал, что без шифрования это все делать. Шифровать можно GPG само тело сообщения.
Да. Всё верно =)
Difrex> Так мы вообще никак не переусложним стандарт.
При случае отпишу туда конь цепцию, которая сложилась в голове на эту тему.
--------------------------------------------------------------------------------
subject: Re: Netmail
16.03.2019 16:43
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Привет!
Это первое сообщение от G2I - бота слежения за задачами в репозитории на Github.
Сейчас я наблюдаю за проектом https://github.com/idec-net/netmail.
Новые события будут публиковаться в этой теме.
+++ G2I: https://github.com/idec-net/github2idec. GPLv3
--------------------------------------------------------------------------------
subject: Re: Netmail
16.03.2019 16:43
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Новый комментарий от пользователя 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
--------------------------------------------------------------------------------
subject: Re: Netmail
16.03.2019 16:43
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Новый комментарий от пользователя 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
--------------------------------------------------------------------------------
subject: Re: Netmail
16.03.2019 16:43
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Новый комментарий от пользователя 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
--------------------------------------------------------------------------------
subject: Re: Netmail
16.03.2019 16:43
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Новый комментарий от пользователя 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
--------------------------------------------------------------------------------
subject: Re: Netmail
16.03.2019 16:43
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Новый комментарий от пользователя 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
--------------------------------------------------------------------------------
subject: Re: Netmail
16.03.2019 16:43
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Новый комментарий от пользователя 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
--------------------------------------------------------------------------------
subject: Re: Netmail
16.03.2019 16:54
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Новый комментарий от пользователя 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-81311e552b…
+++ G2I: https://github.com/idec-net/github2idec. GPLv3
--------------------------------------------------------------------------------
subject: Re: Netmail
16.03.2019 22:35
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Новый комментарий от пользователя 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
--------------------------------------------------------------------------------
subject: Re: Netmail
18.03.2019 07:04
Andrew Lobanov (tavern,1) => KhJliVZCisynujwlx2TU
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>]
<тело сообщения>
====
В гитхаб пока так и не заглядывал, но не проще ли обсуждать здесь?
ЗЫЖ Я за любую движуху, но без излишнего усложнения протокола.
--------------------------------------------------------------------------------
subject: Re: Netmail
18.03.2019 10:20
Difrex (dynamic,1) => qfB7IpIjNsht6mZaQC59
Посмотри пожалуйста https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19…
если согласен, то давай межить этот ПР.
> В гитхаб пока так и не заглядывал, но не проще ли обсуждать здесь?
Так я для того, чтобы и тут и там обсуждать можно было бота написал.
--------------------------------------------------------------------------------
subject: Re: Netmail
18.03.2019 11:31
Difrex (dynamic,1) => qfB7IpIjNsht6mZaQC59
AL> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
В принципе, если личка будет вся синхронизироваться нормально, то можно и своей
ноды ее тянуть.
+++ At work. idec.el/0.1
--------------------------------------------------------------------------------
subject: Re: Netmail
20.03.2019 10:42
Andrew Lobanov (tavern,1) => tAeA40lfJnPhRhAdvzHR
AL>> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
Difrex> В принципе, если личка будет вся синхронизироваться нормально, то можно и своей ноды ее тянуть.
Ну я предлагаю хождение лички организовать как обмен данными между узлами, которые доверяют друг другу. То есть не отдавать кому попало. Но в случе, если сисопы договорились, оно работать должно без проблем.
--------------------------------------------------------------------------------
subject: Re: Netmail
20.03.2019 11:33
vit01 (mira, 1) => qfB7IpIjNsht6mZaQC59
AL> 1. Между узлами сети личные сообщения ходят как простая эха, но по паролю.
AL> 2. Клиент забирает со своего узла свои сообщения по паролю. То есть не получит чужих сообщений никак.
AL> 3. Шифрование не является частью протокола.
AL> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?
Это и правда упрощает реализацию, хотя и теряется гибкость.
Почему-то всегда думалось, что мы примем путь настоящей децентрализации (как в обычных эхах), чтобы пути хождения сообщений были заранее не регламентированы и можно было бы строить гораздо более нетривиальные схемы
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
--------------------------------------------------------------------------------
subject: Re: Netmail
20.03.2019 12:26
Andrew Lobanov (tavern,1) => FZxRdFdhqxbvZuozfelV
AL>> Забирать личку с любого узла сети не вижу смысла, так как это переусложнит стандарт.
vit01> Так, надо уточнить: это значит, что схема узлов, между которыми ходит нетмейл, будет эквивалентна топологии "звезда", где каждый узел попарно соединяется с каждым?
Не надо каждому с каждым. Просто весь нетмейл ходит по всем узлам. То есть это такой подвид эхомейла, которым ноды обмениваются по паролю, а клиенты получают только свою часть от этой эхи.
Но это всего лишь мои мысли.
--------------------------------------------------------------------------------
subject: Re: Netmail
20.03.2019 15:45
vit01 (mira, 1) => rB0Mb6sBgDzFP3QMiF2n
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
--------------------------------------------------------------------------------
subject: Re: Netmail
20.03.2019 17:48
Difrex (dynamic,1) => Jd1mZhCE59uMDdAuFg4J
На счёт протокола получения лички клиентом возражений нет? Мержим?
+++ картошки хватит на всех
--------------------------------------------------------------------------------
subject: Re: Netmail
20.03.2019 17:47
Difrex (dynamic,1) => fRVQwFvO62SatuK6PnJP
vit01> 1. Сообщения пройдут через node2 в незашифрованном виде, сисоп node2 их спокойно читает. Итого MITM
vit01> 2. Сообщения "node1 to node3" не доходят в принципе, потому что node2 имеет право получать нетмейл только для собственных поинтов
vit01> Первый вариант - ситуация неприемлемая, потому что так убивается сама идея нетмейла как такового. "Личка" подразумевает, что мы не хотим выносить общение напоказ. Но концепция ii/IDEC исходит из того, что собственному боссу поинт node1 доверяет (боссу получателя он тоже вынужден доверять, потому что поинт node3 ему доверяет). А вот транзитным сисопам доверять никто не должен, ведь личные сообщения на то и личные.
vit01> Второй вариант гарантирует приватность, но при этом ограничивает возможности построения разных топологий станций. Здесь мы либо ограничиваемся схемой "звезда", либо нетмейл на некоторых узлах принципиально не поддерживается.
Можно обменяться ключами нод. Ну, шифровать ими личку с армором, тогда всё остаётся в plain text, но усложняет стандарт.
С другой стороны gpg есть ваще везде.
+++ картошки хватит на всех
--------------------------------------------------------------------------------
subject: Re: Netmail
21.03.2019 07:27
Andrew Lobanov (tavern,1) => fRVQwFvO62SatuK6PnJP
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> Второй вариант гарантирует приватность, но при этом ограничивает возможности построения разных топологий станций. Здесь мы либо ограничиваемся схемой "звезда", либо нетмейл на некоторых узлах принципиально не поддерживается.
Второй вариант неприемлемый, потому что или гарантировано усложняет топологию сети или делает нетмейл бесполезным.
Ёлы, всё уже сто лет как придумано. Передавать сообщения в скомпрометированных сетях можно безопасно уже очень-очень много лет, а народ всё ещё пихает шифрование куда ни поподя, усложняя стандарты.
--------------------------------------------------------------------------------
subject: Re: Netmail
21.03.2019 07:28
Andrew Lobanov (tavern,1) => BLxrVHKaYsUHeNXDSvvA
Difrex> На счёт протокола получения лички клиентом возражений нет? Мержим?
У меня вообще возражений нет. Только соображения. Что ни примите, я или сделаю это у себя или забью.
--------------------------------------------------------------------------------
subject: Re: Netmail
21.03.2019 08:20
Difrex (dynamic,1) => hNKAqS1L6uKcVXm2zu62
Какие есть соображения по этому: https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19…
--------------------------------------------------------------------------------
subject: Re: Netmail
03.04.2019 09:39
Andrew Lobanov (tavern,1) => Yk2t3klbiqBwqYdBTZlH
Difrex> Какие есть соображения по этому: https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19…
Никаких соображений. Всё замечательно. Так я это себе и представлял =)
Я тут немного выпадаю из сети. Не теряйте. Рано или поздно я отвечу =)
--------------------------------------------------------------------------------
subject: Re: Netmail
03.04.2019 10:06
Difrex (dynamic,1) => m2JmJA3vDFKnEQGtItzG
AL> Difrex> Какие есть соображения по этому: https://github.com/idec-net/netmail/blob/520079017d13f375930d0d4fee19…
AL> Никаких соображений. Всё замечательно. Так я это себе и представлял =)
Ок. Я мержу тогда.
+++ At work. idec.el/0.1
--------------------------------------------------------------------------------
subject: Re: Netmail
03.04.2019 14:37
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Новый комментарий от пользователя 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
--------------------------------------------------------------------------------
subject: Re: Netmail
21.07.2019 10:47
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Новый комментарий от пользователя 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
--------------------------------------------------------------------------------
subject: Re: Netmail
21.07.2019 10:47
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Новый комментарий от пользователя 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
--------------------------------------------------------------------------------
subject: Re: Netmail
21.07.2019 12:57
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Новый комментарий от пользователя 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
--------------------------------------------------------------------------------
subject: Re: Netmail
05.03.2020 14:03
G2I (dynamic,2) => hOxZjLmgYv3Qwb32vJIK
Новый комментарий от пользователя 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
--------------------------------------------------------------------------------
subject: Re: Netmail
06.03.2020 11:10
Andrew Lobanov (tavern,1) => SZ0YMEVahSf7sjmrymvQ
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, что нет необходимости прохождения нетмейла по лишним нодам. Заодно будет повод актуализировать нодлист :)
--------------------------------------------------------------------------------
subject: Re: Netmail
06.03.2020 14:11
Difrex (dynamic,1) => zBVFKFZoxyUY3zsr9Y4y
> Я тут отвечу пока. Вообще, доля здравого смысла в этом есть. Плюсы очевидны. Опять таки, если оглядываться на фидонет, то там нетмейл тоже сбоку от эхомейла. И даже маршруты прохождения почты разные зачастую. Может, попробуем такой вариант?
Можно попробовать. Нужно формальное описание.
> Заодно будет повод актуализировать нодлист :)
Давайте стандартизируем его :)
--------------------------------------------------------------------------------
subject: Re: Netmail
07.03.2020 00:54
mirage (mira, 26) => zBVFKFZoxyUY3zsr9Y4y
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 и получает сообщения.
--------------------------------------------------------------------------------
subject: Re: Netmail
07.03.2020 08:27
Difrex (dynamic,1) => ZSAzem4B6BKskS9hzTeB
mirage> Продолжу тут тоже.
mirage> У этой схемы нашел один минус - кто угодно может напушить что угодно на ноду. Нужна аутентификация нод.
У нас есть уже в стандарте авторизация для ноды. Можно её и использовать.
Смотри тут https://ii-net.tk/idec-doc/?p=extensions про push.
+++ картошки хватит на всех
--------------------------------------------------------------------------------
subject: Re: Netmail
19.03.2020 23:36
mirage (mira, 26) => A5xSdc3zSt01nvptt30K
mirage>> Продолжу тут тоже.
mirage>> У этой схемы нашел один минус - кто угодно может напушить что угодно на ноду. Нужна аутентификация нод.
Difrex> У нас есть уже в стандарте авторизация для ноды. Можно её и использовать.
Difrex> Смотри тут https://ii-net.tk/idec-doc/?p=extensions про push.
То есть каждая нода для каждой должна выдать по паролю? Это же не масштабируется.
--------------------------------------------------------------------------------