Svaža

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. Nema centralnog tijela, ne može se osloniti na 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.

Glavna ideja je da se sinhronizira Merkle drvo s učesnicima.

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

Scenariji

Stvorite skupu

Bob želi stvoriti novi poraz

  1. Bob creates a local Git repository.

  2. Zatim, on stvara početni potpisni obvezu s sljedećim:

    • Njegov javni ključ u /admins

    • Njegov certifikat uređaja u ̀ / uređaja `

    • Njegov CRL u ̀ /crls`

  3. Hash prvog komita postaje ID razgovora.

  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.

Dodavanje nekoga

Bob adds Alice

  1. Bob adds Alice to the repo:

    • Dodaje pozvani URI u /invited

    • Dodaje CRL u /crls

  2. Bob sends a request on the DHT.

Prihvaćanje pozivnice

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.

Poslanje poruke

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

Napomena

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.

Primanje poruke

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.

Valutacija obveze

Kako bi se izbjeglo da korisnici potjeraju neke neželjene obaveze (s sukobima, lažnim porukama itd.), ovako se svaki obaveze (od najstarijeg do najnovijeg) MUŽE potvrditi prije spajanja udaljene grane:

Napomena

  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.

Zabranite uređaj

Važno

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.

Slični sustavi (s distribuiranim grupnim sustavima) nisu toliko, ali ovo su neki primjeri:

  • [mpOTR ne definiše kako zabraniti nekoga]

  • Signal, bez bilo kojeg središnjeg servera za grupni razgovor (EDIT: nedavno su promijenili to), ne daje mogućnost zabraniti nekoga 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).

Uklonite uređaj iz razgovora

Ovo je jedini dio koji mora imati konsenzus da se izbjegne raspad razgovora, kao što je ako se dva člana udari iz razgovora, što će vidjeti treću?

To je potrebno kako bi se otkrili otkazani uređaji ili jednostavno izbjegli nepromišljeni ljudi u javnoj sobi.

Alice uklanja Boba

Važno

Alice MUST be an admin to vote.

  • Prvo glasa za zabranu Bob-a. Da bi to učinila, ona kreira datoteku u /votes/ban/members/uri_bob/uri_alice (članovi mogu biti zamijenjeni uređajima za uređaj, ili pozvani za pozivnice ili admine za admine) i obavezuje

  • To znači da je >50% administratora složeno zabraniti Bob (ako je sama, sigurno je više od 50%).

  • Ako je glasanje riješeno, datoteke u /votes/ban mogu biti uklonjene, sve datoteke za Bob u /members, /admins, /invited, /CRLs, /devices mogu biti uklonjene (ili samo u /devices ako je uređaj koji je zabranjen) i Bobov certifikat može biti smješten u /banned/members/bob_uri.crt (ili /banned/devices/uri.crt ako je uređaj zabranjen) i angažiran u repo

  • Onda, Alice obavijesti druge korisnike (izvan Bob)

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

  • To znači da je >50% administratora složeno zabraniti Bob (ako je sama, sigurno je više od 50%).

  • Ako je glasanje riješeno, datoteke u /votes/unban mogu biti uklonjene, sve datoteke za Bob u /members, /admins, /invited, /CRLs, mogu biti ponovno dodane (ili samo u /devices ako je uređaj koji je ne zabranjen) i angažiran u repo

Uklonite razgovor

  1. Sačuvanje u convInfos removed=time::now() (kao što je sačuvanjeContact save u kontaktima) da se razgovor ukloni i sinhronizuje s drugim korisničkim uređajima

  2. Ako se novi poziv za ovaj razgovor primi, ignoriran je.

  3. Ako je Jami pokrenut i repo još uvijek prisutan, razgovor nije objavljen klijentima.

  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. Kada smo sigurni da je netko sinhronizirano, uklonite izbrisano= vrijeme:: sada() i sinhronizujte s drugim korisničkim uređajima

  6. Svi uređaji u vlasništvu korisnika sada mogu izbrisati skladište i srodne datoteke

Kako odrediti režim

