Расширение протокола до версии 2.0

[stepanskryabin]

черновик предстоящих изменений в протокол.

1. Права пользователей

1.1 Основные типы пользователей

• модератор | moderator
• владелец | owner
• читающий | reader
• пищущий | writer

1.2 Права

• чтение | read
• редактирование | edit
• удаление | delete

2. Добавление новых сущностей

2.1 Новый тип flow - workspace

К основным трём потокам добавляется третий поток с наименованием Workspace который предназначен для объединения Chat, Group, Channel в единое целевое пространство.

Для этого в flow добавляются следующие поля:

Ключ	Тип	Обязательный (запрос / ответ)	Описание
sub_flow	list[str]	No / No	Список uuid потоков flow входящих в Workspace

2.2 Добавление дополнительных полей в message

Для улучшения удобства обсуждения добавляется поле threads, а так же поле content которое служит для облегчения обработки сообщений и добавления дополнительных данных о контенте.

Поле threads

Ключ	Тип	Обязательный (запрос / ответ)	Описание
message_uuid	str	No / No	uuid исходного message от которого пошел thread

Поле content

Ключ	Тип	Обязательный (запрос / ответ)	Описание
body	str	Yes / Yes	Тело контента (текст) или имя файла (для другого типа контента)
formatted_body	str	No / No	Тело контента (только для текста) с включенными тэгами оформления
info	info	Yes / Yes	Информация о контенте
thumbnail_info	thumbnail_info	No / No	Превью (для изображения или видео)
msgtype	str	Yes / Yes	Тип контента (text, image, video, documents, audio)
url	str	No / No	Ссылка на скачивание

Поле info

Ключ	Тип	Обязательный (запрос / ответ)	Описание
mimetype	str	Yes / Yes	Mime-тип контента
size	int	No / No	размер в байтах
width	int	No / No	Ширина (для видео и изображения) в пикселах, для остальных типов данных значение null
height	int	No / No	Высота (для видео и изображения) в пикселах, для остальных типов данных значение null
duration	int	No / No	Длительность (для видео и аудио) в секундах, для остальных типов данных значение null

Поле thumbnail_info

Ключ	Тип	Обязательный (запрос / ответ)	Описание
thumbnail_url	str	No / No	Ссылка на скачивание
mimetype	str	No / No	Mime-тип контента
size	int	No / No	Размер, в байтах
width	int	No / No	Ширина (для видео и изображения) в пикселах, для остальных типов данных значение null
height	int	No / No	Высота (для видео и изображения) в пикселах, для остальных типов данных значение null

2.3 Добавление дополнительных полей в user

Ключ	Тип	Обязательный (запрос / ответ)	Описание
flow_invite	list[int]	No / No	Потоки в которых пользователь был приглашен
flow_join	list[int]	No / No	Потоки к которым пользователь присоединился
flow_leave	list[int]	No / No	Потоки из которых пользователь вышел самостоятельно
flow_ban	list[int]	No / No	Потоки из которых пользователь был удален администратором
flow_knock	list[int]	No / No	Потоки в которые пользователь запросил доступ

пример:

{
"content": {
    "body": "image.jpeg",
    "info": {
        "mimetype": "image/jpeg",
        "size": "1024000",
        "widht": 1980,
        "height": 1280,
        "duration": null
        },
    "thumbnail_info": {
        "thumbnail_url": "/server/files/asdgalkdfg87adft7a6df",
        "mimetype": "image/jpeg",
        "size": 1024,
        "width": 320,
        "height": 480
        },
   "msgtype": "image",
   "url": "/server/files/xzdf89gud98fffg45g45h45h45h"
   }
}

2.3. Удаление лишних полей из message:

• file_picture
• file_video
• file_audio
• file_document
• emoji

2.4. Изменение наименования полей в user:

Так как хранение пароля будет осуществлятся клиентом самостоятельно, сервер будет хранить только хэш пароля (клиент передаёт не голый пароль а его хэш) полученного от клиента. Для этого имя поля password заменяется на hash_password.

2.5 Новый объект server после data

Поле предназначено для передачи общей информации о сервере.

