Päris

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. Mitte ühtegi keskvalitsust, ei saa usaldada ühtegi serverit.

  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.

Peamine idee on saada sünkroniseeritud Merkle puu osalejatega.

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

Scenarioid

Looda hulk

Bob tahab luua uut rohma

  1. Bob creates a local Git repository.

  2. Seejärel loodab ta algselt allkirjastatud kohustuse, milles on järgmine:

    • Tema avalik võtme /admins

    • Tema seadme sertifikaat ̀ / seadmete]]

    • Tema CRL on ̀ /crls`

  3. Esimese kommitsiooni hash muutub konverentsis ** ID **

  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.

Lisada keegi

Bob adds Alice

  1. Bob adds Alice to the repo:

    • Lisatakse kutsutud URI /invited

    • Lisatakse CRL /crls

  2. Bob sends a request on the DHT.

Kutsumise vastuvõtmine

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.

Saada sõnum

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

Märkus

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.

Saadme sõnum

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.

Kohustusliku kohustuse kinnitamine

Et vältida kasutajate poolt soovimatuid komiteeringuid (konfliktidega, vale sõnumitega jne), tuleb iga komiteeringu (vanemast uueni) enne kaugdeosa ühendamist kinnitada:

Märkus

  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.

Keela seadme

Tähtis

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.

Sarnased süsteemid ( jaotatud rühmasüsteemidega) pole nii palju, kuid need on mõned näited:

  • [mpOTR ei defineeri, kuidas kedagi keelata]

  • Signaal, ilma keskne server grupikatsetamiseks (EDIT: nad hiljuti seda punkti muutsid), ei anna võimalust keelata kedagi grupist.

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

Võta seadme konverentsist välja

See on ainus osa, kus peab olema konsensus, et vältida vestluse lõhkumist, nagu kui kaks liikmet löövad üksteist vestlusest välja, mis näeb kolmandat?

See on vajalik, et tuvastada tühistatud seadmed või lihtsalt vältida soovimatute inimeste esinemist avalikus ruumis.

Alice eemaldab Bob.

Tähtis

Alice MUST be an admin to vote.

  • Esiteks, ta hääletab Bob’i keelustamise poolt. Selleks loodab ta faili /vooteid/keeld/liikmed/uri_bob/uri_alice (liikmed võivad asendada seadmetega seadmete jaoks või kutsuda kutsumisi või adminiadminite jaoks) ja teeb kohustusi

  • See tähendab, et >50% admineeridest nõustub Bob’i keelustama (kui ta on üksi, on see kindlasti rohkem kui 50%).

  • Kui hääletus on lahendatud, saab /vooteid/keeldusesse kuuluvaid failiid eemaldada, kõik Bob’i failid /members, /admins, /invited, /CRLs, /devicesis võib eemaldada (või ainult /devicesis, kui see on seadme, mis on keelatud) ja Bob’i sertifikaat võib paigutada /banned/members/bob_uri.crtisse (või /banned/devices/uri.crt kui seadme on keelatud) ja pühendada repo’le

  • Siis, Alice teavitab teisi kasutajaid (välja arvatud 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

  • See tähendab, et >50% admineeridest nõustub Bob’i keelustama (kui ta on üksi, on see kindlasti rohkem kui 50%).

  • Kui hääletus on lahendatud, saab failid /vooteid/unban eemaldada, kõik Bob’i failid /liikmed, /admins, /invited, /CRL’d, võib lisada uuesti (või ainult /seadmete, kui see on seadme, mis on keelatud) ja pühendada repo

Võta kõne ära

  1. Salvestada convInfos eemaldatud= aeg:: nüüd() (nagu eemaldadaKontakt salvestas kontaktides) et vestlus eemaldatakse ja sünkroneeritakse teiste kasutajate seadmetega

  2. Kui selle vestluse jaoks saab uus kohustus, siis seda ignoreeritakse.

  3. Kui Jami algab ja repo on endiselt olemas, siis vestlust klienditele ei teatata.

  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. Kui oleme kindel, et keegi on sünkroneeritud, eemaldage kustutatud=time::now() ja sünkroneerige teiste kasutajate seadmetega

  6. Kõik kasutaja omanikud seadmed saavad nüüd kustutada hoiukonna ja sellega seotud failid

Kuidas määrada režiimi

Muudusid ei saa aja jooksul muuta. Või see on teine vestlus. Nii, et need andmed salvestakse algses kommitteerimis sõnumis.

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

Praegu võtab „mode“ väärtused 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:

Proos on endiselt sama, konto võib lisada kontakt addContact kaudu, siis saata TrustRequest DHT kaudu.

  1. TrustRequest sisaldas „konvertsatsiooniId“, et teavitada kolleegit, millist vestlust kloneerida, kui ta nõustub taotluse vastuvõtmisega

  2. TrustRequest proovib uuesti, kui kontakt on tagasi online. See ei ole täna nii (nagu me ei taha luua uut TrustRequest, kui kaaslane lahkub esimene). Seega, kui konto saab usaldusnõue, ignoreeritakse see automaatselt, kui taotlus seotud vestlusest on tagasi lükatud (nagu convRequests on sünkroniseeritud)

Kui kontakt nõustub nõusolekuga, on vaja sünkroneerida, sest kontakt vajab nüüd vestluse klonimist.

eemaldame kontakt ja sellega seotud 1:1-ga (samal protsessiga kui “ eemalda konverents“). Ainus märk on see, et kui me keelame kontakti, ei oota me sinkroniseerimist, vaid eemaldame kõik seotud failid.

Rasked stsenaariumi

On ka mõningaid juhtumeid, kus võib luua kaks vestlust.

  1. Alice adds Bob.

  2. Bob accepts.

  3. Alice removes Bob.

  4. Alice adds Bob.

või

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

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() annab tagastamise.

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

Suhtlused nõuavad täpsustust

Kõneluste taotlused esitatakse ** Map<String, String>**** järgmiste võtmetega:

  • id: the conversation ID

  • from: URI of the sender

  • Saadmine: ajajälg

  • pealkiri: (valimine) vestluse nimi

  • kirjeldus: (valimine)

  • avatar: (optional) the profile picture

Suhtluse profiili sünkroneerimine

Et olla tuvastatav, vajab vestlus üldiselt metadata, nagu pealkiri (nt Jami), kirjeldus (nt mõned linkid, mis on projekt jne) ja kujutis (projekt logo). Need metadata on vabatahtlikud, kuid need jagatakse kõigi liikmete vahel, seega tuleb need sünkroniseerida ja inkorporeerida taotlusesse.

Varustus ladustuses

Kõneluse profiil salvestatakse klassikalises vCard faelis juurel (/profile.vcf) nagu:

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

Sinkroniseerimine

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

Viimane näitus

Sinkroniseeritud andmetes saadab iga seadme teistele seadmetele konverentside seisund. Selles seisundis saadetakse viimane näidanud.

Toetatakse 5 stsenaariumi:

  • Kui teiste seadmete poolt saatetud viimane näide on sama kui praegune, siis ei ole midagi teha.

  • kui praeguse seadme jaoks ei ole viimast näidet, kasutatakse kaugnäitavat sõnumit.

  • Kui viimati näidanud kaugseadme repo’s ei ole, tähendab see, et commit tuleb hiljem kätte, seega kaaseta tulemust

  • Kui kaugseadme on juba võetud, kontrollimme, et viimane näidanud kohalik on varem ajaloos, et seda asendada

  • Lõpuks, kui sama autori sõnum on kuulutatud, siis tuleb viimast avaldatud sõnumit ajakohastada.

Eelistused

Kõigis vestlustes on kasutaja poolt kehtestatud eelistusi lisatud. Need eelistused sünkroniseeritakse kasutaja seadmetel. See võib olla vestluse värv, kui kasutaja tahab ignoreerida teated, failide üleandmise suuruse piirangu jne.

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

  • „ignoreNotifications“ - ignoreerida uudiste sõnumite teated selles vestluses

  • „symbol“ - määratleda eeltähtise emoji.

Need eelistused salvestatakse MapStringString paketis, mis salvestatakse accountDir/conversation_data/conversationId/preferences ja edastatakse ainult ühe kasutaja seadmetele SyncMsg kaudu.

eelistustega suhtlemiseks kasutatavad API-d 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*/);
};

Sisse liitumise konfliktide juhtimine

Kuna kaks administratorit võivad kirjeldust samal ajal muuta, võib profile.vcf puhul tekkida ühinemiskonflikt. Sel juhul valitakse commit kõrgemal hashiga (nt ffffff > 000000).

AIPd

Kasutajal on 2 meetodit vestluse metadate saamiseks ja seadmiseks:

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

kus infos on map<str, str> järgmise võtmega:

  • Režiim: ainult lugemine

  • pealkiri

  • kirjeldus

  • avatar: the profile picture

Kasutatud protokollid

Git

Miks see valik

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

  1. Me peame sõnumite sünkroneerima ja korraldama. Merkle puu on selleks ideaalne struktuur ja seda saab linneerida, sulades harudeid. Pealegi, kuna seda kasutatakse Git’is massivalt, on selle seadmete vahel lihtne sünkroneerida.

  2. Looduslikult levitatud, laialdaselt kasutatud, palju tagumiste ja ühendatavaid.

  3. Võimalik kontrollida kohustusi läbi hakke ja massiivne kasutatud kripto

  4. Vajaduse korral salvestatakse andmebaasis

  5. Konflikti vältimine toimub mitte failide asemel, vaid sõnumite abil.

Mida me peame kinnitama

  • Toetus? git.lock võib olla madal

  • Libgit2 haagid

  • Mitmed tõmmad samal ajal?

Piirid

Et kustutada vestlust, peab seadme sellest lahkuma ja luua teine.

Kuid mitte-püsivad sõnumid (näiteks sõnumid, mida saab lugeda ainult mõningaid minutit) saab saata DRT-i kaudu erilise sõnumi kaudu (näiteks kirjutamise või lugemise teated).

Strukture

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

Failide üleandmine

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.

Protokolli

Lähetja lisab vestlusesse uue kohustuse järgmises vormis:

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 loob linkis ${data_path}/conversation_data/${conversation_id}/${file_id}, kus file_id=${commitid}_${value["tid"]}.${extension}

Siis saab vastuvõtja nüüd laadi failid alla, võtes ühendust faili vastuvõtvate seadmetega, avades kanali name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId ja salvestades infot, et faili ootab ${data_path}/conversation_data/${conversation_id}/waiting

Sissevõtuv seadme võtab kanali vastu, kontrollima, kas faili saab saata (kui sha3sum on õige ja kui faili on olemas).

Kui üleandmine on lõpetatud või kanaal suletud, sha3sum kinnitatakse, et faili on õige (või see on kustutatud).

Kui see ei toimi, kui vestlusseadme on taas sisse lülitatud, küsime me kõiki oodatavaid failiid samamoodi.

Call in Swarm

Idea

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

„kontoUri/seadmeId/konversiooniId/konfidend“ kus kontoUri/seadmeId kirjeldab võõrustajat.

Võõrustaja saab määrata kahe viisil:

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

  • Või algne helistaja.

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)

Iga osa saab infot, et kõne on algatud ja saab sellega ühendust võtta.

Rünnakud?

  • Avoid Git bombs

Märkused

Kommitti ajajälga on usaldusväärne, sest seda saab muuta.

TLS

Git-operatsioonid, juhtimis sõnumid, failid ja muud kasutavad p2p TLS v1.3 linkit ainult küüriga, mis tagab PFS.

DHT (UDP)

Kasutatakse mobiiltelefonide sõnumite saatmiseks (push-teate aktiveerimiseks) ja TCP-ühenduste algatamiseks.

Võrgutegevus

Ütleme, et kutsuda keegi

Alice tahab Bobit kutsuda:

  1. Alice lisab Bob’i vestlusele

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

  3. Kui see pole ühendatud, siis DHT b. Muidu Alice saadab SIP-kanaal

  4. Bob a. Kui kutsu saab, väljastatakse kliendile signaal b. Ei ole ühendatud, seega ei saa ta kunagi taotluse saada, sest Alice ei tohi teada, kas Bob lihtsalt ignoreeris või blokeeris Alice.

Proos, mille abil saadetakse kellelegi sõnum

Alice tahab Bobile sõnumit saata:

  1. Alice lisab repole sõnumi, andes ID

  2. Alice saab sõnumit, kui see on edukas

  3. Mõlemal juhul koostatakse sõnum: { „application/im-gitmessage-id“ : „{„id“:“\(convId", "commit":"\)commitId“, „deviceId“: „$alice_device_hash“}“}. a. Kui ei ole ühendatud, DHT b. Muidu saadab Alice SIP-kanaalis

  4. Bobil on neli võimalust: a. Bob pole Alice’iga ühendatud, nii et kui ta usub Alice’i, küsi uut ühendust ja mine b. b. Kui on ühendatud, too Alice’ilt ja teata uus sõnum c. Bob ei tea seda vestlust. Küsi DHT’ist, et saada kutsu, et võta algselt vastu seda vestlust ({„rakendus/ kutsu“, vestlusId}) d. Bob on ühendust lahti (ei ole võrgu või lihtsalt suletud). Ta ei saa uut sõnumit, kuid üritab sinkroniseerida, kui järgmine ühendus toimub

Täiteviis

! [Diagramm: rohi kleitide klass](images/rohi kleitide klasside diagramm.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"
}

Helistused

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

!! Vana raamistik!!

Märkus

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

Kriptode parandused.

Kui on olemas praegune disain, kui sertifikaat on varastatud kui konverentsil on eelnevad DHT väärtused, võib konverents lahti krüpteerida.

Märkus

A lib might exist to implement group conversations.

Vajad ECC-töö toetust OpenDHT-s

Kasutamine

Lisada rollid?

Grupiga vestelda kasutatakse kahte peamist asjaolust:

  1. Mis tahes, nagu Mattermost ettevõttes, era kanalitega, ja mõned rollid (admin/spectator/bot/ jne) või hariduse jaoks (kui ainult mõned on aktiivsed).

  2. Horisontaalsed vestlused on nagu sõbrad.

Jami will be for which one?

Rakendamise idee

Sertifikaat rühma jaoks, mis allkirjastab kasutaja rooli lippuga.

Liitu vestlusega

  • Ainult otsese kutse alusel

  • Liinil/QR-koodil/mis tahes

  • Ruumi nime kaudu? (räsi DHT võrgus)

Mida me vajame

  • Konfidentsiaalsus: liikmed väljaspool rühma kleit ei tohiks olla võimelised lugema sõnumit rühmas

  • Edasi salajasus: kui ükski avalik võtm on rikkunud, peaksid eelnevad sõnumid jääma konfidentsiaalseks (võimalikuma määral)

  • Sõnumite tellimine: sõnumite nõuetekohaseks järjekorras olema on vaja

  • Sinkroniseerimine: Samuti on vaja tagada, et kõik sõnumid saadakse võimalikult kiiresti.

  • Kinnitus: Tegelikult elab DHT-i sõnum vaid 10 minutit. Kuna see on selle tüüpi DHT-i jaoks parim arvutatud aeg. Selleks et säilitada andmeid, peab sõlm iga 10 minuti tagant DHT-i väärtust panema. Teine viis, kuidas teha, kui sõlm on offline, on lasta sõlmidele uuesti andmeid panna. Aga kui 10 minuti pärast on 8 sõlm veel siin, siis teevad nad 64 taotlust (ja see on eksponentsiaalne).

Muud jaotatud viisid

  • IPFS: Vajan uurimist

  • Vajan uurimist.

  • Vajan uurimist.

Tänapäeva töö põhjal

Grupi chati saab kasutada samadel töödel, mida meil on juba mitme seadmega (kuid siin on gruppsertifikaat).

  1. See peab andmebaasi kliendilt deemoni juurde viima.

  2. Kui keegi pole ühendatud, ei saa sinkroniseerimist teha ja inimene ei näe kunagi vestlust

Teine pühendatud DHT

Nagu DHT superkasutajaga.

Failide üleandmine

Praegu põhineb failide ülekandmise algoritm TURN-ühenduse (vt Failide üleandmine). Suur rühma puhul on see halb.

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

Toidud