Mod ne može se promijeniti kroz vrijeme. Ili je to još jedan razgovor. Dakle, ovi podaci se pohranjuju u početnoj obavezi.

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

Za sada, „mode” prihvaća vrijednosti 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:

Proces je i dalje isti, račun može dodati kontakt putem addContact, a zatim poslati TrustRequest putem DHT-a.

  1. TrustRequest ugrađuje „conversationId” kako bi obavijestio vršnjaka koji razgovor klonirati pri prijema zahtjeva

  2. TrustRequest se ponovno pokušava kada se kontakt vrati na mrežu. To nije slučaj danas (što ne želimo generirati novi TrustRequest ako vršnjaci odbace prvi). Dakle, ako nalog prima zahtjev za povjerenje, automatski će se ignorirati ako se zahtjev s povezanim razgovorom odbije (kao convRequests se sinhronizira)

Zatim, kada kontakt prihvati zahtjev, potreban je period sinhronizacije, jer kontakt sada mora klonirati razgovor.

removeContact() će ukloniti kontakt i povezane 1:1 razgovore (s istim postupkom kao „Umaknite razgovor”). Jedina napomena ovdje je da ako zabranimo kontakt, ne čekamo na sinhronizaciju, samo uklonimo sve povezane datoteke.

Neugodni scenariji

U nekim slučajevima mogu se stvoriti dvije razgovore.

  1. Alice adds Bob.

  2. Bob accepts.

  3. Alice removes Bob.

  4. Alice adds Bob.

ili

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

Važno

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() vraća {{„sinkronizacija”: „istina”}} ako se sinhronizuje.

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

Razgovori traže specifikacije

U slučaju da se u ovom slučaju ne može utvrditi kako je to moguće, u skladu s člankom 3. stavkom 1.

  • id: the conversation ID

  • from: URI of the sender

  • Dobiće: vremenski stempel

  • naslov: (neopcionalno) ime za razgovor

  • opisa: (neopcionalno)

  • avatar: (optional) the profile picture

Simcronizacija profila razgovora

Za identifikaciju razgovora obično su potrebni neki metapodatki, kao što su naslov (npr. Jami), opis (npr. neke veze, što je projekt itd.) i slika (logof projekt).

Uloženje u skladištu

Profil razgovora se čuva u klasičnom datoteku vCard na korijenu (/profile.vcf) poput:

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

Sinkronizacija

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

Posljednji prikaz

U sinhronizovanoj podaci, svaki uređaj šalje drugim uređajima stanje razgovora. U tom stanju, posljednji prikazan je poslan. Međutim, jer svaki uređaj može imati svoj vlastiti stanje za svaki razgovor, i vjerojatno bez iste posljednje obveze u nekom trenutku, postoje nekoliko scenarija koje treba uzeti u obzir:

Podržani su 5 scenarija:

  • Ako je posljednji prikazan koji su poslali drugi uređaji isti kao i sadašnji, nema što učiniti.

  • ako za trenutni uređaj nije prikazan posljednji, koristi se udaljena prikazana poruka.

  • Ako posljednji udaljeni prikazan nije prisutan u repo, to znači da će se commit kasnije dobiti, tako da se rezultat sakupi

  • Ako je daljinski uređaj već prikupljen, provjerimo je li lokalni posljednji prikazan je prije u povijesti da ga zamijenimo

  • Konačno, ako se objavi poruka istog autora, to znači da moramo ažurirati posljednji prikazan.

Prihvatljivosti

U svakom razgovoru su priložene preferencije koje je korisnik postavio. Te preferencije se sinhronizuju na korisnikovim uređajima. Ovo može biti boja razgovora, ako korisnik želi ignorirati obavijesti, ograničenje veličine prenosa datoteka itd. Za sada, prepoznatljivi ključevi su:

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

  • „ignoreNotifications” - ignorirati obavijesti o novim porukama u ovom razgovoru

  • „simbol” - definirati podrazumevan emoji.

U skladu s člankom 3. stavkom 1. stavkom 1. stavkom 1. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2. stavkom 2.