Ключ	Тип	Обязательный (запрос / ответ)	Описание
name	str	Yes / Yes	Имя сервера
crypto_protocol	str	No / No	наименование протокола поддерживаемого сервером
protocol_min_version	str	No/No	Минимальная версия протокола которую поддерживает сервер
protocol_max_version	str	No/No	Максимальная версия протокола которую поддерживает сервер

2.6. Новый объект ciphers после server

Поле предназначено для передачи информации о используемых протоколах шифрования.

Ключ	Тип	Обязательный (запрос / ответ)	Описание
open_key	str	No / Yes	открытый ключ шифрования
open_key_time_stamp	int	No / Yes	время формирования ключа подписи / шифрования
crypto_protocol	str	No / Yes	тип протокола шифрования
session_key	str	No / Yes	сессионный (симметричный) ключ шифрования
session_key_time_stamp	int	No / Yes	время формирования ключа шифрования

2.7. Новый объект event после ciphers

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

Ключ	Тип	Обязательный (запрос / ответ)	Описание
flow	list[str]	No / No	Список с uuid потоков, по котором сервер должен отправить обновление
user	list[str]	No / No	Список с uuid пользователей, по которым сервер должен отправить обновление
time	int	No / No	Время с которого сервер должен отправить обновление
start	int	No / No	Начальная позиция при запросе большой партии
end	int	No / No	Конечная позиция при запросе большой партии

3. Новые методы

3.1. метод handshake

• клиент направляет запрос handshake_hello cо своим открытым ключем шифрования и временем его жизни.
• сервер отвечает handshake_hello со своим открытым ключем шифрования, временем его жизни, а также симметричным (сессионным) ключем шифрования зашифрованным открытым ключем клиента и временем жизни сессионного ключа.
• после чего клиент отвечает серверу handshake_end и отправляет свой симметричный (сессионный) ключ шифрования зашифрованный сессионным ключем сервера, а также время жизни сессионного ключа.
• в ответ сервер отвечает пустым handshake_end со статусом 200.

запрос клиента:

{
"type": "handshake_hello",
"ciphers": {
    "open_key": "DKMDKDJDJDJDJ",
    "open_key_time_stamp": 34534543645645645,
    "crypto_protocol": "PKSC#7",
    "session_key": null,
    "session_key_time_stamp": null
             },
"jsonapi": {
   "version": "2.0",
   "revision": "1"
              },
"meta": null
}

ответ сервера:

{
"type": "handshake_hello",
"ciphers": {
    "open_key": "PLPLPLPLPLPLPLLLPLPP",
    "open_key_time_stamp": 34534543645645645,
    "crypto_protocol": "PKSC#7",
    "session_key": "iof87fx78cfb87cxgb78xc78cxv",
    "session_key_time_stamp": 3534543654645
            },
"errors": {
    "code": 200,
    "status": "Ok",
    "time": 235235345345,
    "detail": "successfully"
            },
"jsonapi": {
    "version": "2.0",
    "revision": "1"
     },
"meta": null
}

ответ клиента:

{
"type": "handshake_end",
"ciphers": {
    "open_key": null,
    "open_key_time_stamp": null ,
    "crypto_protocol": "PKSC#7",
    "session_key": "zdf98gzd98fbyz80fgb087xcgb",
    "session_key_time_stamp": 8943894389459874
               },
"jsonapi": {
   "version": "2.0",
   "revision": "1"
              },
"meta": null
}

ответ сервера:

{
"type": "handshake_end",
"errors": {
   "code": 200,
   "status": "Ok",
   "time": 235235345345,
   "detail": "successfully"
          },
"jsonapi": {
   "version": "2.0",
   "revision": "1"
     },
"meta": null
}

3.2 метод - update_session_key

• клиент направляет на сервер запрос на обновление сессионных ключей, запрос подписан ключем сервера и зашифрован старым сессионным ключем.
• сервер в ответ отправляет клиенту новый сессионный ключ подписаный и зашифрованный открытым ключем клиента, в ответе статус "Accepted" и код "202"

запрос клиента:

{
"type": "update_session_key",
"data": {
    "user": [{
        "uuid": "334534534",
        "aith_id": 87934897789
             }]
        },
"jsonapi": {
    "version": "2.0",
    "revision": "1"
           },
"meta": null
}

