Sääli

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. Ei keskusviranomaisia, ei palvelijoita.

  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.

Pääaine on synkronoida Merkle-puun osallistujien kanssa.

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

Scenarioita

Luotaan joukko

Bob haluaa luoda uuden joukon.

  1. Bob creates a local Git repository.

  2. Sitten hän tekee aluksi allekirjoitetun sitoumuksen seuraavasti:

    • Hänen avaimensa on /admins

    • Hänen laitteen todistuksensa ̀ / laitteissa `

    • Hänen CRL:sä on ̀ /crls`

  3. Ensimmäisen sitoutumisen hashista tulee keskustelun tunnus.

  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.

Lisää joku

Bob adds Alice

  1. Bob adds Alice to the repo:

    • Lisää kutsuttu URI /invited

    • Lisää CRL:n /crls

  2. Bob sends a request on the DHT.

Kutsun vastaanottaminen

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.

Lähetä viesti

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

Muista

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.

Saamme viestin

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.

sitoumuksen vahvistaminen

Jotta käyttäjät eivät tule tekemään toisiaan vastaan epätoivottuja sitoumuksia (sota konflikteja, väärä viestiä jne.), jokainen sitoumus (vanhempista uusimmille) on oltava todennettu ennen kauko-alueen yhdistämistä:

Muista

  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.

Kieltäkää laitteet

Tärkeä

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.

Samaa järjestelmää (joilla on jakautuneet ryhmäjärjestelmät) ei ole niin paljon, mutta tässä on muutamia esimerkkejä:

  • [mpOTR ei määritä, miten kieltää joku]

  • Signal, ilman keskitettua serveriä ryhmäkeskustelulle (EDIT: he muuttivat tuota kohtaansa hiljattain), ei anna mahdollisuutta kieltää jotakuta ryhmältä.

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

Poista puhelimesta laitteen

Tämä on ainoa osa, jossa on oltava yhteinen päätös, jotta keskustelu ei jakaudu. Jos kaksi jäsentä potkii toisiaan, mitä kolmas näkee?

Tämä on tarpeen peruutetun laitteen havaitsemiseksi tai yksinkertaisesti välttää haluttomien ihmisten läsnäolon julkisessa huoneessa.

Alice poistaa Bobin.

Tärkeä

Alice MUST be an admin to vote.

  • Hän äänesti Bobin kieltoa varten ja luo tiedoston /votes/ban/members/uri_bob/uri_alice (jäseniä voidaan korvata laitteilla laitteelle tai kutsua kutsuille tai hallinnoille) ja sitoutuu

  • Hän tarkistaa, onko äänestys ratkaistu, mikä tarkoittaa, että > 50%:n hallitsijoista suostuu kielteeseen Bobin (jos hän on yksin, se on varmasti yli 50%).

  • Jos äänestys ratkaistaan, tiedostoja /votes/ban voidaan poistaa, kaikki Bobin tiedostot /members, /admins, /invited, /CRLs, /devices voidaan poistaa (tai vain /devices, jos se on laite, joka on kielletty) ja Bobin todistus voidaan sijoittaa /banned/members/bob_uri.crt (tai /banned/devices/uri.crt, jos laite on kielletty) ja sitoutua repo

  • Sitten Alice ilmoittaa muille käyttäjille (Bobin ulkopuolella)

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

  • Hän tarkistaa, onko äänestys ratkaistu, mikä tarkoittaa, että > 50%:n hallitsijoista suostuu kielteeseen Bobin (jos hän on yksin, se on varmasti yli 50%).

  • Jos äänestys ratkaistaan, tiedostoja /votes/unban voidaan poistaa, kaikki Bobin tiedostot /jäsenissä, /admins, /invited, /CRLs, voidaan lisätä uudelleen (tai vain / laitteissa, jos se on laitetta, joka on kielletty) ja sitoutua repo

Poista keskustelu

  1. Säästä convInfos removed=time::now() (kuten poistatKontakti säästää yhteystoimissa) että keskustelu poistetaan ja synkronoidaan muiden käyttäjien laitteiden kanssa

  2. Jos uusi sitoumus tulee, se ei ole huomioitu.

  3. Jos Jami käynnistää ja repo on yhä läsnä, keskustelu ei ilmoiteta asiakkaille.

  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. Kun olemme varmoja, että joku on synkronoitu, poista erased=time::now() ja synkronoida muiden käyttäjien laitteiden kanssa

  6. Kaikki käyttäjän omistamat laitteet voivat nyt poistaa tallennus ja niihin liittyvät tiedostot

