Zvyšuje sa

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:

  1. Ability to split and merge based on network connectivity.

  2. History synchronization. Every participant must be able to send a message to the entire group.

  3. Žiadna centrálna autorita, nemôžem sa spoľahnúť na žiadny server.

  4. Non-repudiation. Devices must be able to verify past messages‘ validity and to replay the entire history.

  5. Perfect Forward Secrecy (PFS) is provided on the transport channels. Storage is handled by each device.

Hlavným nápadom je synchronizovať strom Merkle s účastníkmi.

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

Scenáriu

Vytvorte hromadu

Bob chce vytvoriť nový hŕstok

  1. Bob creates a local Git repository.

  2. Potom vytvorí prvotné podpísané záväzky s nasledovnými:

    • Jeho verejný kľúč v /admins

    • Jeho certifikát zariadenia v ̀ /devices `

    • Jeho CRL v ̀ /crls`

  3. Hash prvého prijímania sa stáva identifikátorom konverzácie.

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

Pridať niekoho

Bob adds Alice

  1. Bob adds Alice to the repo:

    • Pridaje pozvaný URI v /invited

    • Pridanie CRL do /crls

  2. Bob sends a request on the DHT.

Prijatie pozvania

Alice gets the invite to join the previously created swarm

  1. Alice accepts the invite (if she declines, nothing happens; she will remain in the „invited“ list, and will never receive any messages)

  2. A peer-to-peer connection is established between Alice and Bob.

  3. Alice pulls the Git repository from Bob. WARNING this means that messages require a connection, not from the DHT as it is today.

  4. Alice validates the commits from Bob.

  5. To validate that Alice is a member, she removes the invite from /invited directory, then adds her certificate to the /members directory

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

Posielať správu

Alice sends a message to Bob

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

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

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

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

  3. Alice announces the commit via the DRT with a service message and pings the DHT for mobile devices (they must receive a push notification).

Poznámka

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.

Príjem správy

Bob receives a message from Alice

  1. Bob performs a Git pull on Alice’s repository.

  2. All incoming commits MUST be verified by a hook.

  3. If all commits are valid, commits are stored and displayed.Bob then announces the message via the DRT for other devices.

  4. If any commit is invalid, pull is aborted. Alice must restore her repository to a correct state before retrying.

Súdny dvor

Aby sa zabránilo používateľom, ktorí tlačia niektoré nežiaduce commity (s konfliktmi, falošnými správami atď.), takto sa každý commit (od najstaršieho až po najnovší) musí overiť pred splynutím vzdialeného oddelenia:

Poznámka

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

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

Zákaz na zariadenie

Dôležité

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:

  1. Untrusted Timestamps: Commit timestamps cannot be relied upon for ordering ban events, as any device can forge or replay commits with arbitrary dates.

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

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

Podobné systémy (s rozdeľovanými skupinovými systémami) nie sú tak veľa, ale toto sú niektoré príklady:

  • [mpOTR nedefinuje, ako zakazovať niekoho]

  • Signal, bez centrálneho servera pre skupinový rozhovor (EDIT: nedávno to zmenili), nedáva možnosť zakazovať niekoho z skupiny.

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

Odstráňte zariadenie z konverzácie

Toto je jediná časť, v ktorej je potrebné mať konsenzus, aby sa zabránilo rozpadu konverzácie, ako keby sa dvaja členovia kopali z konverzácie, čo uvidí tretí?

Tento proces je veľmi podobný medzi členom a zariadením:

Alice odstraňuje Boba

Dôležité

Alice MUST be an admin to vote.

  • Najprv hlasuje za zákaz Boba. Na to vytvorí súbor v /votes/ban/members/uri_bob/uri_alice (membry môžu byť nahradené zariadeniami pre zariadenie, alebo pozvané na pozvánky alebo správcov pre správcov) a zaväzuje

  • Potom skontroluje, či hlasovanie je vylúčené. To znamená, že >50% správcov súhlasí s zákonom Boba (ak je sama, je to určite viac ako 50%).

  • Ak je hlasovanie vyřešené, súbory do /votes/ban môžu byť odstránené, všetky súbory pre Boba v /memberoch, /admins, /invited, /CRLs, /devices môžu byť odstránené (alebo len v /devices, ak je to zariadenie, ktoré je zakázané) a Bobov certifikát môže byť umiestnený do /banned/members/bob_uri.crt (alebo /banned/devices/uri.crt, ak je zariadenie zakázané) a odovzdaný repo

  • Potom Alice informuje ostatných používateľov (okrem Boba)

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

  • Potom skontroluje, či hlasovanie je vylúčené. To znamená, že >50% správcov súhlasí s zákonom Boba (ak je sama, je to určite viac ako 50%).

  • Ak je hlasovanie vyřešené, súbory do /votes/unban môžu byť odstránené, všetky súbory pre Bob v /membery, /admins, /invited, /CRLs, môžu byť pridané (alebo len v /devices, ak je to zariadenie, ktoré je zakázané) a zapísané do repo