Ответ сервера:

{
"type": "update_session_key",
"data": {
    "user": [{
        "uuid": "334534534"
             }],
        "meta": null
         },
"ciphers": {
    "session_key": "98df89897f7890fg890f",
    "session_key_time_stamp": 984389748974897
             },
"errors": {
    "code": 202,
    "status": "Accepted",
    "time": 34894798345,
    "detail": "Information is accepted."
         },
"jsonapi": {
    "version": "2.0",
    "revision": "1"
              },
"meta": null
}

3.3 метод update_open_key

• клиент направляет на сервер запрос на обновление открытого ключа, запрос содержит новый открытый ключ шифрования, подписан ключем сервера и зашифрован сессионным ключем.
• сервер в ответ отправляет клиенту новый сессионный ключ подписаный и зашифрованный открытым ключем клиента, в ответе статус "Accepted" и код 202

запрос клиента:

{
"type": "update_open_key",
"data": {
    "user": [{
        "uuid": "334534534",
             }]
        },
"ciphers": {
    "open_key": "xcv90xv9088cvx89cxv89xvc",
    "open_key_time_stamp": "4390849804590845",
    "crypto_protocol": "PKSC#7"
           },
"jsonapi": {
    "version": "2.0",
    "revision": "1"
             },
"meta": null
}

Ответ сервера:

{
"type": "update_session_key",
"data": {
    "user": [{
        "uuid": "334534534",
               }]
           },
"ciphers": {
    "session_key": "98df89897f7890fg890f",
    "session_key_time_stamp": 984389748974897
               },
"errors": {
    "code": 202,
    "status": "Accepted",
    "time": 34894798345,
    "detail": "Information is accepted."
         },
"jsonapi": {
    "version": "2.0",
    "revision": "1"
        },
"meta": null
}

3.4 Разделение метода get_update на несколько методов

get_update_flow

Метод get_update_flow позволяет получить от сервера доступную информацию о flow, от времени time по натстоящее время.

Запрос клиента:

{
"type": "get_update_flow",
"data": {
    "time": 1594492370,
    "flow": [{
        "uuid": "34543646"},
         {...}],
    "user": [{
        "uuid": "1234567",
        "auth_id": "dks7sd9f6g4fg67vb78g65"
          }]
        },
"jsonapi": {
    "version": "1.0",
    "revision": "17"
            },
"meta": null
}

get_update_message

Метод get_update_message позволяет получить от сервера доступную информацию о сообщениях которые принадлежать определенному flow, от времени time по настоящее время.

Запрос клиента:

{
"type": "get_update_message",
"data": {
    "time": 1594492370,
    "flow": [{
        "uuid": "34543646"},
         {...}],
    "user": [{
        "uuid": "1234567",
        "auth_id": "dks7sd9f6g4fg67vb78g65"
          }]
        },
"jsonapi": {
    "version": "1.0",
    "revision": "17"
             },
"meta": null
}

get_update_user

Метод get_update_user позволяет получить от сервера доступную информацию о пользователях, от времени time по настоящее время.

Запрос клиента:

{
"type": "get_update_user",
"data": {
    "time": 1594492370,
    "user": [{
        "uuid": "1234567",
        "auth_id": "dks7sd9f6g4fg67vb78g65"
          }]
        },
"jsonapi": {
    "version": "1.0",
    "revision": "17"
             },
"meta": null
}

3.5 Метод invite_user_to_flow

Метод предназначен для приглашения пользователя вступить в поток.

• Клиент отправляет серверу запрос invite_client_to_flow с указанием ID пользователей
• Сервер отвечает invite_user_to_flow со статусом 200

Запрос клиента:

{
"type": "invite_user_to_flow",
"data": {
    "time": 1594492370,
    "flow": [{
        "uuid": "34543646",
        "user_uuid": []
               }],
    "user": [{
        "uuid": "1234567",
        "auth_id": "dks7sd9f6g4fg67vb78g65"
          }]
        },
"jsonapi": {
    "version": "1.0",
    "revision": "17"
             },
"meta": null
}