U skladu s člankom 1. stavkom 1. stavkom 1.

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

U skladu s člankom 1. stavkom 1.

Budući da dva admina mogu istovremeno promijeniti opis, može se dogoditi sukob spajanja na profile.vcf. U ovom slučaju, odabrati će se commit s većom hashom (npr. ffffff > 000000).

Ugrađivanje

Korisnik je dobio 2 metode za dobivanje i postavljanje metadata razgovora:

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

u kojem je info map<str, str> s sljedećim ključevima:

  • U slučaju da se ne može koristiti

  • naslov

  • opisa

  • avatar: the profile picture

Korisni protokoli

-Git

Zašto je ovaj izbor

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

  1. Merklov stablo je savršena struktura za to i može se linearizirati spajanjem grana.

  2. -Distributiran od prirode, masovno korišten, puno backendova i priključiv.

  3. Mogu provjeriti obveze putem hakova i masovno korištenog kriptovalute

  4. Mogu se pohraniti u bazi podataka ako je potrebno

  5. Konflikti se izbjegavaju korištenjem commit poruka, a ne datoteka.

Što moramo potvrditi

  • Učinkovitost? git.lock može biti niska

  • Vruče u libgit2

  • Više puca u isto vrijeme?

Ograničenja

Da bi izbrisali razgovor, uređaj mora napustiti razgovor i stvoriti drugi.

Međutim, ne-stalne poruke (kao što su poruke koje se mogu čitati samo nekoliko minuta) mogu se poslati putem posebne poruke putem DRT-a (kao što su obavijesti o pisanju ili čitanju).

Structura

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

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

Poslač dodaje novi commit u razgovor s sljedećim formatom:

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 stvara vezu u ${data_path}/conversation_data/${conversation_id}/${file_id} gdje file_id=${commitid}_${value["tid"]}.${extension}

Nakon toga, primatelj sada može preuzeti datoteke kontaktiranjem uređaja koji hostiraju datoteku otvaranjem kanala s name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId i pohraniti informacije da je datoteka čeka u ${data_path}/conversation_data/${conversation_id}/waiting

Pripremlja koja prima vezu će prihvatiti kanal provjerom da li se datoteka može poslati (ako je sha3sum ispravna i ako datoteka postoji). Prijemnik će zadržati prvi otvoren kanal, zatvoriti ostale i zapisati u datoteku (s istim putem kao i šalitelj: ${data_path}/conversation_data/${conversation_id}/${file_id}) sve prihađane podatke.

Kada je prijenos završen ili kanal zatvoren, sha3sum se provjerava kako bi se potvrdilo da je datoteka ispravna (ili je izbrisana).

U slučaju neuspjeha, kada se uređaj razgovora vrati na mrežu, tražimo sve čekajuće datoteke na isti način.

Call in Swarm

Ideja

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

„Uri računa/aparatId/konverzijaId/konfId” gdje se u Uri računa/aparatId opisuje gostitelj.

Domaćin može se odrediti na dva načina:

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

  • Ili početni pozivnik.

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)

Dakle, svaki dio će dobiti informacije da je poziv započeo i moći će se pridružiti tako da ga nazove.

Napadi?

  • Avoid Git bombs

Uloga

Vreme za obvezu može se vjerovati jer je uređivano.

TLS

Git operacije, kontrolne poruke, datoteke i druge stvari će koristiti p2p TLS v1.3 link s samo šiframa koji jamče PFS.

DHT (UDP)

Koristi se za šaljanje poruka za mobilne uređaje (za pokretanje push obavijesti) i za pokretanje TCP povezivanja.

Aktivnost mreže

Proces poziva nekoga

Alice želi pozvati Boba:

  1. Alice dodate Bob u razgovor

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

  3. Dvije mogućnosti za slanje poruke a. Ako nije povezano, preko DHT b. Inače, Alice šalje na SIP kanala

  4. Bob je dobio poziv, signal je emitiran za klijentu b. Nije povezan, tako da nikada neće primiti zahtjev jer Alice ne smije znati da li je Bob upravo ignorirao ili blokirao Alice.

