idec.talks

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

fRVQwF... . ОТВЕТИТЬ

\/ . Andrew Lobanov to vit01 @ Re: Netmail 20/03/19 09:26

\/ . vit01 to Andrew Lobanov @ Re: Netmail 20/03/19 08:33

\/ . Andrew Lobanov to Difrex @ Re: Netmail 20/03/19 07:42

\/ . Difrex to Andrew Lobanov @ Re: Netmail 18/03/19 08:31

\/ . Difrex to Andrew Lobanov @ Re: Netmail 18/03/19 07:20

\/ . Andrew Lobanov to G2I @ Re: Netmail 18/03/19 04:04

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>]
<тело сообщения>

====

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

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

qfB7Ip... . ОТВЕТИТЬ

\/ . Difrex to All @ Апгрейд на dynamic 17/03/19 07:42

\/ . G2I to All @ Re: Netmail 16/03/19 19:35

\/ . vit01 to Difrex @ Re: dynamic 16/03/19 16:20

\/ . vit01 to Difrex @ Re: IDEC Mobile 16/03/19 15:56

\/ . Difrex to vit01 @ Re: IDEC Mobile 16/03/19 15:41

\/ . vit01 to Difrex @ Re: IDEC Mobile 16/03/19 14:30

\/ . Difrex to vit01 @ Re: IDEC Mobile 16/03/19 14:10

\/ . G2I to All @ Re: Netmail 16/03/19 13:54

\/ . G2I to All @ Re: Netmail 16/03/19 13:43

\/ . vit01 to All @ IDEC Mobile 16/03/19 09:33

\/ . Andrew Lobanov to Difrex @ Re: Netmail 13/03/19 09:34

\/ . Difrex to Andrew Lobanov @ Re: Netmail 12/03/19 12:27

\/ . Andrew Lobanov to Difrex @ Re: Netmail 12/03/19 12:07

\/ . Andrew Lobanov to Anotheroneuser @ Re: Документация 12/03/19 12:07

\/ . Difrex to All @ Netmail 12/03/19 09:29

\/ . Anotheroneuser to Andrew Lobanov @ Re: Документация 12/03/19 08:50

\/ . Difrex to Andrew Lobanov @ Re: Документация 12/03/19 07:58

\/ . Andrew Lobanov to All @ Документация 12/03/19 04:21

\/ . Difrex to All @ go-idec 04/03/19 13:41

Раз у нас намечается(наконец-то :) развитие, то я покрыл тестами гошную либу на 90%.
Буду очень рад, если кто-то еще будет туда коммитить. Сейчас там не хватает поддержки фэх.

Пример получения последних сообщений:

====

package main

import (
	"fmt"
	"time"

	idec "github.com/idec-net/go-idec"
)

func main() {
	fc := idec.FetchConfig{
		Node:   "https://dynamic.lessmore.pw/idec/",
		Echoes: []string{"pipe.2032", "idec.talks"},
		Offset: -3,
		Limit:  3,
	}
	ids, err := fc.GetMessagesIDS()
	if err != nil {
		panic(err)
	}
	msgs, err := fc.GetRawMessages(ids)
	if err != nil {
		panic(err)
	}
	for _, m := range msgs {
		msg, err := idec.ParseMessage(m.Message)
		if err != nil {
			panic(err)
		}
		fmt.Printf("Author: %s, Subg: %s, Date: %s\n", msg.From, msg.Subg, time.Unix(int64(msg.Timestamp), 0))
	}
}

====

Запуск

====

go run test.go
Author: Difrex, Subg: Re: idec, Date: 2019-03-04 11:56:06 +0300 +03
Author: Difrex, Subg: Re: idec, Date: 2019-03-04 11:21:04 +0300 +03
Author: Peter, Subg: Re: idec, Date: 2019-03-04 11:09:22 +0300 +03
Author: Andrew Lobanov, Subg: Re: Метадата, Date: 2019-03-03 08:25:10 +0300 +03
Author: Peter, Subg: Re: Метадата, Date: 2019-03-02 23:17:49 +0300 +03
Author: Andrew Lobanov, Subg: Re: Метадата, Date: 2019-03-02 20:02:04 +0300 +03

====

Iu0Zni... . цепочка . ОТВЕТИТЬ

\/ . Andrew Lobanov to Peter @ Re: Метадата 03/03/19 05:25

>> Детализации особо и нет. Я честно не понимаю стремления отказаться от файлов.
Peter> Ой, моя реплика относилась к идее делать несколько тегов на каждый тип. Ну типа тег - картинка, тег - архив. Что-то ещё.. Тогда мы должны делать все эти n запросов. Да ещё и выбирать, что пропускать... Вот это, кмк, будет хуже текущих фрек.