{
"type": "get_update_message",
"data": {
    "time": 1594492370,
    "flow": [{
        "uuid": "34543646"},
         {...}],
    "user": [{
        "uuid": "1234567",
        "auth_id": "dks7sd9f6g4fg67vb78g65"
          }]
        },
"jsonapi": {
    "version": "1.0",
    "revision": "17"
             },
"meta": null
}

4. Прочие изменения (не)протокола

4.1 Хранение / шифрование файлов сервером

• все файлы хранятся на сервере в директории /static/files
• у всех файлов вместо имени хэш, расширения нет
• информация о файле хранится в БД
• ссылка на файл хранится в БД
• каждый файл зашифрован

4.2 Шифрование flow

Пользователю будет доступно настройка шифрования для чатов, групп, каналов, сообществ

Шифрование chat

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

• вложенное поле ciphers
  • вложенное поле user1
    • вложенное поле open_key
    • вложенное поле open_key_time_stamp
    • вложенное поле crypto_protocol
    • вложенное поле session_key
    • вложенное поле session_key_time_stamp
  • вложенное поле user2
    • вложенное поле open_key
    • вложенное поле open_key_time_stamp
    • вложенное поле crypto_protocol
    • вложенное поле session_key
    • вложенное поле session_key_time_stamp

Шифрование group

• как?

Шифрование channel

• как?

Шифрование workspace

• необходимо?

Добавить логаут и логаут на всех устроиствах

?

Добавить защиту от регистрации множества аккаунтов

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

[NekrodNIK]

Опишу что же такое WORKSPACE.
Рассмотрим, как это будет выглядеть у пользователя. В его списке чатов, кроме самих чатов будут находиться отдельные пункты с пометкой workspace. При нажатии на этот пункт, от кнопки идёт волна, фон и цветовая гамма меняется в зависимости личных настроек workspace. Вместе с фоном и гаммой волна меняет и список чатов, который меняется на тот, который содержится в workspace. Появляется кнопка назад, для выхода из workspace. Внутри workspace, чаты изолированы от других чатов, к ним не получить доступа не состоя в workspace. Присоединяясь к workspace, user автоматически входит в чаты, которые выбрал администратор workspace. При желании, он может выйти из них, или войти в другие. Поиск теперь ищет не по всей бд, а по конкретному workspace. Workspace можно экспортировать, полностью перенеся на другой сервер.
Теперь к самой идее. Что же такое workspace? Это отдельное пространство, вне которого данные и чаты не выходят. Это собственный изолированный уголок MoreliaTalk. Что это даёт пользователю? Он может создать собственное сообщество, с подразделением на темы, или форум, или же вообще обсуждение разработки чего-либо. Это очень похоже на сервера Discord, или Slack, однако не имеет такой выраженной направленности, то есть workspace не нацелен на развлечения, как сервер Discord, и не ставит ставку только на работу, как Slack. И в отличии от Slack и Discord, workspace не ограничивает вас в общении - выйти из workspace и зайти в глобальный чат или личную переписку с другом проще простого, а вернуться не составит проблем. Это функциональность Slack внутри мессенджера, на вроде Telegram. И эта фишка должна стать ключевой в версии MoreliaTalk 2.0. Мы с широкого пинка должны ворваться в мир мессенджеров, разумеется набрав перед этим некоторую аудиторию, а затем выпустив апдейт, который меняет правила игры.
Теперь к тому, как это реализовать. И тут самое интересное. Теперь все чаты, что ранее были глобальными, становятся частью единого workspace "main". Любой пользователь по умолчанию состоит в workspace "main". Теперь права пользователей работают отдельно для каждого workspace и чата. Внутри workspace "main", чаты имеют суверинитет, и глобальный администратор MoreliaTalk не имеет к ним доступа. Внутри других workspace, админ, разумеется царь, но не бог, бог - это владелец. Так вот. Куда этот workspace добавить в протокол? Думается, что поля flow, message и другие, мы перенесём внутрь нового поля workspaces. Поле workspaces представляет собой массив, содержащий в себе объекты типа Workspace, в который входят поля, касающиеся чатов и их сообщений. Также внутрь типа Workspace будут добавлены специальный поля для получения информации о конкретном workspace и др. Все нововедения потребуют глобального изменения как протокола, так и методов сервера и клиента.
В целом вроде описал идею workspace, при наличии вопросов, милости просим, отвечу. И если есть что добавить, тоже пишите.

