Сварка

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).

Сценари

Napravi roj

Bob želi da napravi novi roj

Bob creates a local Git repository.
Zatim kreira početno potpisano urezivanje sa sledećim:
- Његов јавни кључ у /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:
- Додаје позивљену УРИ у /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.

Slanje poruke

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.

Slični sistemi (sa sistemima distribuiranih grupa) nisu toliko, ali ovo su neki primeri:

[mpOTR не дефинише како забранити некога]
Signal, bez ikakvog centralnog servera za grupno ćaskanje (EDIT: nedavno su promenili tu tačku), ne daje mogućnost da se zabrani neko iz grupe.

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.

Prvo, ona glasa za zabranu Boba. Da bi to uradila, ona kreira datoteku u /votes/ban/members/uri_bob/uri_alice (članovi mogu biti zamenjeni uređajima za uređaj, ili pozvani za pozivnice ili administratori za administratore) i obaveže
То значи да > 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 ако је уређај који је не забрањен) и посвећени репо

Ukloni prepisku

Sačuvaj u convInfos remove=time::nov() (kao removeContact sačuva u kontaktima) da je konverzacija uklonjena i sinhronizovana sa uređajima drugih korisnika
Ако се добије нова обавеза за овај разговор, игнорисана је.
Ако је Џами стартирао и репо је још увек присутан, разговор није објављен клијентима.
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.
Када смо сигурни да је неко синхронизован, уклоните избришено=време:: сада() и синхронизирајте са уређајима других корисника
Сви уређаји у власништву корисника сада могу избрисати складиште и повезане датотеке

Како се одређује режим

Модови се не могу променити током времена. Или је то друга разговора. Дакле, ови подаци се чувају у почетној поруци обавештења.

{
    "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” да би информисао вршњака који разговор клонира када прихвати захтев
ТрастРекест се поново покушава када се контакт врати на интернет. То није случај данас (као што не желимо да генеришемо нови ТрастРекест ако вршњак одбаци први).

Онда, када контакт прихвати захтев, потребан је период синхронизације, јер контакт сада треба клонирати разговор.

removeContact() ће уклонити контакт и повезане разговоре 1:1 (с истим процесом као „Уклони разговор”). Једина приметка овде је да ако забранимо контакт, не чекамо синхронизацију, само уклањамо све повезане датотеке.

Скријни сценарио

Postoje slučajevi u kojima se mogu kreirati dva razgovora. Ovo su najmanje dva od tih scenarija:

Alice adds Bob.
Bob accepts.
Alice removes Bob.
Alice adds Bob.

или

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).

Разговори захтевају спецификацију

Замоље за разговоре представља Мапа<Стринг, Стринг> са следећим кључевима:

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).

Последњи приказан

У синхронизованим подацима, сваки уређај слаје на друге уређаје стање разговора. У овом стању, последњи приказан се слаје. Међутим, пошто сваки уређај може имати свој стан за сваки разговор, и вероватно без исте последне обавезе у неког тренутку, постоје неколико сценарија које треба узети у обзир:

Поддржани су пет сценарија:

ако је последњи приказан који је послао други уређаји исти као садашњи, нема ништа да се уради.
ако није показано последње за тренутни уређај, користи се подавна порука.
ако последњи удаљени систем није присутан у репо, то значи да ће се ангажовање касније добити, тако да се резултат чува
ако је удаљено већ извучено, проверимо да ли је локално последње приказан било раније у историји да га заменимо
На крају, ако се објави порука од истог аутора, то значи да морамо да ажуришемо последње приказану поруку.

Преференције

Сваки разговор има прикључени преференције које је одредио корисник. Ове преференције се синхронизују на корисничким уређајима. Ово може бити боја разговора, ако корисник жели да игнорише обавештења, ограничење величине преноса датотека итд.

„color” - the color of the conversation (#RRGGBB format)
„игнорисати обавештења” - игнорисати обавештења за нове поруке у овом разговору
„симбол” - да дефинише дефолт емоџи.

Ове преференције се чувају у паку 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).

АПИ

Корисник је добио 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>

где је инфо мапа<str, str> са следећим кључевима:

Режим: само читање
титула
описање
avatar: the profile picture

Реимпортирање рачуна (врза/експорт)

У архиву МОЖЕ бити садржана разговорИд да би се могли извлачити разговори на новим комтима након реимпорта (јер на овом месту нема позива).

Разговор је тамо, у овом случају, демон је у стању да поново клонише овај разговор
РазговорId недостаје, па демон пита (преку поруке {{" апликација/ покана", разговорId}}) нови позив који корисник треба (поново) прихватити

Важно

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.lock може бити ниска
Гук у libgit2
Многе ударе истовремено?

Прегранице

Istorija se ne može izbrisati. Da biste izbrisali konverzaciju, uređaj mora da napusti konverzaciju i kreira drugu.

Међутим, непостојане поруке (као што су поруке које се могу читати само неколико минута) могу се послати путем посебне поруке преко ДРТ-а (као што су обавештења за писање или читање).

Структура

/
 - 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";

i pravi vezu u ${data_path}/conversation_data/${conversation_id}/${file_id} gde je file_id=${commitid}_${value["tid"]}.${ektension}

Онда примаоц сада може преузети датотеке контактирајући уређаје који хостера датотеку, отварајући канал са name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId и чувајући информације да датотеку чека у ${data_path}/conversation_data/${conversation_id}/waiting

Улазак који прима повезаност ће прихватити канал потврђивањем да ли се датотека може послати (ако је sha3sum исправна и ако датотека постоји). Пријемник ће чувати први отворен канал, затворити друге и записати у датотеку (с истим путем као и испратељ: ${data_path}/conversation_data/${conversation_id}/${file_id}) све долазеће податке.