Miten määrittää toimintatapa

Muotintoa ei voi muuttaa ajan kuluessa tai se on toinen keskustelu.

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

Tällä hetkellä ”modus” hyväksyy arvoja 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:

Prosessi on edelleen sama, tili voi lisätä yhteydenpito addContactin kautta ja lähettää sitten TrustRequest DHT:n kautta.

  1. TrustRequest-ohjelmassa on ”talkIde”, joka kertoo, minkä keskustelun kloonaaminen on tehtävä, kun pyydetty hyväksyy

  2. TrustRequest-pyyntö tehdään uudelleen, kun yhteys tulee takaisin verkkoon. Tämä ei ole tapaus tänään (esimerkiksi emme halua luoda uutta TrustRequest-pyyntöä, jos vertaisemme hylkäävät ensimmäisen). Jos tili saa luottamuspyyntöä, se jätetään automaattisesti, jos pyyntö liittyy asiaan liittyvään keskusteluun hylätään (kun convRequests synkronoidaan)

Kun yhteys hyväksyy pyynnön, synkronointi on tarpeen, koska yhteydenotto tarvitsee nyt kloonaation.

removeContact() poistaa yhteyden ja siihen liittyvät 1:1-puhujat (samalla prosessilla kuin ”Poista keskustelu”).

Kiusallisia skenaarioita

Joskus voidaan luoda kaksi keskustelua, ja tässä on ainakin kaksi tällaista skenaaria:

  1. Alice adds Bob.

  2. Bob accepts.

  3. Alice removes Bob.

  4. Alice adds Bob.

tai

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

Tärkeä

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() palauttaa {{”syncing”: ”true”}} synkronoinnin yhteydessä.

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

Keskusteluiden pyyntö

Keskustelukysymykset on ilmaistava Map<String, String>** seuraavasti:

  • id: the conversation ID

  • from: URI of the sender

  • vastaanotettu: aikavarmuus

  • otsikko: (valinnainen) keskustelun nimi

  • kuvaus: (valinnainen)

  • avatar: (optional) the profile picture

Keskustelun profiilijärjestely

Jotta keskustelu olisi tunnistettavissa, se tarvitsee yleensä metatietoja, kuten otsikon (esim. Jami), kuvauksen (esim. linkit, mikä on projekti jne.) ja kuvan (hankkeen logo).

Säilytys säilytyslaitossa

Keskustelun profiili tallennetaan klassiseen vCard-tiedostoon juuressa (/profile.vcf) kuten:

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

Synkronointi

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

Viimeinen kuvaus

Synkronoituissa tietoihin jokainen laite lähettää muiden laitteiden keskustelun tilaa. Tässä tilassa lähetetään viimeinen näytetty.

Tuetaan viisi skenaariota:

  • Jos viimeinen, jonka lähettävät muut laitteet, on sama kuin nykyinen, ei ole mitään tehtävää.

  • Jos nykyisen laitteen viimeinen näyttö ei ole, käytetään kaukosäyttöön näytettävää viestiä.

  • Jos viimeinen näytetty kaukosähkö ei ole repo-lehdessä, se tarkoittaa, että commit otetaan myöhemmin, joten se tallentaa tuloksen

  • Jos etäkautta on jo hakenut, tarkistamme, onko viimeinen näytetty paikallinen aikaisemmin historiassa korvaaakseen sen

  • Lopuksi, jos sama kirjailija ilmoittaa viestin, se tarkoittaa, että meidän on päivitettävä viimeinen näytetty.

Asetukset