[stepanskryabin]

Опишу что же такое WORKSPACE. Рассмотрим, как это будет выглядеть у пользователя. В его списке чатов, кроме самих чатов будут находиться отдельные пункты с пометкой workspace. При нажатии на этот пункт, от кнопки идёт волна, фон и цветовая гамма меняется в зависимости личных настроек workspace. Вместе с фоном и гаммой волна меняет и список чатов, который меняется на тот, который содержится в workspace. Появляется кнопка назад, для выхода из workspace. Внутри workspace, чаты изолированы от других чатов, к ним не получить доступа не состоя в workspace. Присоединяясь к workspace, user автоматически входит в чаты, которые выбрал администратор workspace. При желании, он может выйти из них, или войти в другие. Поиск теперь ищет не по всей бд, а по конкретному workspace. Workspace можно экспортировать, полностью перенеся на другой сервер.
т.е. юзер автоматом присоединяется во все чаты/каналы/группы воркспейса, при акцептировании приглашения?

Права доступа автоматом так же назначаются юзеру чтобы он мог читать/писать в чаты/группы/каналы?

Теперь к самой идее. Что же такое workspace? Это отдельное пространство, вне которого данные и чаты не выходят. Это собственный изолированный уголок MoreliaTalk. Что это даёт пользователю? Он может создать собственное сообщество, с подразделением на темы, или форум, или же вообще обсуждение разработки чего-либо. Это очень похоже на сервера Discord, или Slack, однако не имеет такой выраженной направленности, то есть workspace не нацелен на развлечения, как сервер Discord, и не ставит ставку только на работу, как Slack. И в отличии от Slack и Discord, workspace не ограничивает вас в общении - выйти из workspace и зайти в глобальный чат или личную переписку с другом проще простого, а вернуться не составит проблем. Это функциональность Slack внутри мессенджера, на вроде Telegram. И эта фишка должна стать ключевой в версии MoreliaTalk 2.0. Мы с широкого пинка должны ворваться в мир мессенджеров, разумеется набрав перед этим некоторую аудиторию, а затем выпустив апдейт, который меняет правила игры. Теперь к тому, как это реализовать. И тут самое интересное. Теперь все чаты, что ранее были глобальными, становятся частью единого workspace "main". Любой пользователь по умолчанию состоит в workspace "main". Теперь права пользователей работают отдельно для каждого workspace и чата. Внутри workspace "main", чаты имеют суверинитет, и глобальный администратор MoreliaTalk не имеет к ним доступа. Внутри других workspace, админ, разумеется царь, но не бог, бог - это владелец. Так вот. Куда этот workspace добавить в протокол? Думается, что поля flow, message и другие, мы перенесём внутрь нового поля workspaces. Поле workspaces представляет собой массив, содержащий в себе объекты типа Workspace, в который входят поля, касающиеся чатов и их сообщений. Также внутрь типа Workspace будут добавлены специальный поля для получения информации о конкретном workspace и др. Все нововедения потребуют глобального изменения как протокола, так и методов сервера и клиента. В целом вроде описал идею workspace, при наличии вопросов, милости просим, отвечу. И если есть что добавить, тоже пишите.

Нужны конкретные детали Workspace. Я пока не вижу смысла глобально перекраивать объект Flow, достточно добавить пару доп полей для Workspace.

[stepanskryabin]

Протокол безопасности TLS 1.3 описание

[NekrodNIK]

Опишу что же такое WORKSPACE. Рассмотрим, как это будет выглядеть у пользователя. В его списке чатов, кроме самих чатов будут находиться отдельные пункты с пометкой workspace. При нажатии на этот пункт, от кнопки идёт волна, фон и цветовая гамма меняется в зависимости личных настроек workspace. Вместе с фоном и гаммой волна меняет и список чатов, который меняется на тот, который содержится в workspace. Появляется кнопка назад, для выхода из workspace. Внутри workspace, чаты изолированы от других чатов, к ним не получить доступа не состоя в workspace. Присоединяясь к workspace, user автоматически входит в чаты, которые выбрал администратор workspace. При желании, он может выйти из них, или войти в другие. Поиск теперь ищет не по всей бд, а по конкретному workspace. Workspace можно экспортировать, полностью перенеся на другой сервер. т.е. юзер автоматом присоединяется во все чаты/каналы/группы воркспейса, при акцептировании приглашения?