Вообще, я примерно так и думаю.

Например:

====

image:<filename>:<base64>
audio:<filename>:<base64>

====

А желание не пропустить информацию, ИМХО, противоречит самой цели секты.

ggygRC... . ОТВЕТИТЬ

\/ . Peter to Andrew Lobanov @ Re: Метадата 02/03/19 20:17

\/ . Andrew Lobanov to Peter @ Re: Метадата 02/03/19 17:02

\/ . Peter to Andrew Lobanov @ Re: Метадата 01/03/19 15:27

\/ . Difrex to Andrew Lobanov @ Re: Метадата 01/03/19 15:14

\/ . Andrew Lobanov to Difrex @ Re: Метадата 01/03/19 08:57

\/ . Difrex to Andrew Lobanov @ Re: Метадата 01/03/19 07:41

\/ . Andrew Lobanov to Difrex @ Re: Метадата 28/02/19 11:47

\/ . Difrex to Andrew Lobanov @ Метадата 28/02/19 11:27

>Фетчер тоссит сообщение, видит метку и добавляет msgid в список сообщений с дополнительными данными. После того, как растоссил, передаёт айдишники в какую-нить схему типа x/d/.
Вот это еще не особо нравится.

Со стороны клиента мне это видится так:

====

           +--------------+
           |              |
           | IDEC Client  |
   +------>|              |<------+
   |       +--------------+       |
   |                              |
 xdata tag                      message
   |                             data
   |                              |
   |                              v
 +-+-------------+      +-----------------+
 | /u/m/gkC...   |      | /x/d/gkC...     |
 |               |      |                 |
 +---------------+      +-----------------+

====

Т.е. клиент видя соотвествующий тег лезет в /x/d/gkCo68TG1nrIXrgMklUN, получает от туда список аттачей, а затем делает еще
один запрос /x/d/gkCo68TG1nrIXrgMklUN/attachName для получения аттача. На ровном месте мы получили 3 запроса.

VJPNts... . ОТВЕТИТЬ

\/ . Andrew Lobanov to vit01 @ Re: Переезд 27/02/19 09:56

\/ . Difrex to vit01 @ Re: lor-opennet 27/02/19 08:13

\/ . vit01 to btimofeev @ Re: IDEC Mobile 15/02/19 14:30

\/ . Difrex to Andrew Lobanov @ Re: А где у нас актуальный nodegraph.svg? 29/01/19 11:49

\/ . vit01 to All @ Переезд 24/01/19 18:07

\/ . vit01 to Andrew Lobanov @ Re: lor-opennet 26/02/19 22:29

\/ . vit01 to Andrew Lobanov @ Re: А где у нас актуальный nodegraph.svg? 01/02/19 21:35

\/ . Andrew Lobanov to vit01 @ lor-opennet 26/02/19 17:27

\/ . Difrex to All @ Обновление динамика 20/02/19 11:20

\/ . Anotheroneuser to Difrex @ Re: А где у нас актуальный nodegraph.svg? 29/01/19 20:17

\/ . Difrex to Anotheroneuser @ Re: А где у нас актуальный nodegraph.svg? 29/01/19 09:54

\/ . Andrew Lobanov to Difrex @ Re: А где у нас актуальный nodegraph.svg? 29/01/19 03:44

\/ . Anotheroneuser to Difrex @ Re: А где у нас актуальный nodegraph.svg? 28/01/19 17:20

\/ . Difrex to All @ А где у нас актуальный nodegraph.svg? 28/01/19 13:39

\/ . Difrex to vit01 @ Re: Полнотекстовый поиск и подписи 25/01/19 07:14

\/ . vit01 to Difrex @ Re: Полнотекстовый поиск и подписи 23/01/19 16:32

\/ . vit01 to btimofeev @ Re: Лежит станция Мира 21/01/19 15:47

\/ . btimofeev to vit01 @ Re: Лежит станция Мира 21/01/19 11:34

\/ . btimofeev to vit01 @ Re: IDEC Mobile 21/01/19 09:27

\/ . vit01 to All @ Полнотекстовый поиск и подписи 08/01/19 07:24

\/ . vit01 to vit01 @ Re: IDEC Mobile 02/01/19 16:11

\/ . vit01 to vit01 @ Re: IDEC Mobile 31/12/18 11:00

\/ . Anotheroneuser to btimofeev @ Re: IDEC Mobile 17/12/18 08:38

\/ . vit01 to btimofeev @ Re: IDEC Mobile 16/12/18 02:59

\/ . btimofeev to vit01 @ Re: IDEC Mobile 15/12/18 19:56

vit01 to All @ IDEC Mobile 08/12/18 08:12