Ipurdi-zuloa

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. Ez dago autoritate zentralik, ez dago zerbitzari batengan konfiantzarik.

  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.

Ideia nagusia Merkle zuhaitz bat lortzea da.

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

Eszenarioak

Sorgindu talde bat

Bobek talde berri bat sortu nahi du.

  1. Bob creates a local Git repository.

  2. Ondoren, hasierako konpromisoa sinatzen du honekin:

    • Giltza publikoa /admins

    • Bere gailuaren ziurtagiria ̀ /gailuetan

    • Bere CRL-a ̀ /crls`

  3. Lehen konpromisoaren hash-a elkarrizketaren ID-a bihurtzen da.

  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.

Norbait gehitzen.

Bob adds Alice

  1. Bob adds Alice to the repo:

    • Gonbidatuen URI gehitzen da /invited

    • CRL gehitzen da /crls

  2. Bob sends a request on the DHT.

Gonbidapena jasotzea

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.

Mezu bat bidaltzen

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

Oharra

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.

Mezu bat jasotzen

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.

Konpromiso bat egiaztatzea

Erabiltzaileek nahi ez diren konpromiso batzuk bultzatzea saihesteko (gatazkak, mezu faltsuak, etab.), horrela egin behar da konpromiso bakoitza ( Zaharrena berria) urruneko adar bat bildu aurretik:

Oharra

  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.

Debekatu gailu bat.

Garrantzitsua

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.

Antzeko sistemak (talde banatuekin) ez dira asko, baina hauek adibide batzuk dira:

  • [mpOTRk ez du definitzen nola debekatu norbait]

  • Seinaleak, talde-txata egiteko zerbitzari zentralik gabe (EDIT: puntu hori aldatu dute duela gutxi), ez du ematen norbaitek taldetik kanporatzeko gaitasuna.

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

Kendu gailua elkarrizketatik

Hau da elkarrizketa zatitzea saihesteko adostasun bat behar duen zatirik bakarra. Bi kide elkarri ostikoka hasten badira, zer gertatuko da hirugarrenarekin?

Hau beharrezkoa da desjabetutako gailuak detektatzeko, edo nahi ez diren pertsonak gela publiko batean presentzia saihesteko.

Alice Bob kentzen ari da.

Garrantzitsua

Alice MUST be an admin to vote.

  • Lehenengo, Bob-en debekatzearen alde bozkatzen du. Horretarako, fitxategia /votes/ban/members/uri_bob/uri_alice (memberrak gailu bateko gailuek ordezkatu ahalko dituzte, edo gonbidapenerako gonbidatu edo administratzaileentzat) sortzen du eta konpromisoa hartzen du

  • Orduan, bozkatzea ebatzi den egiaztatzen du. Horrek esan nahi du administratzaileen %50ek Bob debekatzea onartzen duela (Bob bakarrik badago, %50 baino gehiago da ziur).

  • Bozketa ebatzi bada, /votes/ban artxibatuak kendu daitezke, Bob-entzako artxibo guztiak /members, /admins, /invited, /CRLs, /devices-en kendu daitezke (edo soilik /devices-etan galarazi den gailu bat bada) eta Bob-en ziurtagiria /banned/members/bob_uri.crt-en sartu daitezke (edo /banned/devices/uri.crt gailu bat debekatuta badago) eta repo-ra eman.

  • Orduan, Alice-k beste erabiltzaileei (Bob-etik kanpo)

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

  • Orduan, bozkatzea ebatzi den egiaztatzen du. Horrek esan nahi du administratzaileen %50ek Bob debekatzea onartzen duela (Bob bakarrik badago, %50 baino gehiago da ziur).

  • Bozketa ebatzi bada, /bozketa/desbango artxiboak kendu daitezke, Bob-entzako artxibo guztiak /kideetan, /adminsetan, /invitatuetan, /CRLetan, gehitu daitezke (edo bakarrik /aparatuetan debekatu gabeko gailua bada) eta repoari konprometitu.

Kendu elkarrizketa bat.

  1. Konpon ezazu konbinatuetan konbinatuak kendu = denbora:: orain() (kontaketan gorde dituen kontaktua kentzea bezala) elkarrizketa kendu eta beste erabiltzaileen gailuekin sinkronizatzea

  2. Elkarrizketa honetarako konpromiso berri bat jasotzen bada, ez da onartzen.

  3. Jami-ren martxan jarriz gero eta erreposak oraindik badaude, ez da elkarrizketa bezeroei iragartzen.

  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. Norbait sinkronizatzen ari dela ziur zaudenean, ezabatu erratua=time::now() eta sinkronizatu beste erabiltzaile baten gailuekin

  6. Erabiltzailearen jabetzako gailu guztiek ezabatu ahal izango dituzte artxiboak eta artxiboak.

Modua nola zehaztu

Moduak ezin dira aldatu denboran zehar. Edo beste elkarrizketa bat da. Beraz, datu hauek lehen konpromiso mezuan gordetzen dira. konpromiso mezuak honako hau izango da:

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

Oraingoz, «moduak» balioak onartzen ditu 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:

Prozesua oraindik berdina da, kontu batek kontaktua gehitu dezake addContact bidez, eta gero TrustRequest bat bidali DHT bidez.

  1. TrustRequest-ek «konbersazio-Id» bat txertatzen du lankideari eskaria onartzen duenean zein elkarrizketa klonatzeko.

  2. TrustRequest berriro saiatzen dira kontaktua berriro online da. Gaur egun ez da horrela (ez dugu nahi TrustRequest berria sortzeko, orok baztertzen lehen). beraz, kontua konfiantza eskaera jaso bada, automatikoki baztertu egingo da, erlazionatutako elkarrizketa eskaera baztertu bada (convRequests sinkronizatu dira)

Gero, kontaktu batek eskaera onartzen duenean, sinkronizazio-denbora beharrezkoa da, kontaktuak orain elkarrizketa klonatzeko beharra baitu.

«Contact» (deleteContact) kontaktuak eta 1:1 elkarrizketak kenduko ditu (konbertsitate bat kentzeko prozesu berarekin).

Egoera zail bat

Badira kasu batzuk non bi elkarrizketa sortu daitezke.

  1. Alice adds Bob.

  2. Bob accepts.

  3. Alice removes Bob.

  4. Alice adds Bob.

edo

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

Garrantzitsua

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() sinkronizatzen bada, {{«sinkronizazioa»: «egia»}} itzuliko da.

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

Elkarrizketak zehaztasunaren eskaera

Elkarrizketa-eskaerak ** Map<String, String>** batekin adierazten dira, eta hauek dira:

  • id: the conversation ID

  • from: URI of the sender

  • jasota: denbora-markak

  • Izenburua: Elkarrizketaren izena (hautazkoa)

  • deskribapena: (hautazkoa)

  • avatar: (optional) the profile picture

Elkarrizketaren profila sinkronizatzea

Elkarrizketa bat identifikatu ahal izateko, meta-datuak behar dira, adibidez, izenburua (adibidez: Jami), deskribapena (adibidez: estekak, zein da proiektua, etab.) eta irudia (proiektuaren logoa).

Biltegian gordetzea

Elkarrizketaren profila vCard fitxategi klasiko batean gordetzen da erro (/profile.vcf) honelako:

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

Sinkronizazioa

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

Azkenekoz agertu

Datu sinkronizatuak, gailu bakoitzak beste gailu batzuetara bidaltzen ditu elkarrizketen egoera. egoera honetan, azkeneko agertzen dena bidaltzen da.

5 eszenario babesten dira:

  • Beste gailu batzuek bidalitako azken irudia egungoarekin bat bazaio, ez dago ezer egiteko.

  • gailu egungo azkeneko agerraldia ez bada, urrutiko mezu agerraldia erabiltzen da.

  • azken urrutiko agerian utzi ez bada erreposan, esan nahi du commit geroago jasoko dela, beraz, cache emaitza

  • Urrutiko agintea dagoeneko hartuta badago, egiaztatu behar dugu azkeneko agertu den tokiko agintea aurretik dagoen historia batean ordezkatu ahal izateko.

  • Azkenik, egile beraren mezu bat iragarri badugu, azkeneko mezuaren egunerapena behar dugu.

Atseginak

Elkarrizketa bakoitzean erabiltzaileak ezarritako nahia gehitu da. Nahiagoenak erabiltzailearen gailuetan sinkronizatzen dira. Hau izan daiteke elkarrizketaren kolorea, erabiltzaileak jakinarazpenak baztertu nahi baditu, fitxategi transferentziaren tamainako muga, etab. Oraingoz, ezagututako gakoak dira:

  • «color» - the color of the conversation (#RRGGBB format)

  • «ez ikusi iragarkiak» - elkarrizketa honetan mezu berriak ez aipatzeko

  • «simbulu» - emoji bat definitzeko.

Maila horretako hautaketak MapStringString pakete batean gordetzen dira, accountDir/conversation_data/conversationId/preferences-n gordetzen dira eta erabiltzaile beraren gailuen artean soilik bidaliko dira SyncMsg bidez.

APIak lehentasunen artean interakzioan jar ditzake:

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

Fusioen gatazken kudeaketa

Bi administratzaileek deskribapena aldi berean alda dezakete, eta horrek bultzada bat eragiten du profile.vcf. Kasu honetan, hash handiagoa duen commit (adibidez ffffff > 000000) aukeratuko da.

APIak

Erabiltzaileak bi metodo ditu elkarrizketaren metadata lortzeko eta ezartzeko:

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

non infos t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t t

  • Modua: Irakurketa bakarrik

  • izenburua

  • deskribapena

  • avatar: the profile picture

Erabilitako protokoloak

-Ez.

Zergatik aukeratu duzu?

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

  1. Mezuak sinkronizatu eta ordenatu behar ditugu. Merkle Zuhaitza egitura perfektua da horretarako eta adarrak batzean linealizatu daiteke. Gainera, Git-ek erabilera masiboa duelako, erraza da gailuen arteko sinkronizazioa.

  2. Naturak banatzen du, erabilgarria da, atzekoz aurrera eta konektatu daiteke.

  3. Konpromisoak egiaztatu ditzakezue kakoen bidez eta masiboki erabiltzen den kriptografia

  4. Beharrezkoa bada, datu basean gorde daiteke.

  5. Gatazka saihesten da mezuak erabiltzean, ez fitxategiak.

Zer baieztatu behar dugu?

  • Performance? git.lock baxu izan daiteke

  • Libgit2ko kakoak

  • Aldi berean hainbat tiraldi?

Mugak

Elkarrizketa bat ezabatzeko, gailuak elkarrizketa utzi behar du eta beste bat sortu.

Hala ere, mezu iraunkorrak (adibidez mezuak minutu batzuetan irakur daitezkeenak) mezu berezi baten bidez bidal daitezke DRT bidez (adibidez, idazte edo irakurketa jakinarazpenak).

Egitura

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

Fitxategiak transferitzeko

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.

Protokoloa

Bidaliak elkarrizketan konpromiso berria gehitzen du hurrengo formatuan:

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

eta lotura bat sortzen du ${data_path}/conversation_data/${conversation_id}/${file_id} non file_id=${commitid}_${value["tide"]}.${extension}

Ondoren, hartzaileak fitxategiak deskargatu ditzake fitxategia jasotzen duten gailuekin harremanetan jarriz, kanala irekiz name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId eta fitxategiak zain dituen informazioa gordez ${data_path}/conversation_data/${conversation_id}/waiting

Sarrera jasotzen duen gailuak kanala onartuko du fitxategia bidal daitekeen egiaztatuz (sha3sum zuzena bada eta fitxategia existitzen bada).

Transferentzia amaitzen denean edo kanala itxi denean, sha3sum egiaztatzen da fitxategia zuzena den egiaztatzeko (edo ezabatzen da).

Porrot egitean, elkarrizketaren gailu bat berriro martxan jartzen denean, itxaron ditugun fitxategi guztiak modu berean eskatuko ditugu.

Call in Swarm

Ideia bat

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

«accountUri/deviceId/conversationId/confId» non accountUri/deviceId-ak hartzen duen izena.

Etxebizitza bi moduz zehazten da:

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

  • Edo lehen deilaria.

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)

Parte bakoitzak dei bat hasi dela jakingo du eta dei eginez bat egin dezake.

Erasoak?

  • Avoid Git bombs

Oharrak

Konpromiso baten denbora-marka fidagarria da editatzekoa delako. Erabiltzailearen denbora-marka soilik fidagarria da.

TLS

Git operazioak, kontrol mezuak, fitxategiak eta beste gauza batzuk P2P TLS v1.3 lotura bat erabiliko dute, PFS bermatzen duten zifrekin.

DHT (UDP)

Mugikorretarako mezuak bidaltzeko (push-oharrazioak pizteko) eta TCP konexioak abiatzeko erabiltzen da.

Sarearen jarduera

Norbait gonbidatzeko prozesua

Alice-k Bob gonbidatu nahi du:

  1. Alice-k Bob gehitzen du elkarrizketara

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

  3. Bi aukera bidaltzeko mezua a. Ez bada konektatuta, DHT b. Bestela, Alice bidaltzen SIP kanalean

  4. Bob a. Gonbidapena jasotzen du, seinalea emititzen da bezeroarentzat b. Ez dago konektatuta, beraz, ez du inoiz eskaria jasoko Alice-k jakin behar duelako Bob-ek Alice-ri kasurik egin ote zion edo blokeatu ote zion.

Mezu bat bidaltzeko prozesua

Alice-k mezu bat bidali nahi dio Bob-i:

  1. Alice-k mezu bat gehitzen du erreposan, nortasun agiria emanez.

  2. Alice-k mezu bat jasotzen du (bere buruarengandik) arrakasta izanez gero

  3. Bi aukera, alice eta bob konektatuta daude edo ez. Bi kasuetan mezu bat sortzen da: { «aplikazioa/im-git-message-id» : «{«id»:»\(convId", " konpromisoa":"\)commitId», «deviceId»: «$alice_device_hash»}»}.

  4. Bobek lau aukera ditu: a. Bob ez dago Alice-rekin konektatuta, beraz, Alice-rekin konfiantza badu, konektatu berri bat eskatu eta b. b. konektatuta badago, Alice-ren bila joan eta mezu berriak jakinarazi c. Bobek ez daki elkarrizketa hori. DHT-tik eskatu gonbidapen bat lortzeko lehenik elkarrizketa hori onartzeko ({«eskaera/ Gonbidapena», elkarrizketaId}) d. Bob deskonektatuta dago (ez dago sareik, edo itxi besterik ez da).

Erabateko eragiketa

[Diagrama: elkarrizketa klaseak]

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

Deiak

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

!! Garai Zaharreko Proiektua!!

Oharra

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

Krpto-garapenak.

Talde-txata serio baterako, kripto serio bat ere behar dugu. Gaur egungo diseinuarekin, ziurtagiri bat lapurtu bada elkarrizketaren aurreko DHT balioak bezala, elkarrizketa deszifratzeko aukera izango da. Beharbada ** Double ratchet** bezalako zerbaitera joan behar dugu.

Oharra

A lib might exist to implement group conversations.

ECCren laguntza behar du OpenDHT-n

Erabilera

Rol gehiago?

Talde-txateak bi erabilera nagusi dituzte:

  1. Enpresa batean, kate pribatuekin, eta rol batzuk (admin/espectador/bot/etc) edo hezkuntzarako (hainbat soilik dauden lekuetan).

  2. Elkarrizketa horizontalak lagunen arteko elkarrizketa bezala.

Jami will be for which one?

Erabateko ideia

Zeregin baterako bandera batekin erabiltzaileak sinatzen dituen talde batentzako ziurtagiria.

Elkarrizketa baterako.

  • Gonbidapen zuzen baten bidez bakarrik.

  • Lotura bat edo QR kodea edo dena delakoa.

  • Gela baten izenean?

Behar duguna

  • Konfidentzialtasuna: Talde-txatetik kanpoko kideek ez lukete mezuak irakurriko taldean.

  • Sekretu aurreratua: taldearen giltza edozein arriskuan jartzen bada, aurreko mezuak konfidentzialak izan behar dute (ahal den neurrian)

  • Mezuen ordenaketa: beharrezkoa da mezuak ordena egokian edukitzea

  • Sinkronizazioa: Mezu guztiak ahalik eta lasterren jasotzea ere beharrezkoa da.

  • Persistentzia: DHTko mezu batek 10 minutu baino ez ditu irauten. DHT mota horretarako kalkulatutako denbora onena delako. Datuak irauteko, nodoak DHTko balioa 10 minutuan behin jarri behar du.

Beste banatutako bideak

  • Ikerketa batzuk behar ditut.

  • Ikerketa batzuk behar ditut.

  • Ikerketa batzuk behar ditut.

Gaur egungo lanari jarraituz,

Talde-txata gailu anitzeko dagoeneko dugun lan beraren arabera izan daiteke (baina hemen, talde-ziurtagiri batekin).

  1. Honekin datu basea bezerotik daimonera mugitu behar da.

  2. Inor ez bada konektatuta, sinkronizazioa ezin da egin, eta pertsona ez da inoiz ikusiko elkarrizketa

Beste DHT bat.

DHT bat bezala super erabiltzaile batekin.

Fitxategiak transferitzeko

Gaur egun, fitxategi transferentzia algoritmoa TURN konexioan oinarritzen da (ikus Fitxategiak transferitzeko). Talde handi baten kasuan, hau txarra izango da. Lehenengo eta behin, fitxategi transferentziarako p2p inplement bat behar dugu.

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

Baliabideak