* Черновик стандарта личных сообщений
** Преамбула
Разговоры о личных сообщениях в сетях IDEC ведутся давно -- года два. Но к какому либо решению,
договоренности так и не пришли. Самая большая проблема -- это оставить IDEC простым, plaintext.
В этом документе попробуем набросать некий протип, который может быть войдет в стандарт.
** Чеклист
- [-] Описание стандарта в этом документе
- [-] Формат бадла
- [-] Формат сообщения на отправку
- [-] Формат node2node API
- [-] Формат client API
- [-] Согласие на принятие стандарта от core-team(ники с [[https://github.com/orgs/idec-net/people][Github]])
- [-] vit1-irk
- [-] btimofeev
- [-] spline1986
- [-] Difrex
- [-] Реализация PoC
- [-] Сервер
- [-] Клиент
** TODO Стандарт обмена
Сейчас у нас есть практически не используемые поля, такие как, tags и address.
- tags
Теги в IDEC в сообщении представляют из себя список с разделителем ~/~.
Так обязательные теги, которые проверяют все ноды/клиенты -- это ~ii/ok~.
Также у нас имеется тег ответа на сообщение - ~repto/IZXhLBKJx0rhx0lXYu3L~
Для личного сообщения предлагается добавить некий тег, например, ~type/xmail~
по которому нода сможет определять, что это сообщение является личным.
- address
Адрес сейчас не используется никак и только говорит о том, с какой ноды
пишет человек. Предлагается исправить этот недостаток. Мы можем использовать
адреса для отправки сообщения определенному поинту на его адрес.
*** TODO Формат бандла личного сообщения
На основе нижеизложенных фактов предлагается к рассмотрению следующий формат бандла
#+begin_src
ii/ok/repto/IZXhLBKJx0rhx0lXYu3L/type/xmail # Тут мы проставлем тег ответа, а так же сообщаем, что сообщение является личным
dynamic,1 # Вместо эхи мы используем адрес поинта, кому предназначено это сообщение
1455789357 # Время сообщения в unixtime
Pupkin # Имя пользователя отправившего сообщение
Lunar, 2 # Адрес поинта отправившего сообщение
Vasya # Имя пользователя, которому предназначенно сообщение
Re: Мое первое сообщение в эху # Заголовок сообщения
# Пустая строка
текст сообщения # Текст сообщения
#+end_src
*** TODO Формат сообщения на отправку
#+begin_src
dynamic,1 # Вместо эхи используем адрес
Vasya # Имя пользователя, которому предназначено сообщение
Тестируем # Заголовок сообщения
# Пустая строка
@repto:2hEUbMAxKSA83vcmgU4s # Проставляем тег ответа, либо строка относится к телу сообщения
И вот я пишу своё первое письмо в нашу секту. # Текст
Меня видно? # сообщения
#+end_src
*** TODO Формат node2node API
*** TODO Формат client API
Т.к. мы используем теги, то API отправки сообщения можно не менять, но поменять конечный эндпоинт,
вынеся его в расширения протокола.
Т.е.:
#+begin_src sh
curl -XPOST -d 'pauth=authstring' -d 'tmsg=BASE64' http://node.domain.tld/x/m/point
# Либо
curl -XGET http://node.domain.tld/x/m/point/authstring/BASE64
#+end_src
А для получения сообщений адресованных вам делаем запрос вида
#+begin_src sh
curl -XGET http://node.domain.tld/x/m/mail/authstring
# Либо
curl -XPOST -d 'pauth=authstring' http://node.domain.tld/x/m/
# Получение сообщений со сдвигом
curl -XPOST -d 'pauth=authstring' http://node.domain.tld/x/m/-10:10
#+end_src
Т.к. нода по authstring может узнать информацию о поинте, то она должна знать о том
какие сообщения адресованные этому поинту есть на этой ноде и возвращает их.
Так, ответ от ноды предлагается сделать аналогичным ~/u/e~:
#+begin_src sh
curl -XPOST -d 'pauth=authstring' http://node.domain.tld/x/m/-1:1
HTTP/1.1 200 Ok
Content-Type: text/plain
dynamic,1
IZXhLBKJx0rhx0lXYu3L
#+end_src
Получаем это сообщение
#+begin_src sh
curl -XPOST -d 'pauth=authstring' http://node.domain.tld/x/m/IZXhLBKJx0rhx0lXYu3L
HTTP/1.1 200 Ok
Content-Type: text/plain
IZXhLBKJx0rhx0lXYu3L:BASE64
#+end_src
Либо несколько сообщений, по аналогии с существующей схемой ~/u/e~
#+begin_src sh
curl -XPOST -d 'pauth=authstring' http://node.domain.tld/x/m/IZXhLBKJx0rhx0lXYu3L/IZahLHKJ10rZx0ZXAAA0/...
HTTP/1.1 200 Ok
Content-Type: text/plain
IZXhLBKJx0rhx0lXYu3L:BASE64
IZahLHKJ10rZx0ZXAAA0:BASE64
...:BASE64
#+end_src