Jokaisessa keskustelussa on liitetty käyttäjän asettamia mieltymykset. Nämä mieltymykset synkronoidaan käyttäjän laitteiden välillä. Tämä voi olla keskustelun väri, jos käyttäjä haluaa jättää huomautukset huomiotta, tiedostojen siirron koon rajoitus jne. Tällä hetkellä tunnetaan avaimet ovat:

  • ”color” - the color of the conversation (#RRGGBB format)

  • ”ignoreNotifications” - jättää huomiotta uudet viestejä koskevia ilmoituksia tässä keskustelussa

  • ”symboli” - määritellä oletusarvoinen emoji.

Nämä ennakkot tallennetaan MapStringString-pakettiin, joka tallennetaan accountDir/conversation_data/conversationId/preferences ja lähetetään vain saman käyttäjän laitteiden välillä SyncMsg:n kautta.

API:n käyttöä, jolla on vuorovaikutus mieltymyksineen, on:

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

Solujen konfliktien hallinta

Koska kaksi administrattoria voi muuttaa kuvausta samanaikaisesti, profile.vcf:ssä voi esiintyä fuusiongelmaa. Tässä tapauksessa valitsee commit, jossa on korkeampi hash (esim. ffffff > 000000).

API:t

Käyttäjä sai 2 menetelmää saadakseen ja asettamaan keskustelun metatatat:

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

jossa infos on map<str, str> seuraavasti:

  • Luku: Luku-aine

  • nimikkeen

  • kuvaus

  • avatar: the profile picture

Käytetty protokolli

Git

Miksi tämä valinta

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

  1. Merkle-puun avulla voidaan synkronoida sivujen yhdistäminen, koska Git käyttää sitä paljon, ja sen avulla laitteiden välillä on helppo synkronoida.

  2. Luonto on sitä, joka jakaa, käyttää, käyttää, käyttää ja käyttää.

  3. Voidaan tarkistaa sitoumukset hakkien ja massiivisesti käytettyjen kryptovaluutan avulla

  4. Se voidaan tallentaa tietokannassa tarvittaessa

  5. Konflikteja vältetään käyttämällä commit-viestejä, ei tiedostoja.

Mitä meidän on vahvistettava

  • git.lock voi olla alhainen

  • Liibgit2 -hakka

  • Monenlaiset vetävät samanaikaisesti?

Rajoitukset

Historiasta ei voi poistaa.

Ei-vaikaiset viesteet (esimerkiksi vain muutaman minuutin lukemattomat viesteet) voidaan kuitenkin lähettää erityisen viestin kautta DRT:n kautta (esimerkiksi kirjoitus- tai lukemiskirjeet).

Rakenne

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

Tiedostojen siirto

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.

pöytäkirja

Lähettäjä lisää keskustelussa uuden sitoutumisen seuraavalla muodolla:

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

ja luo linkin ${data_path}/conversation_data/${conversation_id}/${file_id} jossa file_id=${commitid}_${value["tiid"]}.${extension}

Sitten vastaanottaja voi nyt ladata tiedostot ottamalla yhteyttä tiedoston vastaanottaviin laitteisiin avaamalla kanava name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId ja tallentaa tiedot tiedostosta odottavasta ${data_path}/conversation_data/${conversation_id}/waiting

Sähköyhteyden vastaanottava laite hyväksyy kanavan tarkistamalla, voidaanko tiedosto lähettää (jos sha3sum on oikea ja jos tiedosto on olemassa). vastaanottaja pitää ensimmäisen avatun kanavan, sulkee muut ja kirjoittaa tiedostolle (samalla polulla kuin lähettäjä: ${data_path}/conversation_data/${conversation_id}/${file_id}) kaikki saapuvat tiedot.

Kun siirto on valmis tai kanava suljettu, sha3sum tarkistetaan, että tiedosto on oikea (tai se poistetaan). Jos se on voimassa, tiedosto poistetaan odottamisesta.

Jos puhelu epäonnistuu, kun puhelu-laite on taas käynnissä, pyydämme kaikki odottamislaitteet samalla tavalla.

Call in Swarm

Ajatus

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

”tunnusUri/laitteenId/käsittelyId/selvä” jossa accountUri/laitteenId kuvailee isäntä.

Isäntä voidaan määrittää kahdella tavalla:

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

  • Tai ensimmäinen soittaja.

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)

Jokainen osa saa tiedon, että puhelu on käynnistynyt ja voi liittyä siihen soittamalla.

Hyökkäykset?

  • Avoid Git bombs

Huomattaukset

Kun commit-tiedosto on laadittu, se on muokkavissa.

TLS

Git-operaatioissa, ohjausviesteissä, tiedostoissa ja muissa asioissa käytetään p2p TLS v1.3 -linkkiä, joissa on vain kytkät, jotka takaavat PFS: n.

DHT (UDP)

Käytetään lähettämään viestejä mobiileille (työttömyysilmoituksia käynnistämiseen) ja TCP-yhteyksiä käynnistämiseen.

Verkostoteollisuus

Process to invite someone