Proces za šaljanje poruke nekome

Alice želi poslati poruku Bobu:

  1. Alice doda poruku u repo, daje identifikaciju

  2. Alice dobiva poruku (od sebe) ako uspješno

  3. U oba slučaja se stvara poruka: { „aplikacija/im-git-message-id” : „{„id”:”\(convId", "komit":"\)commitId”, „deviceId”: „$alice_device_hash”}”}. a. Ako nije povezano, preko DHT b. Inače, Alice šalje na SIP kanal

  4. Bob nije povezan s Alice, pa ako vjeruje Alice, pitajte za novu vezu i idite na b. b. Ako je povezan, uzmite od Alice i najavite nove poruke c. Bob ne zna taj razgovor. Tražite preko DHT-a da primi poziv prije nego što možete prihvatiti taj razgovor ({„aplikacija/upitavanje”, razgovorId}) d. Bob je isključen (nema mreže ili je samo zatvoren).

Uprikazivanje

[Diagram: šarm chat klase](izvodi/swarm chat-klas-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"
}

Pozivi

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

!! Stari nacrt!!

Napomena

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

Crypto improvements.

Za ozbiljnu grupnu funkciju razgovora, trebamo i ozbiljnu kriptografiju. S trenutnim dizajnom, ako se potvrda ukrade kao prethodne vrijednosti DHT razgovora, razgovor se može dešifrirati. Možda trebamo ići na nešto poput Duple ratchet.

Napomena

A lib might exist to implement group conversations.

Potreban je ECC-ov podršak u OpenDHT-u

Ugrađivanje

Dodavanje uloge?

Postoje dva glavna slučaja korištenja za grupne razgovore:

  1. Nešto poput Mattermost u tvrtki, sa privatnim kanalima, i nekim ulogama (admin/spectator/bot/etc) ili za obrazovanje (gdje je aktivno samo nekoliko).

  2. Horizontalni razgovori kao razgovor između prijatelja.

Jami will be for which one?

Ideja za provedbu

Certifikat za grupu koja potpiše korisnika zastavom za ulogu.

Pridruži se razgovoru

  • Samo putem direktnog poziva

  • Ključ/QR kod/što god

  • -Kroz ime sobe?

Što nam treba

  • Privrednost: članovi izvan grupnog razgovora ne bi trebali moći čitati poruke u grupi

  • Prijava: ako je bilo koji ključ u grupi kompromitiran, prethodne poruke treba ostati povjerljive (što je moguće više)

  • U redu je redoslijed poruka:

  • Simkronizacija: Također je potrebno biti sigurna da sve poruke imaju što je prije moguće.

  • Ustanovljivost: Zapravo, poruka na DHT-u živi samo 10 minuta. Jer je to najbolje vrijeme izračunano za ovu vrstu DHT-a. Da bi se podaci ostvarili, čvor mora ponovno staviti vrijednost na DHT-u svakih 10 minuta. Drugi način da se to učini kada je čvor offline je pustiti čvorove da ponovno stavljaju podatke. Ali, ako nakon 10 minuta, 8 čvorova su još uvijek ovdje, oni će učiniti 64 zahtjeva (i to je eksponencijalno). Trenutni način da se izbjegne spamiranje za to je upitan. To će još uvijek učiniti 64 zahtjeva, ali ograničiti maksimalno redundanciju na 8 čvorova.

S druge strane,

  • IPFS: Treba malo istrage

  • Treba mi istraživanje.

  • Treba mi nešto istrage.

Na temelju trenutnog rada koji imamo

Grupa čata može se zasnivati na istom radu koje već imamo za više uređaja (ali ovdje, s grupnim potvrdom).

  1. Ovo treba pomaknuti bazu podataka iz klijenta u demona.

  2. Ako nitko nije povezan, sinhronizacija se ne može napraviti, a osoba nikada neće vidjeti razgovor

Još jedan posvećen DHT

Kao DHT sa super korisnikom.

What’s next for file transfers

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

Povratak