A szar

A swarm (group chat) is a set of participants capable of resilient, decentralized communication. For example, if two participants lose connectivity with the rest of the group (e.g., during an Internet outage) but can still reach each other over a LAN or subnetwork, they can exchange messages locally and then synchronize with the rest of the group once connectivity is restored.

A swarm is defined by the following properties:

Ability to split and merge based on network connectivity.
History synchronization. Every participant must be able to send a message to the entire group.
Nincs központi hatóság, nem lehet megbízni semmilyen szerverben.
Non-repudiation. Devices must be able to verify past messages» validity and to replay the entire history.
Perfect Forward Secrecy (PFS) is provided on the transport channels. Storage is handled by each device.

A fő ötlet, hogy szinkronizáljuk a Merkle fáját a résztvevőknek.

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

Szénáriumok

Új csoport létrehozása

Bob új csoportot szeretne létrehozni

Bob creates a local Git repository.
Ezután az első aláírt kötelezettségvállalást készíti, amely a következőkkel rendelkezik:
- A közszöveg kulcsa a /admins
- A készülék tanúsítványát ̀ /eszközök
- A CRL-je ̀ /crls`
Az első elkötelezettség hashje a beszélgetés azonosítója.
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.

Valakit hozzáadnak.

Bob adds Alice

Bob adds Alice to the repo:
- A meghívott URI-t /invited-ben adja hozzá
- A CRL-t a /crls-be adja
Bob sends a request on the DHT.

Meghívást kapunk

Alice gets the invite to join the previously created swarm

Alice accepts the invite (if she declines, nothing happens; she will remain in the „invited” list, and will never receive any messages)
A peer-to-peer connection is established between Alice and Bob.
Alice pulls the Git repository from Bob. WARNING this means that messages require a connection, not from the DHT as it is today.
Alice validates the commits from Bob.
To validate that Alice is a member, she removes the invite from /invited directory, then adds her certificate to the /members directory
Once all commits are validated and syncronized to her device, Alice discovers other members of the group. with these peers, she will then construct the DRT with Bob as a bootstrap.

Üzenetet küldek

Alice sends a message to Bob

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

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

Alice ensure her device credentials are present. If Alice’s device certificate or its associated CRL isn’t already stored in the repository, she adds them so that other participants can verify the commit.
Alice commits to the repository (Because Jami relies primarily on commit-message metadata rather than file contents, merge conflicts are rare; the only potential conflicts would involve CRLs or certificates, which are versioned in a dedicated location).
Alice announces the commit via the DRT with a service message and pings the DHT for mobile devices (they must receive a push notification).

Megjegyzés

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.

Egy üzenet

Bob receives a message from Alice

Bob performs a Git pull on Alice’s repository.
All incoming commits MUST be verified by a hook.
If all commits are valid, commits are stored and displayed.Bob then announces the message via the DRT for other devices.
If any commit is invalid, pull is aborted. Alice must restore her repository to a correct state before retrying.

A kötelezettségvállalás érvényesítése

Annak érdekében, hogy a felhasználók ne nyomjanak el néhány nem kívánt elkötelezettséget (konfliktusokkal, hamis üzenetekkel stb.), így kell minden elkötelezettséget (az egyik legidősebbtől a legújabbig) igazolni, mielőtt egyesít egy távoli ág:

Megjegyzés

If the validation fails, the fetch is ignored and we do not merge the branch (and remove the data), and the user should be notified.
If a fetch is too big, it’s not merged.

For each incoming commit, ensure that the sending device is currently authorized and that the issuer’s certificate exists under /members or /admins, and the device’s certificate under /devices.
Then handle one of three cases, based on the commit’s parent count:
- Merge Commit (2 parents). No further validation is required, merges are always accepted.
- Initial Commit (0 parents). Validate that this is the very first repository snapshot:
  - Admin certificate is added.
  - Device certificate is added.
  - CRLs (Certificate Revocation Lists) are added.
  - No other files are present.
- Ordinary Commit (1 parent). The commit message must be JSON with a top‑level type field. Handle each type as follows:
  - If text (or any non–file‑modifying MIME type)
    - Signature is valid against the author’s certificate in the repo.
    - No unexpected files are added or removed.
  - If vote
    - voteType is one of the supported values (e.g. „ban”, „unban”).
    - The vote matches the signing user.
    - The signer is an admin, their device is present, and not themselves banned.
    - No unexpected files are added or removed.
  - If member
    - If adds
      - Properly signed by the inviter.
      - New member’s URI appears under /invited.
      - No unexpected files are added or removed.
      - If ONE_TO_ONE, ensure exactly one admin and one member.
      - If ADMIN_INVITES_ONLY, the inviter must be an admin.
    - If joins
      - Properly signed by the joining device.
      - Device certificate added under /devices.
      - Corresponding invite removed from /invited and certificate added to /members.
      - No unexpected files are added or removed.
    - If banned
      - Vote is valid per the vote rules above.
      - Ban is issued by an admin.
      - Target’s certificate moved to /banned.
      - Only files related to the ban vote are removed.
      - No unexpected files are added or removed.
  - Fallback. If the commit’s type or structure is unrecognized, reject it and notify the peer (or user) that they may be running an outdated version or attempting unauthorized changes.

Tiltogasd a készüléket

Fontos

Jami source code tends to use the terms (un)ban, while the user interface uses the terms (un)block.

Alice, Bob, Carla, Denys are in a swarm. Alice issues a ban against Denys.

In a fully peer‑to‑peer system with no central authority, this simple action exposes three core challenges:

Untrusted Timestamps: Commit timestamps cannot be relied upon for ordering ban events, as any device can forge or replay commits with arbitrary dates.
Conflicting bans: In cases where multiple admin devices exist, network partitions can result in conflicting ban decisions. For instance, if Alice can communicate with Bob but not with Denys and Carla, while Carla can communicate with Denys, conflicting bans may occur. If Denys bans Alice while Alice bans Denys, the group’s state becomes unclear when all members eventually reconnect and merge their conversation histories.
Compromised or expired devices: Devices can be compromised, stolen, or have their certificates expire. The system must allow banning such devices and ensure they cannot manipulate their certificate or commit timestamps to send unauthorized messages or falsify their expiration status.

A hasonló rendszerek (a megosztott csoportrendszerekkel) nem olyan sok, de ezek néhány példa:

[mpOTR nem határozza meg, hogyan lehet valaki tiltást]
A Signal, a csoportcsatlakozás központi szerverének nélkül (EDIT: nemrégiben megváltoztatták ezt a pontot), nem adja meg a lehetőséget arra, hogy valaki tiltja meg egy csoportot.

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

Vedd el a beszélgetést

Ez az egyetlen rész, ahol egyetértés kell legyen, hogy elkerüljük a beszélgetés szétválását, mint például, ha két tag rúgja egymást a beszélgetésből, mi lesz a harmadik?

Ez szükséges a visszavonott eszközök felismeréséhez, vagy egyszerűen elkerülni a nem kívánt embereket a nyilvános szobában.

Alice removes Bob

Fontos

Alice MUST be an admin to vote.

Először is, szavazik Bob tilalomáért. Ezt meg kell tennie, hogy a fájlt /votes/ban/memberek/uri_bob/uri_alice (a tagokat helyettesíthetik a készülékekre, vagy meghívásra vagy adminre hívásra) és elkötelezi magát
Ez azt jelenti, hogy a kormányzók 50%-a beleegyezik Bob tiltásában (ha egyedül van, akkor biztosan több mint 50%).
Ha a szavazás megoldódik, a /votes/ban fájlokat eltávolíthatjuk, a Bob-nak a /memberek, /admins, /invited, /CRL-ek, /eszközökben lévő fájlokat eltávolíthatjuk (vagy csak a /eszközökben, ha tiltott eszköz) és a Bob tanúsítványt a /banned/members/bob_uri.crt (vagy /banned/devices/uri.crt, ha tiltott eszköz) és a repo-hoz küldhetjük.
Alice tájékoztatja a többi felhasználót (Bob kivételével)

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
Ez azt jelenti, hogy a kormányzók 50%-a beleegyezik Bob tiltásában (ha egyedül van, akkor biztosan több mint 50%).
Ha a szavazás megoldódik, a /votes/unban fájlokat eltávolíthatjuk, a Bob-nak a /memberek, /admins, /invited, /CRL-ekben lévő összes fájlt újból hozzáadhatjuk (vagy csak a /device-ekben, ha tiltott eszköz) és a repo-hoz adhatjuk át.

Vedd el a beszélgetést

A konverzió eltávolítása és más felhasználó eszközökkel szinkronizálása (mint a távolításA kapcsolat az elérhetőségek között)
Ha egy új megbízást kapunk a beszélgetésért, akkor figyelmen kívül hagyjuk.
Ha Jami-nek még mindig van a repo, a beszélgetést nem jelentjük be az ügyfeleknek.
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.
Ha biztosak vagyunk benne, hogy valaki szinkronizált, töröljük a törölt=idő:: most() és szinkronizáljuk más felhasználó eszközökkel
A felhasználó tulajdonában lévő eszközök mostantól törölhetik a tárolót és a kapcsolódó fájlokat

Hogyan határozzunk meg a módot

A módokat nem lehet idővel megváltoztatni. Vagy ez egy másik beszélgetés. Tehát, ez az adat az eredeti elkötelezettség üzenetében tárolódik. A elkötelezettség üzenete lesz a következő:

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

A mód jelenleg 0 (ONE_TO_ONE), 1 (ADMIN_INVITES_ONLY), 2 (INVITES_ONLY), 3 (PUBLIC) értéket fogad el.

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:

A folyamat még mindig ugyanaz, egy fiók addContact-en keresztül hozzáadhat egy kapcsolatot, majd a DHT-en keresztül küldhet egy TrustRequest-t. De két változás szükséges:

A TrustRequest egy „konversációId”-t tartalmaz, amely tájékoztatja a társulatot arról, hogy melyik beszélgetést klónozzon a kérés elfogadása során
A TrustRequest-t újra próbálják meg, amikor a kapcsolat visszatér online. Ez nem így van ma (mert nem akarunk új TrustRequest-t generálni, ha a társa eldobja az elsőt). Tehát, ha egy fiók megbízás iránti kérelmet kap, automatikusan figyelmen kívül hagyják, ha a kapcsolódó beszélgetéssel kapcsolatos kérelmet elutasítják (mint a convRequests szinkronizálódnak)

Aztán, amikor egy kontakt elfogadja a kérést, szükség van egy szinkronizációs időszakra, mert a kontaktnak most kell klóni a beszélgetést.

RemoveContact() eltávolítja a kapcsolatot és a kapcsolódó 1:1 beszélgetéseket (olyan folyamatban, mint a „Törölj el egy beszélgetést”). Az egyetlen megjegyzés, hogy ha tiltjuk a kapcsolatot, nem várunk a szinkronizációt, csak eltávolítjuk az összes kapcsolódó fájlt.

Nehéz forgatókönyvek

Van néhány eset, amikor két beszélgetést lehet létrehozni.

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

vagy

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

Fontos

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() visszaküld a szinkronizáció esetén.
ConfigurationManager::getConversationMembers() will return a map of two URIs (the current account and the peer who sent the request).

A beszélgetések specifikációt kérnek

A beszélgetések kérelmeket a következő kulcsokkal a Map<String, String> jelöljük:

id: the conversation ID
from: URI of the sender
Megkapott: időbélyeg
cím: (nem kötelező) a beszélgetés neve
Leírás: (nem kötelező)
avatar: (optional) the profile picture

Beszélgetés névjegyének összehangolása

A beszélgetés azonosíthatóakhoz általában bizonyos metadatok kellenek, mint például a cím (pl. Jami), a leírás (pl. néhány link, mi a projekt stb.), valamint egy kép (a projekt logója). Ezek a metadatok opcionálisak, de megosztott minden tag számára, ezért szinkronizálásra és beillesztésre van szükség a kérelmekbe.

A tárolóban való tárolás

A beszélgetés profilját klasszikus vCard fájlokban tárolják a gyökérnél (/profile.vcf) például:

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

Összehangolás

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

Utoljára megjelenített

A szinkronizált adatok során minden eszköz más eszközökre küld a beszélgetések állapotát. Ebben az állapotban az utolsó megjelenítettet küldik.

Az alábbi öt forgatókönyvet támogatjuk:

Ha a többi eszköz által küldött utolsó megjelenítés ugyanaz, mint a jelenlegi, akkor nem lehet tenni semmit.
ha a jelenlegi készülék esetében nem jelenik meg az utolsó, a távoli megjelenített üzenetet kell használni.
Ha a legutóbbi távolsági megjelenítés nem jelen van a repo-ban, akkor azt jelenti, hogy a commit később lesz, így a eredmény tárolható
Ha a távirányító már elhelyezett, ellenőrizzük, hogy a legutóbbi megjelenített helyi a korábbiak a történetében, hogy helyettesítsük.
Végül, ha ugyanazon szerzőtől küldött üzenetet hirdetünk, azt jelenti, hogy frissíteni kell az utolsó megjelenített üzenetet.

Beállítások

Minden beszélgetéshez a felhasználó által beállított preferenciák vannak csatolták. Ezek a preferenciák a felhasználó eszközén keresztül szinkronizálódnak. Ez lehet a beszélgetés színje, ha a felhasználó figyelmen kívül hagyni akarja a értesítéseket, a fájlátviteli méretkorlátozást stb.

„color” – a beszélgetés színe (#PPZZKK formátum)
„ignoreNotifications” - figyelmen kívül hagyni az új üzenetek értesítését ebben a beszélgetésben
„szimbólum” - egy alapértelmezett emoji meghatározására.

Ezek a preferenciák a MapStringString csomagban vannak tárolva, a accountDir/conversation_data/conversationId/preferences-ben, és csak a SyncMsg-en keresztül ugyanazon felhasználó eszközére kerülnek továbbításra.

Az API-k a preferenciákkal való kölcsönhatás céljából:

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

Összeolvadás konfliktuskezelés

Mivel két admin egyszerre megváltoztathatja a leírást, a profile.vcf-en összevonási konfliktus fordulhat elő. Ebben az esetben a commit a magasabb hash (pl. ffffff > 000000) mellett kerül kiválasztásra.

A BPI-k

A felhasználó két módszert használ a beszélgetés metadatainak megszerzésére és beállítására:

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

ahol a info a következő kulcsokkal rendelkező map<str, str>:

Általános:
cím
leírás
avatar: the profile picture

Újraimportál egy számlát (link/export)

A tárolóban conversationID-t kell tartalmaznia, hogy új commit-ekről való beszélgetéseket újraimport után lehessen visszaszerezni (mert ebben a pillanatban nincs meghívás).

A beszélgetés ott van, ebben az esetben a rendszerfolyamat képes újra klóni a beszélgetést.
A beszélgetésId hiányzik, így a rendszerfolyamat kér (az üzenet {{"alkalmazás/hívás", beszélgetésId}}) egy új meghívást, amelyet a felhasználónak (újra) kell elfogadnia

Fontos

A conversation can only be retrieved if a contact or another device is there, else it will be lost. There is no magic.

Használt protokollok

Git

Miért ezt a választást

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

A Merkle Fa tökéletes struktúra, és lineárisátható a szálakat egyesítésével.
A természet által elosztott, széles körben használt, sok háttérrel és csatlakoztatható.
A kötvények a krumpli és a nagy mennyiségben használt kriptókkal történő ellenőrzése
Szükség esetén adatbázisban tárolható
A konfliktusokat a commit üzenetek, nem a fájlok segítségével lehet elkerülni.

Amit igazolnunk kell

A teljesítmény? git.lock alacsony lehet
A libgit2 gombjai
Több vonás egyszerre?

A határértékek

A beszélgetés törléséhez a készüléknek kilépnie kell a beszélgetésből és létre kell hoznia egy másik.

A nem állandó üzenetek (például néhány percig olvasható üzenetek) azonban különleges üzenet útján küldhetők a DRT-en keresztül (például a gépelés vagy olvasás értesítések).

Szerkezet

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

Adatátviteli átvitel

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

A küldő a következő formátumban új elkötelezettséget ad hozzá a beszélgetéshez:

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

és egy linket hoz létre a ${data_path}/conversation_data/${conversation_id}/${file_id}, ahol file_id=${commitid}_${value["tide"]}.${extension}

A címzett a fájlokat a fájlot befogadó eszközökkel kapcsolatba lépve egy csatornát kinyitva a name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId és tárolja az információt, hogy a fájl vár a ${data_path}/conversation_data/${conversation_id}/waiting

A csatlakozást kapó eszköz elfogadja a csatornát, ha ellenőrizheti, hogy a fájlt küldhet-e (ha a sha3sum helyes és a fájlt meglehetősen létezik). A kapó megtartja az első megnyitott csatornát, bezárja a többieket és egy fájlt ír (a küldővel azonos útvonalon: ${data_path}/conversation_data/${conversation_id}/${file_id}) minden beérkező adatot.

Amikor a továbbítás befejeződött vagy a csatorna lezárult, a sha3sum ellenőrizhető annak érdekében, hogy a fájl helyes (vagy eltávolítható).

Ha nem sikerül, amikor a beszélgetés készüléke újra online lesz, ugyanazon a módon kérjük meg az összes váró fájlt.

Call in Swarm

Ideája

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

„fiókUri/eszközId/megbeszélgetésId/megbízásId” ahol a fiókUri/eszközId leírja a hostet.

Az állomás kétféleképpen határozható meg:

In the swarm metadatas. Where it’s stored like the title/desc/avatar (profile picture) of the room
Vagy az első hívó.

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)

Tehát minden rész megkapja az információt, hogy a hívás elkezdődött, és csatlakozhat hozzá, ha hívja.

Attacks?

Avoid Git bombs

Megjegyzések

A commit időpontja megbízható, mert szerkeszthető. Csak a felhasználó időpontja megbízható.

TLS

A Git műveletek, az irányító üzenetek, fájlok és más dolgok csak a kódokkal használnak egy p2p TLS v1.3 linket, amelyek garantálják a PFS-t. Így minden kulcsot új kapcsolatra újratárgyalják.

DHT (UDP)

A telefonok üzenetének küldésére (push értesítések kiindításához) és a TCP-kapcsolatok indításához használható.

Hálózati tevékenység

A meghívás folyamat

Alice meg akarja hívni Bobot:

Alice Bobot hozza hozzá a beszélgetéshez
Alice meghívása létrehozza: { „application/invite+json” : { „conversationId”: „$id”, „members”: [{…}] }}
Két lehetőség a küldés a üzenet. Ha nem kapcsolódik, a DHT b. Különben Alice küld a SIP csatornán
A következő lépés a következő lépés: a) Bob a. Megkapja a meghívást, a) a kliens számára egy jelet küld a b) nem kapcsolódik, így soha nem kapja meg a kérelmet, mert Alice nem tudja, hogy Bob csak figyelmen kívül hagyta-e vagy blokkolta-e Alice-t. Az egyetlen módja az, hogy új meghívást új üzenet segítségével regeneráljon (lásd következő forgatókönyvet).

A küldési folyamat

Alice üzenetet szeretne küldeni Bobnak:

Alice egy üzenetet ad a repo-ba, és megadja az azonosítót
Alice kap egy üzenetet (az ő) ha sikerült
A két lehetőség, Alice és Bob kapcsolódnak vagy nem. Mindkét esetben egy üzenet készül: { „application/im-gitmessage-id” : „{„id”:”$convId", "commit":"$commitId”, „deviceId”: „$alice_device_hash”}”}.
Négy lehetőség Bob számára: a. Bob nem kapcsolódik Alicehez, így ha megbízik Alice-ben, kérjen egy új kapcsolatot és menjen b. b. Ha kapcsolódik, hozza el Alice-t és bejelentse az új üzeneteket c. Bob nem ismeri ezt a beszélgetést. Kérjen a DHT-en keresztül, hogy először meghívást kapjon, hogy elfogadhassa a beszélgetést ({„kérelmek/hívás”, beszélgetésId}) d. Bob eltávolított (se hálózat, vagy csak lezárt). Nem kapja meg az új üzenetet, de megpróbálja szinkronizálni, amikor a következő kapcsolat meg fog történni

A végrehajtás

! [Diagram: szájjal beszélgető osztályok]

Támogatott üzenetek

Kezdeti üzenet

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

Egy adattár első véglegesítését jelenti, és a következő módot tartalmazza:

enum class ConversationMode : int { ONE_TO_ONE = 0, ADMIN_INVITES_ONLY, INVITES_ONLY, PUBLIC }

és invited „meghívott”, ha mód = 0.

Szöveges üzenet

{
    "type": "text/plain",
    "body": "content",
    "react-to": "id (optional)"
}

Vagy szerkesztéshez:

{
    "type": "application/edited-message",
    "body": "content",
    "edit": "id of the edited commit"
}

Hívások

A hívás végének megjelenítése (időtartam ezredmásodpercben):

{
    "type": "application/call-history+json",
    "to": "URI",
    "duration": "3000"
}

Vagy csoportos hívás fogadására (amikor az elkezdődik)

{
    "type": "application/call-history+json",
    "uri": "host URI",
    "device": "device of the host",
    "confId": "hosted confId"
}

A hívás végén egy második véglegesítés is hozzáadódik ugyanazzal a JSON-nal + duration (időtartam).

Fájl hozzáadása

{
    "type": "application/data-transfer+json",
    "tid": "unique identifier of the file",
    "displayName": "File name",
    "totalSize": "3000",
    "sha3sum": "a sha3 sum"
}

a totalSize (teljesMéret) bitben van megadva,

Névjegy frissítése

{
    "type": "application/update-profile",
}

Tagesemény

{
    "type": "member",
    "uri": "member URI",
    "action": "add/join/remove/ban"
}

Amikor egy tagot meghívnak, csatlakozik, kilép vagy kirúgják a beszélgetésből

Szavazás eseménye

Rendszergazdák készítették, hogy szavazzanak egy személy eltávolítására vagy eltávolítás megszüntetésére.

{
    "type": "vote",
    "uri": "member URI",
    "action": "ban/unban"
}

**!! ÓRÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁGÁG

Megjegyzés

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

Kriptó javulások.

A komoly csoportcsata funkcióhoz komoly kriptó is szükséges. A jelenlegi tervezéssel, ha egy tanúsítványt lopnak, mint a beszélgetés korábbi DHT értékeit, a beszélgetés dekódolható. Talán olyanra kell mennünk, mint ** Double ratchet**.

Megjegyzés

A lib might exist to implement group conversations.

Az OpenDHT-ben ECC támogatásra van szüksége

Használat

Add Roles?

A csoportos beszélgetések két fő alkalmazási esetet használnak:

Valami olyan, mint egy Mattermost egy vállalatban, magáncsatornákkal, és bizonyos szerepekkel (admin/szpektátor/bot/és stb.) vagy oktatás céljából (ahol csak néhány aktív).
Horizontális beszélgetések, mint egy barátok közötti beszélgetés.

Jami melyiknek lesz?

A végrehajtási ötlet

Egy tanúsítvány egy olyan csoport számára, amely egy szerepre jelöl a jelzőt.

Csatlakozz a beszélgetéshez!

Csak közvetlen meghívással
A link/QR kód/mi legyen
A szobának neve?

Mi kell nekünk

Titoktartás: a csoportcsatán kívül lévő tagoknak nem szabadnak képesek lenniük a csoport üzenetének olvasására
Előzetes titoktartás: ha a csoport egyik kulcsa sérül, a korábbi üzenetek bizalmasak maradnak ( amennyire csak lehetséges)
Üzenetek rendeltetése: A üzenetek megfelelő sorrendben kell lenniük
Összehangolás: A lehető leghamarabb minden üzenet biztosra kell kerülnie.
A DHT-n lévő üzenet valójában csak 10 percig tart. Mivel ez a legjobb időzítés, amit a DHT-nek számolnak. Az adatok fenntartása érdekében a csomópontnak 10 percente újra kell beállítania a DHT-n lévő értéket. A csomópont offline alatt egy másik módja annak, hogy a csomópontok újra beállítsák az adatokat. De ha 10 perc után 8 csomópont még mindig itt van, akkor 64 kérelmet fognak tenni (és ez exponenciális). A spam elkerülésének jelenlegi módja megkérdező. Ez még mindig 64 kérelmet tesz, de a max redundanciát 8 csomópontra korlátozza.

Más elosztott módszerek

IPFS: Need some investigation
Kutatást kell végeznünk.
Maidsafe: Need some investigation

A jelenlegi munkánkat alapján

A csoportcsata ugyanazon a munkával alapszik, amit már több eszköznél is végezünk (de itt a csoportos tanúsítványmal).

A történelem szinkronizáció. Ez a adatbázist a kliensről a démonra kell helyezni.
Ha senki nem kapcsolódik, a szinkronizáció nem történik meg, és az ember soha nem fogja látni a beszélgetést

Egy másik DHT-t

Mint egy DHT egy superhasználóval.

Adatátviteli átvitel

A fájlátviteli algoritmus jelenleg egy TURN kapcsolatra épül (lásd Adatátviteli átvitel). Egy nagy csoport esetében ez rossz lesz. Először egy p2p implementet kell a fájlátviteli célból.

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

Az erőforrások

https://eprint.iacr.org/2017/666.pdf
A hálózatba kötött lineáris rendszerek és az időközönként elmaradó információk robusztus és elosztott szinkronizálása (Sean Phillips és Ricardo G. Sanfelice)