Alice haluaa kutsua Bobin.

  1. Alice lisää Bobia keskustelulle

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

  3. Jos ei ole yhteydessä DHT b:n kautta, Alice lähettää SIP-kanavalla

  4. Bob a. Saatii kutsun, signaali lähetetään asiakkaan b. Ei ole yhteydessä, joten ei koskaan saa pyytää, koska Alice ei saa tietää, jos Bob vain huomioinut tai estänyt Alice.

Lähetysprosessi

Alice haluaa lähettää viestin Bobille:

  1. Alice lisäsi viestin repoon, antamalla tunnisteen

  2. Alice saa viestin, jos se onnistuu.

  3. A. Jos se ei ole yhteydessä DHT b:n kautta, Alice lähettää SIP-kanavalla

  4. Bobilla on neljä mahdollisuutta: a. Bob ei ole yhteydessä Alicelle, joten jos hän luottaa Alicelle, pyydä uutta yhteyttä ja mene b. b. Jos hän on yhteydessä, ota Aliceiltä ja ilmoita uudet viestejä c. Bob ei tunne tätä keskustelua. Pyydä DHT:tä saada kutsu ensin voidakseen hyväksyä sen keskustelun ({”hakemus/kutsun”, keskustelunId}) d. Bob on eronnut (ei verkko, tai vain suljettu). Hän ei saa uutta viestiä, mutta yrittää synkronoida, kun seuraava yhteys tapahtuu

Käytäntöönpano

! [Diagramma: ruumis-chat-luokat]

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

Puhelut

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

!! Vanha luonnoksella!!

Muista

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

Kriptovaluuttot.

Jos kyseessä on DHT-arvo, joka on ennen keskusteluja, keskustelu voidaan decryptata. Ehkä meidän täytyy mennä johonkin kuin Double ratchet.

Muista

A lib might exist to implement group conversations.

Tarvitaan ECC:n tukea OpenDHT:ssä

Käyttö

Lisää rooleja?

Ryhmäpuheissa on kaksi suurta käyttötapahtumaa:

  1. Jotain kuin Mattermost yrityksessä, yksityiskanavilla ja joillakin rooleilla (admin/spectator/bot/etc) tai koulutukselle (jos vain muutamia ovat aktiivisia).

  2. Horisontaaliset keskustelut ovat kuin ystävien keskustelut.

Jami will be for which one?

Käytännöksen idea

Kirjan lisättäminen tai peruuttaminen voidaan tehdä myös.

Liity keskusteluun

  • Vain suoraan kutsuttu

  • Linkin/QR-koodin/joka tahansa

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

Mitä tarvitsemme

  • Luottamuksellisuus: ryhmän chatin ulkopuolella olevien jäsenten ei pitäisi voida lukea ryhmässä olevia viestejä

  • Siihen asti, kun avain on hajottu, aikaisemmat viestit tulisi säilyttää luottamuksellisina (mikä suurempi kuin mahdollista).

  • Viestien järjestäminen: Viestejä on oltava oikeassa järjestyksessä

  • Synkronisation: On myös tarpeen varmistaa, että kaikki viestejä on saatavilla mahdollisimman pian.

  • Kestävyys: Itse asiassa DHT:n viesti kestää vain 10 minuuttia. Koska tämä on tämäntyyppisen DHT:n laskettu paras aika. Kestävyyden vuoksi tietot täytyy siirtää uudelleen DHT:n arvon joka 10 minuutin välein. Toinen tapa tehdä, kun node on offline, on antaa nodeille siirtää uudelleen tiedot. Mutta jos 10 minuutin kuluttua 8 node on vielä täällä, ne tekevät 64 pyyntöä (ja se on eksponentiaalinen).

Muut jakautuneet keinot

  • Tarvitsen tutkimusta.

  • Tarvitsen tutkimusta.

  • Tarvitsen tutkimusta.

Tällä hetkellä meillä on

Ryhmächatti voidaan perustaa samaan työhön, jota meillä on jo monenlaisiin laitteisiin (mutta tässä ryhmäsertifikaattiin).

  1. Tämä siirtää tietokannan asiakkaan ja demonin.

  2. Jos kukaan ei ole yhteydessä, synkronointi ei voi tapahtua, eikä henkilö koskaan näe keskustelua

Toinen erikoistunut DHT

Like a DHT with a superuser. (Not convinced)

What’s next for file transfers

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

Varain