Zrušiť rozhovor

  1. Ušetriť v convInfos odstránený=čas::teraz() (ako odstrániťUšetriť kontakty v kontakte) že konverzácia je odstránená a synchronizovaná s inými zariadeniami používateľa

  2. Ak sa pre tento rozhovor dostane nový záväzok, bude ignorovaný.

  3. Ak je Jamí stále v prevádzke a repo je stále prítomný, konverzácia nie je oznámená klientom.

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

  5. Keď sme si istí, že niekto je synchronizovaný, odstrániť vymazané=čas::teraz() a synchronizovať s inými zariadeniami používateľa

  6. Všetky zariadenia, ktoré vlastnia používatelia, môžu teraz vymazať úložište a súvisiace súbory

Ako určiť režim

Mody sa nemôžu meniť v priebehu času. Alebo je to iný rozhovor. Takže tieto údaje sú uložené v počiatočnej správe o záväzku.

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

V súčasnosti „mode“ prijíma hodnoty 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:

Tento proces je stále rovnaký, účet môže pridať kontakt prostredníctvom addContact, potom poslať TrustRequest prostredníctvom DHT.

  1. TrustRequest obsahuje „konverzáciuId“, aby informoval peera, ktorý rozhovor klonovať pri prijatí žiadosti

  2. TrustRequest sa znova vyskúša, keď sa kontakt vráti online. To nie je dnes prípad (ako nechceme generovať nový TrustRequest, ak peer zamietne prvý). Takže ak účet dostane žiadosť o dôveru, bude automaticky ignorovaný, ak žiadosť s súvisiacou konverzáciou bude odmietnutá (ako convRequests sú synchronizované)

Potom, keď kontakt prijme žiadosť, je potrebná doba synchronizácie, pretože kontakt teraz potrebuje klonovať konverzáciu.

odstrániťContact() odstráni kontakt a súvisiace 1:1 konverzácie (s rovnakým procesom ako „Strháť konverzáciu“). Jediná poznámka je, že ak zakážeme kontakt, nebudeme čakať na synchronizáciu, jednoducho odstranieme všetky súvisiace súbory.

Neudobné scenáre

Existujú prípady, keď sa môžu vytvoriť dve konverzácie.

  1. Alice adds Bob.

  2. Bob accepts.

  3. Alice removes Bob.

  4. Alice adds Bob.

alebo

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

Dôležité

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() vráti {{„synchronizovanie“: „pravdivé“}} v prípade synchronizácie.

  • ConfigurationManager::getConversationMembers() will return a map of two URIs (the current account and the peer who sent the request).

Rozhovory vyžadujú špecifikáciu

Žiadosti o konverzáciu sú zobrazené ** Map<String, String>** s nasledujúcimi klávesmi:

  • id: the conversation ID

  • from: URI of the sender

  • prijaté: časový štempel

  • názov: (voliteľné) meno pre rozhovor

  • opis: (voliteľné)

  • avatar: (optional) the profile picture

Synchronizácia profilov konverzácie

Aby sa konverzácia mohla identifikovať, zvyčajne potrebujú určité metadaty, ako je názov (napr. Jami), opis (napr. niektoré odkazy, čo je projekt atď.) a obraz (logotyp projektu). Tieto metadaty sú volitívne, ale sú zdieľané medzi všetkými členmi, takže je potrebné ich synchronizovať a začleniť do požiadaviek.

Skladovanie v sklade

Profil konverzácie je uložený v klasickom súbore vCard na koreň (/profile.vcf) ako:

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

Synchronizácia

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

Posledné zobrazenie

V synchronizovaných dátách každý zariadenie posiela iným zariadeniam stav konverzácií. V tomto stave sa posiela posledný zobrazený.

Podporuje sa päť scenárov:

  • ak je posledný zobrazený od iných zariadení rovnaký ako súčasný, nie je potrebné nič urobiť.

  • ak sa posledný zobrazený údaj pre súčasné zariadenie neobjaví, použije sa vzdialená zobrazená správa.

  • Ak posledné zobrazené diaľkové zariadenie nie je prítomné v repo, znamená to, že commit bude zobrazený neskôr, takže výsledok sa ukladá v cache

  • Ak je diaľková už vyzdvižená, skontrolujeme, že posledná zobrazená lokalita je v histórii, aby sme ju nahradili

  • Nakoniec, ak sa oznámi správa od toho istého autora, znamená to, že musíme aktualizovať poslednú zobrazenú správu.

Preferencie