Права доступа автоматом так же назначаются юзеру чтобы он мог читать/писать в чаты/группы/каналы?

Теперь к самой идее. Что же такое workspace? Это отдельное пространство, вне которого данные и чаты не выходят. Это собственный изолированный уголок MoreliaTalk. Что это даёт пользователю? Он может создать собственное сообщество, с подразделением на темы, или форум, или же вообще обсуждение разработки чего-либо. Это очень похоже на сервера Discord, или Slack, однако не имеет такой выраженной направленности, то есть workspace не нацелен на развлечения, как сервер Discord, и не ставит ставку только на работу, как Slack. И в отличии от Slack и Discord, workspace не ограничивает вас в общении - выйти из workspace и зайти в глобальный чат или личную переписку с другом проще простого, а вернуться не составит проблем. Это функциональность Slack внутри мессенджера, на вроде Telegram. И эта фишка должна стать ключевой в версии MoreliaTalk 2.0. Мы с широкого пинка должны ворваться в мир мессенджеров, разумеется набрав перед этим некоторую аудиторию, а затем выпустив апдейт, который меняет правила игры. Теперь к тому, как это реализовать. И тут самое интересное. Теперь все чаты, что ранее были глобальными, становятся частью единого workspace "main". Любой пользователь по умолчанию состоит в workspace "main". Теперь права пользователей работают отдельно для каждого workspace и чата. Внутри workspace "main", чаты имеют суверинитет, и глобальный администратор MoreliaTalk не имеет к ним доступа. Внутри других workspace, админ, разумеется царь, но не бог, бог - это владелец. Так вот. Куда этот workspace добавить в протокол? Думается, что поля flow, message и другие, мы перенесём внутрь нового поля workspaces. Поле workspaces представляет собой массив, содержащий в себе объекты типа Workspace, в который входят поля, касающиеся чатов и их сообщений. Также внутрь типа Workspace будут добавлены специальный поля для получения информации о конкретном workspace и др. Все нововедения потребуют глобального изменения как протокола, так и методов сервера и клиента. В целом вроде описал идею workspace, при наличии вопросов, милости просим, отвечу. И если есть что добавить, тоже пишите.

Нужны конкретные детали Workspace. Я пока не вижу смысла глобально перекраивать объект Flow, достточно добавить пару доп полей для Workspace.

Я тут подумал... да, пусть workspace будет просто новым типом flow

[baterflyrity]

Привет! Хотелось бы увидеть в протоколе описание шифрования: конкретные методы + общее описание схемы (алгоритма) шифрования.

Я так полагаю, задумка в end-to-end шифровании. В таком случае TLS не поможет, т.к. он обеспечивает защиту от mitm атаки между клиентом и сервером с точностью до сертификата.

[stepanskryabin]

Привет! Хотелось бы увидеть в протоколе описание шифрования: конкретные методы + общее описание схемы (алгоритма) шифрования.

Да, постараюсь сделать описание схемы работы в документации.

Я так полагаю, задумка в end-to-end шифровании. В таком случае TLS не поможет, т.к. он обеспечивает защиту от mitm атаки между клиентом и сервером с точностью до сертификата.
Общая задумка такая:
Первый уровень - шифрование на уровне протокола websocket (используется TLS 1.3).
Второй уровень - сквозное шифрование между клиентом и сервером.

В случае соединения между двумя пользователями (чат) всё достаточно просто и такая схема реализована в WhatsApp и Telegram. При соединении с количеством клиентов от 3 и более (канал, группа, рабочее пространство), нет рабочей схемы как реализовать сквозное шифрование. Я склоняюсь к варианту первоначального обмена ключами между сервером и каждым клиентом (через использование индивидуальных ключей), а потом переход на универсальные ключи для конкретного канала/группы/рабочего пространства.