Сварка

A swarm (group chat) is a set of participants capable of resilient, decentralized communication. For example, if two participants lose connectivity with the rest of the group (e.g., during an Internet outage) but can still reach each other over a LAN or subnetwork, they can exchange messages locally and then synchronize with the rest of the group once connectivity is restored.

A swarm is defined by the following properties:

Ability to split and merge based on network connectivity.
History synchronization. Every participant must be able to send a message to the entire group.
Нет центрального органа, не может полагаться на какой-либо сервер.
Non-repudiation. Devices must be able to verify past messages“ validity and to replay the entire history.
Perfect Forward Secrecy (PFS) is provided on the transport channels. Storage is handled by each device.

Главная идея заключается в том, чтобы получить синхронизированное дерево Меркл с участниками.

We identified four modes for swarms that we want to implement:

ONE_TO_ONE: A private conversation between two endpoints—either between two users or with yourself.
ADMIN_INVITES_ONLY: A swarm in which only the administrator can invite members (for example, a teacher-managed classroom).
INVITES_ONLY: A closed swarm that admits members strictly by invitation; no one may join without explicit approval.
PUBLIC: A public swarm that anyone can join without prior invitation (For example a forum).

Сценарии

Создать скопление

Боб хочет создать новый рог

Bob creates a local Git repository.
Затем он создает первоначальный подписанный договор с следующим:
- Его публичный ключ в /admins
- Его сертификат устройства в ̀ /устройства
- Его КРЛ в ̀ /crls`
Хеш-адрес первого коммита становится идентификатором разговора.
Bob announces to his other devices that he created a new conversation. This is done via an invite to join the group sent through the DHT to other devices linked to that account.

Добавление кого-то

Bob adds Alice

Bob adds Alice to the repo:
- Добавляет приглашенный URI в /invited
- Добавляет КРС к /crls
Bob sends a request on the DHT.

Принимая приглашение

Alice gets the invite to join the previously created swarm

Alice accepts the invite (if she declines, nothing happens; she will remain in the «invited» list, and will never receive any messages)
A peer-to-peer connection is established between Alice and Bob.
Alice pulls the Git repository from Bob. WARNING this means that messages require a connection, not from the DHT as it is today.
Alice validates the commits from Bob.
To validate that Alice is a member, she removes the invite from /invited directory, then adds her certificate to the /members directory
Once all commits are validated and syncronized to her device, Alice discovers other members of the group. with these peers, she will then construct the DRT with Bob as a bootstrap.

Посылаю сообщение

Alice sends a message to Bob

Alice creates a commit message. She constructs a JSON payload containing the MIME type and message body. For example:

{
    "type": "text/plain",
    "body": "hello"
}

Alice ensure her device credentials are present. If Alice’s device certificate or its associated CRL isn’t already stored in the repository, she adds them so that other participants can verify the commit.
Alice commits to the repository (Because Jami relies primarily on commit-message metadata rather than file contents, merge conflicts are rare; the only potential conflicts would involve CRLs or certificates, which are versioned in a dedicated location).
Alice announces the commit via the DRT with a service message and pings the DHT for mobile devices (they must receive a push notification).

Примечание

To notify other devices, the sender transmits a SIP message with type: application/im-gitmessage-id. The JSON payload includes the deviceId (the sender’s), the conversationId and the reference (hash) of the new commit.

Получение сообщения

Bob receives a message from Alice

Bob performs a Git pull on Alice’s repository.
All incoming commits MUST be verified by a hook.
If all commits are valid, commits are stored and displayed.Bob then announces the message via the DRT for other devices.
If any commit is invalid, pull is aborted. Alice must restore her repository to a correct state before retrying.

Подтверждение обязательства

Чтобы избежать того, чтобы пользователи наталкивали некоторые нежелательные коммиты (с конфликтами, ложными сообщениями и т. Д.), каждый коммит (от старейшего до самого нового) должен быть проверен перед слиянием удаленной ветви:

Примечание

If the validation fails, the fetch is ignored and we do not merge the branch (and remove the data), and the user should be notified.
If a fetch is too big, it’s not merged.

For each incoming commit, ensure that the sending device is currently authorized and that the issuer’s certificate exists under /members or /admins, and the device’s certificate under /devices.
Then handle one of three cases, based on the commit’s parent count:
- Merge Commit (2 parents). No further validation is required, merges are always accepted.
- Initial Commit (0 parents). Validate that this is the very first repository snapshot:
  - Admin certificate is added.
  - Device certificate is added.
  - CRLs (Certificate Revocation Lists) are added.
  - No other files are present.
- Ordinary Commit (1 parent). The commit message must be JSON with a top‑level type field. Handle each type as follows:
  - If text (or any non–file‑modifying MIME type)
    - Signature is valid against the author’s certificate in the repo.
    - No unexpected files are added or removed.
  - If vote
    - voteType is one of the supported values (e.g. «ban», «unban»).
    - The vote matches the signing user.
    - The signer is an admin, their device is present, and not themselves banned.
    - No unexpected files are added or removed.
  - If member
    - If adds
      - Properly signed by the inviter.
      - New member’s URI appears under /invited.
      - No unexpected files are added or removed.
      - If ONE_TO_ONE, ensure exactly one admin and one member.
      - If ADMIN_INVITES_ONLY, the inviter must be an admin.
    - If joins
      - Properly signed by the joining device.
      - Device certificate added under /devices.
      - Corresponding invite removed from /invited and certificate added to /members.
      - No unexpected files are added or removed.
    - If banned
      - Vote is valid per the vote rules above.
      - Ban is issued by an admin.
      - Target’s certificate moved to /banned.
      - Only files related to the ban vote are removed.
      - No unexpected files are added or removed.
  - Fallback. If the commit’s type or structure is unrecognized, reject it and notify the peer (or user) that they may be running an outdated version or attempting unauthorized changes.

Запретить устройство

Важно

Jami source code tends to use the terms (un)ban, while the user interface uses the terms (un)block.

Alice, Bob, Carla, Denys are in a swarm. Alice issues a ban against Denys.

In a fully peer‑to‑peer system with no central authority, this simple action exposes three core challenges:

Untrusted Timestamps: Commit timestamps cannot be relied upon for ordering ban events, as any device can forge or replay commits with arbitrary dates.
Conflicting bans: In cases where multiple admin devices exist, network partitions can result in conflicting ban decisions. For instance, if Alice can communicate with Bob but not with Denys and Carla, while Carla can communicate with Denys, conflicting bans may occur. If Denys bans Alice while Alice bans Denys, the group’s state becomes unclear when all members eventually reconnect and merge their conversation histories.
Compromised or expired devices: Devices can be compromised, stolen, or have their certificates expire. The system must allow banning such devices and ensure they cannot manipulate their certificate or commit timestamps to send unauthorized messages or falsify their expiration status.

Подобные системы (с распределенными групповыми системами) не так много, но это несколько примеров:

[mpOTR не определяет, как запретить кого-то]
Сигнал, без центрального сервера для группового чата (EDIT: они недавно изменили этот пункт), не дает возможности запретить кого-то из группы.

This voting system needs a human action to ban someone or must be based on the CRLs info from the repository (because we can not trust external CRLs).

Удалить устройство из разговора

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

Это необходимо для обнаружения отмененных устройств или просто избегания присутствия нежелательных людей в общественной комнате.

Алиса снимает Боба

Важно

Alice MUST be an admin to vote.

Во-первых, она голосует за запрет Боба. Для этого она создает файл в /votes/ban/members/uri_bob/uri_alice (члены могут быть заменены устройствами для устройства, или приглашены для приглашений или администраторов для администраторов) и обязуется
Затем она проверяет, разрешено ли голосование. Это означает, что >50% администраторов согласны запретить Боб (если она одна, это наверняка больше 50%).
Если голосование будет решено, файлы в /votes/ban могут быть удалены, все файлы для Боба в /members, /admins, /invited, /CRLs, /devices могут быть удалены (или только в /devices, если это устройство, которое запрещено) и сертификат Боба может быть помещен в /banned/members/bob_uri.crt (или /banned/devices/uri.crt, если устройство запрещено) и обязаны репо
Затем Алиса информирует других пользователей (за исключением Боба)

Alice (admin) re-adds Bob (banned member)

If she votes for unbanning Bob. To do that, she creates the file in /votes/unban/members/uri_bob/uri_alice (members can be replaced by devices for a device, or invited for invites or admins for admins) and commits
Затем она проверяет, разрешено ли голосование. Это означает, что >50% администраторов согласны запретить Боб (если она одна, это наверняка больше 50%).
Если голосование будет решено, файлы в /votes/unban могут быть удалены, все файлы для Боба в /members, /admins, /invited, /CRLs, могут быть передобавлены (или только в /devices, если это устройство, которое не запрещено) и обязаны в repo

Убрать разговор

Сохранить в convInfos removed=time::now() (как удалитьСвязь сохраняет в контактах) что разговор удаляется и синхронизируется с устройствами других пользователей
Если мы получим новое сообщение, то это будет проигнорировано.
Если Джами стартует и репо все еще присутствует, разговор не будет объявлен клиентам.
Two cases: a. If no other member in the conversation we can immediately remove the repository b. If still other members, commit that we leave the conversation, and now wait that at least another device sync this message. This avoids the fact that other members will still detect the user as a valid member and still sends new message notifications.
Когда мы уверены, что кто-то синхронизировался, удалите erased=time::now() и синхронизируйте с устройствами других пользователей
Все устройства, принадлежащие пользователю, теперь могут удалить хранилище и связанные с ним файлы

Как указать режим

Моды не могут быть изменены в течение времени. Или это другой разговор. Итак, эти данные хранятся в первоначальном сообщении об обязательстве.

{
    "type": "initial",
    "mode": 0,
}

На данный момент «мод» принимает значения 0 (ONE_TO_ONE), 1 (ADMIN_INVITES_ONLY), 2 (INVITES_ONLY), 3 (PUBLIC)

Processes for 1:1 chats

The goal here is to keep the old API (addContact/removeContact, sendTrustRequest/acceptTrustRequest/discardTrustRequest) to create a chat with a peer and its contact. This still implies some changes that we cannot ignore:

Процесс все равно такой же, учетная запись может добавить контакт через addContact, а затем отправить запрос доверия через DHT. Но необходимы две изменения:

TrustRequest внедряет «conversationId», чтобы сообщить коллегам, какой разговор клонировать при принятии запроса
TrustRequest перепробованы, когда контакт возвращается в сеть. Это не так сегодня (поскольку мы не хотим генерировать новый TrustRequest, если одноклассник отбросит первый). Так что, если учетная запись получает запрос на доверие, он будет автоматически игнорироваться, если запрос с связанным разговором будет отклонен (поскольку convRequests синхронизируются)

Затем, когда контакт принимает запрос, необходимо время синхронизации, потому что контакт теперь должен клонировать разговор.

removeContact() удалит контакт и связанные с ним разговоры 1:1 (с тем же процессом, что и «Удалить разговор»). Единственное замечание здесь заключается в том, что если мы запретим контакт, мы не ждем синхронизации, мы просто удалим все связанные с ним файлы.

Сценарии сложные

Есть случаи, когда можно создать два разговора.

Алиса добавляет Боба.
Боб соглашается.
Алиса убирает Боба.
Алиса добавляет Боба.

или

Alice adds Bob and Bob adds Alice at the same time, but both are not connected together.

In this case, two conversations are generated. We don’t want to remove messages from users or choose one conversation here. So, sometimes two conversations between the same members will be shown. It will generate some bugs during the transition time (as we don’t want to break API, the inferred conversation will be one of the two shown conversations, but for now it’s «ok-ish», will be fixed when clients will fully handle conversationId for all APIs (calls, file transfer, etc)).

Важно

After accepting a conversation’s request, there is a time the daemon needs to retrieve the distant repository. During this time, clients MUST show a syncing view to give informations to the user. While syncing:

ConfigurationManager::getConversations() will return the conversation’s id even while syncing.
ConfigurationManager::conversationInfos() вернет {{«синхронизация»: «истинный»}} в случае синхронизации.
ConfigurationManager::getConversationMembers() will return a map of two URIs (the current account and the peer who sent the request).

Разговоры просят уточнения

Запросы на разговоры представлены Map<String, String> с следующими клавишами:

id: the conversation ID
from: URI of the sender
Принято: часовой печать
название: (необязательно) название разговора
описание: (необязательно)
avatar: (optional) the profile picture

Синхронизация профиля разговора

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

Хранение в хранилище

Профиль разговора хранится в классическом файле vCard в корне (/profile.vcf) например:

BEGIN:VCARD
VERSION:2.1
FN:TITLE
DESCRIPTION:DESC
END:VCARD

Синхронизация

To update the vCard, a user with enough permissions (by default: =ADMIN) needs to edit /profile.vcf and will commit the file with the mimetype application/update-profile. The new message is sent via the same mechanism and all peers will receive the MessageReceived signal from the daemon. The branch is dropped if the commit contains other files or too big or if done by a non-authorized member (by default: <ADMIN).

Последний раз

В синхронизированных данных каждое устройство отправляет другим устройствам состояние разговоров. В этом состоянии отправляется последний отображаемый. Однако, поскольку каждое устройство может иметь свое собственное состояние для каждого разговора, и, вероятно, без того же последнего обязательства в какой-то момент, есть несколько сценариев, которые следует учитывать:

Поддерживаются 5 сценариев:

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

Настройки

Каждый разговор имеет прикрепленные предпочтения, установленные пользователем. Эти предпочтения синхронизируются на всех устройствах пользователя. Это может быть цвет разговора, если пользователь хочет игнорировать уведомления, ограничение размера передачи файлов и т. Д. На данный момент признанные ключи:

«color» - the color of the conversation (#RRGGBB format)
«ignoreNotifications» - игнорировать уведомления о новых сообщениях в этом разговоре
«символ» - для определения дефолта эмодзи.

Эти предпочтения хранятся в пакете MapStringString, хранящемся в accountDir/conversation_data/conversationId/preferences и отправляемых только через устройства одного и того же пользователя через SyncMsg.

API для взаимодействия с предпочтениями:

// Update preferences
void setConversationPreferences(const std::string& accountId,
                                const std::string& conversationId,
                                const std::map<std::string, std::string>& prefs);
// Retrieve preferences
std::map<std::string, std::string> getConversationPreferences(const std::string& accountId,
                                                              const std::string& conversationId);
// Emitted when preferences are updated (via setConversationPreferences or by syncing with other devices)
struct ConversationPreferencesUpdated
{
    constexpr static const char* name = "ConversationPreferencesUpdated";
    using cb_type = void(const std::string& /*accountId*/,
                            const std::string& /*conversationId*/,
                            std::map<std::string, std::string> /*preferences*/);
};

Управление конфликтами слияния

Поскольку два администратора могут изменять описание одновременно, конфликт слияния может возникнуть на profile.vcf. В этом случае будет выбран commit с более высоким хэшем (например, ffffff > 000000).

API

Пользователь получил 2 способа получения и настройки метаданных разговора:

       <method name="updateConversationInfos" tp:name-for-bindings="updateConversationInfos">
           <tp:added version="10.0.0"/>
           <tp:docstring>
               Update conversation's infos (supported keys: title, description, avatar)
           </tp:docstring>
           <arg type="s" name="accountId" direction="in"/>
           <arg type="s" name="conversationId" direction="in"/>
           <annotation name="org.qtproject.QtDBus.QtTypeName.In2" value="VectorMapStringString"/>
           <arg type="a{ss}" name="infos" direction="in"/>
       </method>

       <method name="conversationInfos" tp:name-for-bindings="conversationInfos">
           <tp:added version="10.0.0"/>
           <tp:docstring>
               Get conversation's infos (mode, title, description, avatar)
           </tp:docstring>
           <annotation name="org.qtproject.QtDBus.QtTypeName.Out0" value="VectorMapStringString"/>
           <arg type="a{ss}" name="infos" direction="out"/>
           <arg type="s" name="accountId" direction="in"/>
           <arg type="s" name="conversationId" direction="in"/>
       </method>

где инфо представляет собой map<str, str> с следующими клавишами:

режим: только для чтения
название
описание
avatar: the profile picture

Перевозить учетную запись (ссылка/экспорт)

В архиве МОЖЕ быть записана разговорная информация, чтобы можно было восстановить разговоры на новых коммитах после повторного импорта (потому что в данный момент нет приглашения).

Разговор есть, в этом случае демон способен клонировать этот разговор.
РазговорId отсутствует, поэтому демон просит (по сообщению {{"приложение/приглашение", conversationId}}) новое приглашение, которое пользователь должен (вновь) принять

Важно

A conversation can only be retrieved if a contact or another device is there, else it will be lost. There is no magic.

Используемые протоколы

Гит

Почему этот выбор

Each conversation will be a Git repository. This choice is motivated by:

Мы должны синхронизировать и заказывать сообщения. Древо Меркле - это идеальная структура для этого и может быть линеаризирована путем слияния ветвей. Более того, поскольку он широко используется Git, его легко синхронизировать между устройствами.
Распределенный природой, широко используемый, много задней части и подключимый.
Могли бы проверить обязательства через крюки и широко используемые крипто
При необходимости может быть сохранено в базе данных
Конфликты избегаются, используя сообщения, а не файлы.

Что мы должны подтвердить

Выступление? git.lock может быть низким
Грак в либгит2
Многочисленные порывы одновременно?

Ограничения

Чтобы удалить разговор, устройство должно покинуть разговор и создать другой.

Однако не постоянные сообщения (например, сообщения, которые могут быть прочитаны только на несколько минут) могут быть отправлены через специальное сообщение через DRT (например, уведомления о вводе или прочтении).

Структура

/
 - invited
 - admins (public keys)
 - members (public keys)
 - devices (certificates of authors to verify commits)
 - banned
   - devices
   - invited
   - admins
   - members
 - votes
    - ban
        - members
            - uri
                - uriAdmin
        - devices
            - uri
                - uriAdmin
    - unban
        - members
            - uri
                - uriAdmin
 - CRLs

Передача файлов

This new system overhauls file sharing: the entire history is now kept in sync, so any device in the conversation can instantly access past files. Rather than forcing the sender to push files directly—an approach that was fragile in the face of connection drops and often required manual retries—devices simply download files when they need them. Moreover, once one device has downloaded a file, it can act as a host for others, ensuring files remain available even if the original sender goes offline.

Протокол

Отправитель добавляет в разговор новый коммит в следующем формате:

value["tid"] = "RANDOMID";
value["displayName"] = "DISPLAYNAME";
value["totalSize"] = "SIZE OF THE FILE";
value["sha3sum"] = "SHA3SUM OF THE FILE";
value["type"] = "application/data-transfer+json";

и создает ссылку в ${data_path}/conversation_data/${conversation_id}/${file_id} где file_id=${commitid}_${value["tid"]}.${extension}

Затем получатель может загрузить файлы, связавшись с устройствами, размещающими файл, открыв канал с name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId и хранить информацию о том, что файл ждет в ${data_path}/conversation_data/${conversation_id}/waiting

Приемник будет хранить первый открытый канал, закрывать другие и записывать в файл (с тем же путем, что и отправитель: ${data_path}/conversation_data/${conversation_id}/${file_id}) все поступающие данные.

Когда передача завершена или канал закрыт, sha3sum проверяется, чтобы подтвердить, что файл правильный (или он удален).

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

Call in Swarm

Идея

A swarm conversation can have multiple rendez-vous. A rendez-vous is defined by the following URI:

«accountUri/deviceId/conversationId/confId» где accountUri/deviceId описывает хост.

Хозяин может быть определен двумя способами:

In the swarm metadatas. Where it’s stored like the title/desc/avatar (profile picture) of the room
Или первоначальный звонок.

When starting a call, the host will add a new commit to the repository, with the URI to join (accountUri/deviceId/conversationId/confId). This will be valid till the end of the call (announced by a commit with the duration to show)

Таким образом, каждая часть получит информацию о том, что звонок начался и сможет присоединиться к нему, позвонив ему.

Нападения?

Avoid Git bombs

Записки

Временная печать коммитации может быть доверена, потому что она редактируема.

ТЛС

Операции Git, управления сообщениями, файлами и другими вещами будут использовать p2p TLS v1.3 ссылку с только шифрами, которые гарантируют PFS.

DHT (UDP)

Используется для отправки сообщений для мобильных устройств (для запуска push-уведомлений) и для запуска TCP-соединений.

Сетевая деятельность

Процесс приглашения кого-то

Алиса хочет пригласить Боба:

Алиса добавляет Боба к разговору
Alice generates an invite: { «application/invite+json» : { «conversationId»: «$id», «members»: [{…}] }}
Две возможности для отправки сообщения a. Если не подключен, через DHT b. Иначе, Алиса отправляет по каналу SIP
Два варианта для Боба a. Принимает приглашение, сигнал высылается для клиента b. Не подключен, поэтому никогда не получит запрос, потому что Алиса не должна знать, если Боб просто проигнорировал или заблокировал Алису.

Процесс отправки сообщения кому-то

Алиса хочет отправить сообщение Бобу:

Алиса добавляет сообщение в репо, давая идентификатор
Алиса получает сообщение (от себя) если успешный
В обоих случаях создается сообщение: { «приложение/im-gitmessage-id» : «{«id»:»$convId", "commit":"$commitId», «deviceId»: «$alice_device_hash»}»}. а. Если не подключено, через DHT b. В противном случае, Алиса отправляет по каналу SIP
Четыре возможности для Боба: а. Боб не связан с Алисой, поэтому если он доверяет Алисе, попросите о новом соединении и отправляйтесь в b. b. Если он связан, возьмите у Алисы и объявить о новых сообщениях в. Боб не знает об этом разговоре. Просите через DHT получить приглашение сначала, чтобы иметь возможность принять этот разговор ({«приложение/приглашение», разговорId}) d. Боб отключен (нет сети, или просто закрыт). Он не получит новое сообщение, но попытается синхронизировать, когда произойдет следующее соединение

Реализация

! Диаграмма: уроки чата сварка

Supported messages

Initial message

{
    "type": "initial",
    "mode": 0,
    "invited": "URI"
}

Represents the first commit of a repository and contains the mode:

enum class ConversationMode : int { ONE_TO_ONE = 0, ADMIN_INVITES_ONLY, INVITES_ONLY, PUBLIC }

and invited if mode = 0.

Text message

{
    "type": "text/plain",
    "body": "content",
    "react-to": "id (optional)"
}

Or for an edition:

{
    "type": "application/edited-message",
    "body": "content",
    "edit": "id of the edited commit"
}

Звонки

Show the end of a call (duration in milliseconds):

{
    "type": "application/call-history+json",
    "to": "URI",
    "duration": "3000"
}

Or for hosting a call in a group (when it starts)

{
    "type": "application/call-history+json",
    "uri": "host URI",
    "device": "device of the host",
    "confId": "hosted confId"
}

A second commit with the same JSON + duration is added at the end of the call when hosted.

Добавить файл

{
    "type": "application/data-transfer+json",
    "tid": "unique identifier of the file",
    "displayName": "File name",
    "totalSize": "3000",
    "sha3sum": "a sha3 sum"
}

totalSize is in bits,

Updating profile

{
    "type": "application/update-profile",
}

Member event

{
    "type": "member",
    "uri": "member URI",
    "action": "add/join/remove/ban"
}

When a member is invited, join or leave or is kicked from a conversation

Vote event

Generated by administrators to add a vote for kicking or un-kicking someone.

{
    "type": "vote",
    "uri": "member URI",
    "action": "ban/unban"
}

!! Старый проект!!

Примечание

Following notes are not organized yet. Just some line of thoughts.

Улучшения крипто.

Для серьезной групповой чата нам также нужна серьезная крипто. При текущем дизайне, если сертификат украден как предыдущие значения DHT разговора, разговор может быть расшифрован. Может быть, нам нужно пойти на что-то вроде Double ratchet.

Примечание

A lib might exist to implement group conversations.

Необходимость поддержки ЭКК в OpenDHT

Использование

Добавить роли?

Есть два основных случая использования групповых чатов:

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

Jami will be for which one?

Идея реализации

Сертификат для группы, которая подписывает пользователя флагом для роли.

Присоединяйтесь к разговору

Только по прямому приглашению
С помощью ссылки/КР-код/что угодно
Через имя комнаты?

Что нам нужно

Конфиденциальность: члены вне группового чата не должны иметь возможность читать сообщения в группе
Конфиденциальность: если какой-либо ключ группы был взломан, предыдущие сообщения должны оставаться конфиденциальными (по возможности)
Заказы сообщений: необходимо иметь сообщения в правильном порядке
Синхронизация: Также необходимо убедиться, что все сообщения будут доступны как можно скорее.
Продолжительность: На самом деле сообщение на DHT проходит всего 10 минут. Поскольку это лучшее время, рассчитанное для этого типа DHT. Чтобы сохранить данные, узел должен переставлять значение на DHT каждые 10 минут. Другой способ сделать, когда узел не работает, это позволить узлам переставлять данные. Но если через 10 минут 8 узлов все еще здесь, они будут выполнять 64 запроса (и это экспоненциально).

Другие распределенные способы

IPFS: Нужно провести расследование
Мне нужно провести расследование
Мне нужно провести расследование.

На основании текущей работы, которую мы имеем

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

Это должно переместить базу данных с клиента в демона.
Если никто не подключен, синхронизация не может быть сделана, и человек никогда не увидит разговор

Еще один DHT

Как DHT с суперпользователем.

What’s next for file transfers

Currently, the file transfer algorithm is based on a TURN connection (See Передача файлов). In the case of a big group, this will be bad. We first need a P2P connection for the file transfer. Implement the RFC for P2P transfer.

Other problem: currently there is no implementation for TCP support for ICE in PJSIP. This is mandatory for this point (in PJSIP or homemade)

Сварка

Сценарии

Создать скопление

Добавление кого-то

Принимая приглашение

Посылаю сообщение

Получение сообщения

Подтверждение обязательства

Запретить устройство

Удалить устройство из разговора

Убрать разговор

Как указать режим

Processes for 1:1 chats

Сценарии сложные

Разговоры просят уточнения

Синхронизация профиля разговора

Хранение в хранилище

Синхронизация

Последний раз

Настройки

Управление конфликтами слияния

API

Перевозить учетную запись (ссылка/экспорт)

Используемые протоколы

Гит

Почему этот выбор

Что мы должны подтвердить

Ограничения

Структура

Передача файлов

Протокол

Call in Swarm

Идея

Нападения?

Записки

ТЛС

DHT (UDP)

Сетевая деятельность

Процесс приглашения кого-то

Процесс отправки сообщения кому-то

Реализация

Supported messages

Initial message

Text message

Звонки

Добавить файл

Updating profile

Member event

Vote event

Улучшения крипто.

Использование

Добавить роли?

Идея реализации

Присоединяйтесь к разговору

Что нам нужно

Другие распределенные способы

На основании текущей работы, которую мы имеем

Еще один DHT

What’s next for file transfers

Ресурсы