Kada se transfer završi ili se kanal zatvori, sha3sum se verifikuje da bi se potvrdilo da je datoteka ispravna (u suprotnom se briše). Ako je validan, datoteka će biti uklonjena iz čekanja.

У случају неуспеха, када се уређај разговора врати у рад, питаћемо све датотеке на исти начин.

Call in Swarm

Идеја

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

„аккаунтУри/девизова ИД/конверсија ИД/конфулт” где акаунтУри/девизова ИД описује хост.

Хост може бити одређен на два начина:

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

Примете

Временски печат ангажовања може се веровати јер се може уређивати.

ТЛС

Гит операције, контролне поруке, датотеке и друге ствари ће користити p2p TLS v1.3 линк са само шифром који гарантује PFS.

DHT (UDP)

Користи се за слање порука за мобилне телефоније (за покретање обавештења) и за покретање TCP веза.

Активност мрежа

Процес за позивање некога

Алиса жели да позове Боба:

Алиса додаје Боба у разговор
Alice generates an invite: { „application/invite+json” : { „conversationId”: „$id”, „members”: [{…}] }}
Две могућности за слање поруке а. Ако није повезана, преко DHT b. Иначе, Алис прати на SIP канала
Dve mogućnosti za Boba a. Primi pozivnicu, emituje se signal za klijenta b. Nije povezan, tako da nikada neće primiti zahtev jer Alisa ne sme da zna da li je Bob jednostavno ignorisao ili blokirao Alisu. Jedini način je da ponovo generišete novu pozivnicu putem nove poruke (up. sledeći scenario)

Процес да се пошаље порука некоме

Алиса жели да пошаље поруку Бобу:

Алис додаје поруку у репо, дајући лик
Алиса добија поруку (од себе) ако успеје
У оба случаја се ствара порука: { „примена/им-gitmessage-id” : „{„id”:”$convId", "коммитирај":"$commitId”, „deviceId”: „$alice_device_hash”}”}.
Четири могућности за Боба: а. Боб није повезан са Алисом, па ако му верује Алису, замоли нови приступ и иди на Б. б. Ако је повезан, повуци од Алисе и најави нове поруке. Боб не познаје тај разговор. Попини кроз ДХТ да најпре добије позив да би могао прихватити тај разговор ({„примљена апликација/позив”, разговорId})

Увршење

[Диаграма: часови са скуповима](изображения/с скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скуповима са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са скупом са

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"
}

Poziva

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.

Add a file

{
    "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.

Криптовалуте су побољшане.

Za ozbiljnu funkciju grupnog ćaskanja, takođe nam je potrebno ozbiljno kriptovanje. Sa trenutnim dizajnom, ako je sertifikat ukraden kao prethodne DHT vrednosti razgovora, razgovor se može dešifrovati. Možda treba da pređemo na nešto poput Double ratchet.

Белешка

A lib might exist to implement group conversations.

Потребна је подршка ЕЦЦ у OpenDHT-у

Употреба

Додавање улога?

Postoje dva glavna slučaja upotrebe grupnih ćaskanja:

Нешто слично као Матермост у компанији, са приватним каналима, и неким улогама (админ/спектатор/бот/тд) или за образовање (где је само неколико активних).
Хоризонтални разговори су као разговори између пријатеља.

Jami will be for which one?

Идеја за спровођење

Sertifikat za grupu koja potpisuje korisnika oznakom za ulogu. Dodavanje ili opoziv takođe se može izvršiti.

Pridružite se razgovoru

Само путем директног позивања
Преку линка/КР кода/што год
Преку имена собе?

Оно што нам је потребно

Poverljivost: članovi van grupnog ćaskanja ne bi trebalo da mogu da čitaju poruke u grupi
Tajnost prosleđivanja: ako je bilo koji ključ iz grupe ugrožen, prethodne poruke treba da ostanu poverljive (koliko je to moguće)
Редажење порука: Потребно је да се поруке имају у правом поређењу
Синхронизација: Такође је потребно да се уверите да све поруке имају што је пре могуће.
Устојаност: заправо, порука на ДХТ-у живи само 10 минута. Јер је то најбоље време израчуњено за ову врсту ДХТ-а. Да би се додати да се дато, вузло мора поново ставити вредност на ДХТ-а сваких 10 минута. Други начин да се уради када је вузло искључено је да се вузлови поново ставе подаци. Али, ако након 10 минута, 8 вузла су још увек овде, они ће направити 64 захтеве (и то је експоненцијално).

Други распределени начини

ИПФС: Потребно је истрага
Потребно је истрага.
Потребно је истрага.

На основу садашњег рада које имамо

Grupno ćaskanje može da se zasniva na istom radu koji već imamo za više uređaja (ali ovde, sa grupnim sertifikatom). Problemi za rešavanje:

Схронизација историје. Ово треба да помести базу података из клијента у демона.
Ако нико није повезан, синхронизација се не може урадити, а особа никада неће видети разговор

Још један посвећен ДХТ

Као ДХТ са супер корисником.

Предавање датотека

Trenutno je algoritam za prenos datoteka zasnovan na TURN vezi (pogledajte Предавање датотека). U slučaju velike grupe, ovo će biti loše. Prvo nam treba p2p implementacija za prenos datoteka. Implementirajte RFC za p2p prenos.

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

Ресурси

https://eprint.iacr.org/2017/666.pdf
Строга дистрибуирана синхронизација мрежених линеарних система са интермитерским информацијама (Сен Филлипс и Рикардо Г.Санфелис)