Každá konverzácia má pripojené preferencie nastavené používateľom. Tieto preferencie sú synchronizované na všetkých zariadeniach používateľa. Toto môže byť farba konverzácie, ak chce používateľ ignorovať oznámenia, limit veľkosti prenosu súborov atď. Naďalej sú rozpoznané kľúče:

  • „color“ - the color of the conversation (#RRGGBB format)

  • „ignoreNotifications“ - ignorovať oznámenie o nových správách v tomto rozhovore

  • „symbol“ - definovať predvolené emoji.

Tieto preferencie sú uložené v balení MapStringString, uložené v accountDir/conversation_data/conversationId/preferences a odoslané iba cez zariadenia toho istého používateľa prostredníctvom SyncMsg.

API pre interakciu s preferenciami sú:

// 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*/);
};

Riadenie konfliktov spojenia

Keďže dvaja správcovia môžu zmeniť opis naraz, môže sa na profile.vcf vyskytnúť konflikt fúzie. V tomto prípade sa vyberá commit s vyšším hashom (napr. ffffff > 000000).

API

Používateľ má 2 metódy na získanie a nastavenie metadát konverzácie:

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

kde infos je map<str, str> s nasledujúcimi kľúčmi:

  • režim: Len prečítať

  • názov

  • opis

  • avatar: the profile picture

Použité protokoly

Git

Prečo toto rozhodnutie

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

  1. Merklový strom je ideálna štruktúra na to a môže byť lineárny spajaním vetva. Okrem toho, pretože je masívne používaný Gitom, je ľahké synchronizovať medzi zariadeniami.

  2. Rozdeľované prirodzene, masívne používané, veľa záloh a zapínable.

  3. Dokáže overiť záväzky prostredníctvom háčikov a masívne používané kryptomeny

  4. V prípade potreby sa môže uložiť v databáze

  5. Konflikty sa vyhýbajú pomocou odkazov, nie súborov.

Čo musíme potvrdiť

  • Výkonnosť? git.lock môže byť nízka

  • Vypúšťanie

  • Multiple pulls at the same time?

Omezy

Ak chcete odstrániť konverzáciu, musí zariadenie opustiť konverzáciu a vytvoriť novú.

Nepretrvávajúce správy (napríklad správy čitateľné iba niekoľko minút) sa však môžu odosielať prostredníctvom špeciálnej správy prostredníctvom DRT (napríklad oznámenia o typovaní alebo čítaní).

Struktúra

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

Prenos súborov

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.

Protokol

Odšielač do konverzácie pridá nový záväzok v nasledujúcom formáte:

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

a vytvára odkaz v ${data_path}/conversation_data/${conversation_id}/${file_id} kde file_id=${commitid}_${value["tyd"]}.${extension}

Potom môže prijímač teraz stiahnuť súbory kontaktovaním zariadení, ktoré sú hostiteľmi súboru, otvorením kanálu s name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId a uložiť informácie, ktoré súbory čakajú v ${data_path}/conversation_data/${conversation_id}/waiting

Prístroj, ktorý prijme pripojenie, bude prijímať kanál overením, či sa súbor môže odoslať (ak je sha3sum správny a ak existuje súbor). Prijímač zachová prvý otvorený kanál, zavrie ostatné a zapíše do súboru (s rovnakou cestou ako odosielateľ: ${data_path}/conversation_data/${conversation_id}/${file_id}) všetky prichádzajúce údaje.

Keď je prenos hotový alebo kanál zatvorený, sha3sum sa overí, aby sa overilo, že súbor je správny (ak nie je odstránený).

V prípade neúspechu, keď sa zariadenie konverzácie vráti na internet, budeme požiadať o všetky čakajúce súbory rovnakým spôsobom.

Call in Swarm

Nápad

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

„accountUri/deviceId/conversationId/confId“ kde accountUri/deviceId opisuje hostiteľa.

Hostiteľ sa môže určiť dvoma spôsobmi:

  • In the swarm metadatas. Where it’s stored like the title/desc/avatar (profile picture) of the room

  • Alebo prvý volajúci.

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)

Takže každá časť dostane informácie o tom, že hovor začal a bude môcť pripojiť sa k nemu, keď ho zavolá.

Útoky?

  • Avoid Git bombs

Poznámky

Časová značka commit je spoľahlivá, pretože je upraviteľná.

TLS

Gitové operácie, riadiace správy, súbory a iné veci budú používať odkaz P2P TLS v1.3 s iba šiframi, ktoré zaručujú PFS. Takže každý kľúč je pre každé nové pripojenie renegotizovaný.

DHT (UDP)

Používa sa na odoslanie správ pre mobilné telefóny (na spúšťanie push oznámení) a na spúšťanie TCP pripojenia.

Aktivita siete

Proces pozvania niekoho

