Расширение протокола до версии 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 и более (канал, группа, рабочее пространство), нет рабочей схемы как реализовать сквозное шифрование. Я склоняюсь к варианту первоначального обмена ключами между сервером и каждым клиентом (через использование индивидуальных ключей), а потом переход на универсальные ключи для конкретного канала/группы/рабочего пространства.

[stepanskryabin]

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

Думай над тем, какие параметры в workspace добавить.

[baterflyrity]

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

Странная идея: обмениваться ключами с сервером для сквозного шифрования между клиентами.

[stepanskryabin]

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

Странная идея: обмениваться ключами с сервером для сквозного шифрования между клиентами.

Ещё раз отмечу, что это только для случая когда у нас общаются 3 и более клиента между собой (в одной группе). Стандартными средствами сквозного шифрования невозможно решить проблему шифрования сообщений между множеством клиентов (ну или мне такие способы неизвестны) используя ТОЛЬКО ключи клиентов. Например (упрощённо) при шифровании сообщений между тремя клиентами (чтобы каждый мог читать сообщения соседа) необходимо организовать обмен ключами между клиентами, т.е. у каждого клиента будет 3 ключа (свой и ещё 2-х соседей), после чего нужно будет как-то определять какое сообщение каким ключем расшифровывать. В случае группы на 100 клиентов это уже становится нетривиальной задачей. Нужно обменяться всеми ключами и как-то потом расшифровать сообщение рандомного соседа подходящим ключем выбрав его из этой 100. Учитывая возрастающую сложность алгоритма - я его сразу отбрасываю как нереализуемый.

По этому единственным способом организации сквозного шифрования между множеством клиентов (3 и более) является использование посредника которому все клиенты доверяют, в нашем случае это сервер. Тут только вопрос как это грамотно реализовать, чтобы сервер не мог скомпрометировать цепочку связи между клиентами.

[baterflyrity]

По этому единственным способом организации сквозного шифрования между множеством клиентов (3 и более) является использование посредника которому все клиенты доверяют, в нашем случае это сервер.

Тогда нужно сразу отказаться от шифрования, потому что этим занимается TLS.

[NekrodNIK]

Тогда нужно сразу отказаться от шифрования, потому что этим занимается TLS.

Надо не отказываться, а придумать, как реализовать)))

[stepanskryabin]

По этому единственным способом организации сквозного шифрования между множеством клиентов (3 и более) является использование посредника которому все клиенты доверяют, в нашем случае это сервер.

Тогда нужно сразу отказаться от шифрования, потому что этим занимается TLS.

TLS это шифрование канала передачи информации, передаваемых по открытым сетям, от клиента к серверу. Выше я речь вёл не про канальное шифрование, а про шифрование сообщений клиентов (людей).

[baterflyrity]

Выше я речь вёл не про канальное шифрование, а про шифрование сообщений клиентов (людей).

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

[NekrodNIK]

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

А если бд угонят?

[baterflyrity]

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

А если бд угонят?

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

[stepanskryabin]

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

А если бд угонят?

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

Вообще это хороший вопрос.... Я давно думаю что нужно отходить от централизованной роли сервера к более децентрализованной, без хранения информации о пользователях.. т.е. организовывать сервер только как посредника. Например в виде посредника подтверждающего ключи шифрования клиентов или посредника отвечающего за рассылку сообщения от одного клиента к нескольким другим клиентам подключенным к одному каналу или группе. Что-то наподобие "брокера" - как это реализовано в протокола MQTT.

[stepanskryabin]

НО! Есть один ньюанс, и он в том что целевая группа этого проекта бизнес, а не простые пользователи. А для бизнеса нужна именно централизованная БД и сервер её обрабатывающий.

[baterflyrity]

НО! Есть один ньюанс, и он в том что целевая группа этого проекта бизнес, а не простые пользователи. А для бизнеса нужна именно централизованная БД и сервер её обрабатывающий.

Так что же вы сразу не сказали! Зачем рекламировать это как новый децентрализованный мессенджер с оконечным шифрованием на питоне? Я пошёл, удачи.

[NekrodNIK]

Зачем рекламировать это как новый децентрализованный мессенджер с оконечным шифрованием на питоне?

Никто и не говорил, что он децентрализован)))

[stepanskryabin]

НО! Есть один ньюанс, и он в том что целевая группа этого проекта бизнес, а не простые пользователи. А для бизнеса нужна именно централизованная БД и сервер её обрабатывающий.

Так что же вы сразу не сказали! Зачем рекламировать это как новый децентрализованный мессенджер с оконечным шифрованием на питоне? Я пошёл, удачи.

1. Никто его и не рекламировал. Была одна статья на Хабре и всё.
2. Все технические реализации пока на стадии "размышления" и подготовки протокола версии 2.0. Что там в дальнейшем будет неизвестно, т.к. основные разработчики сами ещё начинающие.
3. Основная цель проекта, развёртывание инфраструктуры мессенджера на своём сервере, с возможной! опционально включаемой, децентрализацией...
4. Ещё раз подчеркну, это не готовый проект "искаропки", а лишь наши потуги придумать и реализовать свой мессенджер.