Alice chce pozvať Boba:

  1. Alice pridáva Bobu k rozhovore

  2. Alice generates an invite: { „application/invite+json“ : { „conversationId“: „$id“, „members“: [{…}] }}

  3. Dve možnosti na odoslanie správy a. Ak nie je pripojená, cez DHT b. Inak Alice posiela na kanáli SIP

  4. Dve možnosti pre Boba a. Prijme pozvanie, signál je vyslaný pre klienta b. Nie je pripojený, takže nikdy nedostane žiadosť, pretože Alice nesmie vedieť, či Bob práve ignoroval alebo zablokoval Alice. Jediný spôsob je regenerovať nové pozvanie prostredníctvom nového správy (pozri ďalší scenár)

Proces odoslania správy niekomu

Alice chce posielať správu Bobovi:

  1. Alice pridá správu do repo, dávajú identifikačné číslo

  2. Alice dostane správu (od seba) ak úspešne

  3. V oboch prípadoch sa vytvorí správa: { „aplikácia/im-gitmessage-id“ : „{„id“:“\(convId", "commit":"\)commitId“, „deviceId“: „$alice_device_hash“}“}. a. Ak nie je pripojená, prostredníctvom DHT b. Inak Alice posiela na kanál SIP

  4. Bob nemá spojenie s Alice, takže ak dôveruje Alice, požiada o nové pripojenie a choďte na b. b. Ak je pripojený, požiadajte od Alice a oznámte nové správy c. Bob nevie o tomto rozhovore. Požiadajte cez DHT, aby ste najprv získali pozvanie, aby ste mohli prijať tento rozhovor ({„prísun/pozvanie“, rozhovorId}) d. Bob je odpojený (bez siete, alebo len uzavretý).

Vykonávanie

! [Diagram: švábové hodiny chat](obrazy/švábové hodiny chat-diagram.jpg)

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

Hovory

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

!! Starý návrh!!

Poznámka

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

Kryptomeny sa zlepšujú.

Pre serióznu funkciu skupinového chatu potrebujeme tiež serióznu kryptografiu. S súčasným dizajnom, ak je certifikát ukradnutý ako predchádzajúce hodnoty DHT konverzácie, konverzácia môže byť dešifrovaná. Možno musíme ísť na niečo ako ** Double ratchet**.

Poznámka

A lib might exist to implement group conversations.

Potrebuje podporu ECC v OpenDHT

Použitie

Pridať úlohy?

Skupinné rozhovory sa používajú v dvoch hlavných prípadoch:

  1. Niečo ako Mattermost v spoločnosti, so súkromnými kanálmi a niektorými úlohy (admin/spektátor/bot/etc) alebo pre vzdelávanie (kde je aktívnych len niekoľko).

  2. Horizontálne rozhovory ako rozhovor medzi priateľmi.

Jami will be for which one?

Nápady na realizáciu

Osvedčenie pre skupinu, ktorá používateľa podpíše vlajkou pre úlohu.

Pridajte sa k konverzácii

  • Iba prostredníctvom priameho pozvania

  • V prípade, že sa to stane,

  • Via a room name? (a hash on the DHT)

Čo potrebujeme

  • Dôvernosť: členovia mimo skupiny by nemali mať možnosť čítať správy v skupine

  • Úvodné tajomstvo: ak je ohrozený kľúč z skupiny, predchádzajúce správy by mali zostať dôverné (tak, ako je to možné)

  • Objednávanie správ: Je potrebné mať správy v správnom poradí

  • Synchronizácia: Je tiež potrebné zabezpečiť, aby všetky správy boli čo najskôr dostupné.

  • Persistence: V skutočnosti správa na DHT žije len 10 minút. Pretože je to najlepšie načasovanie vypočítané pre tento druh DHT. Aby sa údaje udržali, musí uzol znova nastaviť hodnotu na DHT každé 10 minút. Ďalším spôsobom, ako to urobiť, keď je uzol offline, je nechať uzoly znova nastaviť údaje. Ale ak po 10 minútach sú tu ešte 8 uzolov, urobia 64 žiadostí (a je to exponenciálne).

Ostatné rozdeľované spôsoby

  • IPFS: Potrebujem nejaké vyšetrovanie

  • Potrebujem nejaké vyšetrovanie

  • Potrebujem nejaké vyšetrovanie.

Na základe súčasnej práce, ktorú máme

Skupinný chat sa môže zakladať na rovnakom projekte, ktorý už máme pre viac zariadenia (ale tu s skupinovým certifikátom).

  1. Synchronizácia histórie. Musí presunúť databázu z klienta do demóna.

  2. Ak nikto nie je pripojený, synchronizácia sa nemôže uskutočniť a osoba nikdy nebude vidieť konverzáciu

Ďalší DHT

Ako DHT s superpoužívateľom.

What’s next for file transfers

Currently, the file transfer algorithm is based on a TURN connection (See Prenos súborov). 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)

Zásoby