Škrob

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. Ne morejo zaupati nobenemu strežniku.

  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 sinhronizirajo med udeleženci.

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

Ustvarite žar

Bob želi ustvariti novo množico.

  1. Bob creates a local Git repository.

  2. Nato ustvari prvo podpisano zavezo z naslednjim:

    • Njegov javni ključ v /admins

    • Certifikat naprave v ̀ /aparati `

    • Njegov CRL v ̀ /crls`

  3. Hash prvega sporočila postane ID pogovorov.

  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.

Dodatek nekoga

Bob adds Alice

  1. Bob adds Alice to the repo:

    • Dodaja povabljeno URI v /invited

    • Dodatek CRL v /crls

  2. Bob sends a request on the DHT.

Privolitev

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 sporočila

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

Opomba

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.

Ob prejemanju sporočila

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.

Potrditev obveznosti

Da bi se izognili uporabnikom, ki bodo pritisnili nekaj neželenih obveznosti (z konflikti, lažnimi sporočili itd.), mora biti vsak od njih (od najstarejših do najnovejših) potrdljen pred združenjem daljinske podružnice:

Opomba

  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.

Prepoved naprave

Pomembno

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.

Podobne sisteme (z razdeljenimi skupinskimi sistemi) niso toliko, vendar so to nekaj primerov:

  • [mpOTR ne določa, kako prepovedati nekoga]

  • Signal, brez osrednjega strežnika za skupinski klepet (EDIT: nedavno so spremenili to točko), ne daje možnosti, da nekoga prepovedate iz skupine.

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

Izbrišite napravo iz pogovora

To je edini del, ki mora biti soglasje, da se spregovori ne bi razdelili, kot če se dva člana izstrelijo med seboj iz spora, kaj bo videl tretje?

To je potrebno za odkrivanje preklicanih naprav ali preprosto preprečevanje neprimernega prisotnosti ljudi v javni sobi.

Alice odstrani Boba.

Pomembno

Alice MUST be an admin to vote.

  • Za to ustvari datoteko v /votes/ban/members/uri_bob/uri_alice (člani se lahko zamenjajo z napravami za napravo ali povabljajo za povabilo ali upravnike za upravnike) in se zavezuje, da bo

  • Potem preverja, ali je glasovanje rešeno. To pomeni, da se >50% upravnikov strinja, da bo prepovedal Bob (če je sama, je gotovo več kot 50%).

  • Če je glasovanje rešeno, lahko datoteke v /votes/ban odstranite, vse datoteke za Bob v /members, /admins, /invited, /CRLs, /devices se lahko odstranite (ali samo v /devices če je naprava, ki je prepovedana) in Bobov certifikat se lahko v /banned/members/bob_uri.crt (ali /banned/devices/uri.crt če je naprava prepovedana) in se prenesejo v repo

  • Nato Alice obvesti druge uporabnike (izven Boba)

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

  • Potem preverja, ali je glasovanje rešeno. To pomeni, da se >50% upravnikov strinja, da bo prepovedal Bob (če je sama, je gotovo več kot 50%).

  • Če je glasovanje rešeno, lahko datoteke v /votes/unban odstranite, vse datoteke za Bob v /members, /admins, /invited, /CRLs, lahko ponovno dodate (ali samo v /aparatih, če je naprava, ki je ne prepovedana) in se prenesejo v repo

Izbriši pogovor

  1. Prihranite v convInfos odstranjeno=čas::daj() (kot odstraniteSprotnik shrani v stikih), da se pogovor odstrani in sinhronizira z napravami drugih uporabnikov

  2. Če je za ta pogovor prejel nov poziv, ga ignoriramo.

  3. Če je Jami v začetku in repo še vedno prisoten, se pogovor ne objavi strankam.

  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. Ko smo prepričani, da je nekdo sinhronizirano, odstranite izbrisan=time::now() in sinhronizirajte z napravami drugih uporabnikov

  6. Vse naprave, ki jih ima uporabnik, lahko zdaj izbrisata repozitorij in povezane datoteke

Kako določiti način

V času se ne more spremeniti načrta ali je to druga pogovor. Torej, ta podatki so shranjeni v prvotni sporočilih commit.

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

Za zdaj „mode“ sprejme vrednosti 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:

Postopek je še vedno enak, račun lahko doda stik preko addContact, nato pošlje TrustRequest prek DHT. Vendar sta potrebna dve spremembi:

  1. TrustRequest vstavi „obmožnost pogovorov“, ki sodelavcu obvesti, kateri pogovor je treba klonirati, ko sprejme zahtevo

  2. TrustRequest se ponovno poskuša, ko se stik vrne na spletu. To ni danes (ker ne želimo ustvariti novega TrustRequest, če je primernik zavrnil prvi). Če račun prejme zahtevo za zaupnost, bo samodejno ignoriran, če je zahtevo z povezanim pogovorom zavrnjena (kot convRequests so sinhronizirani)

Potem, ko kontakt sprejme zahtevo, je potreben čas sinhronizacije, ker mora kontakt zdaj klonirati pogovor.

odstraniteStopContact) bo odstranil stik in povezane 1:1 pogovore (z enakim postopkom kot „Odstranite pogovor“). Edina opomba tukaj je, da če prepovedamo stik, ne čakam na sinhronizacijo, samo odstranimo vse povezane datoteke.

Scenarij, ki so težki

V nekaterih primerih je mogoče ustvariti dva pogovora.

  1. Alice adds Bob.

  2. Bob accepts.

  3. Alice removes Bob.

  4. Alice adds Bob.

ali

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

Pomembno

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() vrne {{„sinkronizacija“: „prava“}} če se sinhronizira.

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

Pogovori zahtevajo specifikacijo

Zahtevi za pogovor so predstavljeni s Map<String, String> z naslednjimi tipki:

  • id: the conversation ID

  • from: URI of the sender

  • Prejet: časovni značek

  • naslov: (neobvezno) ime za pogovor

  • opis: (na izbiro)

  • avatar: (optional) the profile picture

Sinkronizacija profila pogovora

Za identifikacijo pogovora je treba običajno uporabiti metapodatke, kot so naslov (npr. Jami), opis (npr. nekatere povezave, kakšen je projekt itd.) in sliko (logo projekta).

Skladitev v skladišču

Profil pogovora je shranjen v klasični datoteki vCard na korenu (/profile.vcf) kot:

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

Zadnji prikaz

V sinhroniziranem podatku vsako napravo pošlje na druge naprave stanje pogovorov. V tem stanju se pošlje zadnja prikazana. Vendar pa, ker lahko vsaka naprava ima svoj stanj za vsako pogovor in verjetno brez istega zadnja obveznost v nekem trenutku, obstaja več scenarijev, ki jih je treba upoštevati:

Podprt je 5 scenarijev:

  • Če je zadnji prikaz, ki ga je poslala druga naprava, enak trenutnemu, ni nič, kar bi se zgodilo.

  • če za tekoče napravo ni zadnja prikazana, se uporablja sporočilo, ki se prikaže na daljavo.

  • Če zadnji prikazan daljinski signal ni prisoten v repo, pomeni, da bo commit pozneje, zato se rezultat vnaprej

  • Če je daljinski računalnik že vzeli, preverimo, ali je zadnji prikazan lokalni računalnik prej v zgodovini, da ga zamenjamo.

  • Če je sporočilo objavljeno od istega avtorja, moramo posodobiti zadnjo.

Nastavitve

V vsakem pogovoru so priložene preference, ki jih je uporabnik določil. Te preference so sinhronizirane na uporabnikovih napravah. To je lahko barva pogovora, če želi uporabnik zanemariti obvestila, omejitev velikosti prenosa datotek itd. Za zdaj so prepoznavni ključi:

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

  • „ignoreNotifications“ - ignorirati obvestila za nove sporočila v tem pogovoru

  • „simbol“ - za opredelitev privzete emoji.

Te preference so shranjene v paketu MapStringString, shranjene v accountDir/conversation_data/conversationId/preferences in se pošljejo le na naprave istega uporabnika prek SyncMsg.

API za interakcijo z preferencami so:

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

Upravljanje konfliktov z združitvijo

Ker lahko dva upravitelja hkrati spremenijo opis, se lahko na profile.vcf pojavi konflikt združevanja. V tem primeru se bo izbral commit z višjim hashom (npr. ffffff > 000000).

API

Uporabnik ima 2 metode za pridobivanje in nastavitev metadane pogovorov:

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

kjer je info map<str, str> z naslednjimi tipki:

  • način: samo za branje

  • naslov

  • opis

  • avatar: the profile picture

Uporabljeni protokoli

-Git

Zakaj je ta izbira

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

  1. Merklovo drevo je popolna struktura za to in ga je mogoče linearitizirati z združitvijo podružnic.

  2. Naravnost je razdeljena, pogosto se uporablja, veliko je backendov in se lahko priključi.

  3. Lahko preverite obveze prek krogov in masivno uporabljenih kriptovalute

  4. Če je potrebno, lahko shranjuje v zbirki podatkov

  5. Konflikte se preprečujejo z uporabo sporočil, ne datotek.

Kaj moramo potrditi

  • git.lock lahko nizko

  • V libgit2 so kroge

  • Večkrat hkrati?

Omejitve

Za izbris pogovorov mora naprava zapustiti pogovor in ustvariti drugega.

Vendar pa se lahko ne-stalne sporočila (kot so sporočila, ki se lahko berejo le nekaj minut) pošljejo prek posebnega sporočila prek DRT (kot so obvestila o vpisovanju ali branju).

Struktura

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

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

Odposilka v pogovor doda novo obveznost v naslednjem formatu:

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

in ustvarja povezavo v ${data_path}/conversation_data/${conversation_id}/${file_id} kjer file_id=${commitid}_${value["tid"]}.${extension}

Nato lahko prejemnik zdaj prenesete datoteke s kontaktom z napravami, ki gostujejo datoteko z odprtjem kanala z name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId in shranite informacije, da je datoteka čaka v ${data_path}/conversation_data/${conversation_id}/waiting

Naprava, ki prejme povezavo, bo sprejela kanal z preverjanjem, ali je mogoče pošiljati datoteko (če je sha3sum pravilna in če obstaja datoteka).

Ko je prenos končan ali kanal zaprt, se sha3sum preverja, da je datoteka pravilna (ali je izbrisana).

V primeru neuspeha, ko bo naprava pogovora spet na spletu, bomo zahtevali vse file, ki čakajo, na enak 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/obrobna ID/obreška ID/zadeva“, kjer accountUri/obrobna ID opisuje gostitelja.

Gospodar lahko določi na dva načina:

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

  • Ali prvotni kličevalec.

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)

Vsak del bo prejel informacije, da je klic začel in se lahko pridruži, če ga pokliče.

Napadi?

  • Avoid Git bombs

Opombe

Časovni žig commit-a je zanesljiv, ker je urejen.

TLS

Operacije Git, nadzorni sporočila, datoteke in druge stvari bodo uporabljali povezavo P2p TLS v1.3 z samo šiframi, ki jamčijo PFS. Zato se vsaka ključ ponovno pogaja za vsako novo povezavo.

DHT (UDP)

Uporablja se za pošiljanje sporočil za mobilne telefone (za sprožitev sporočil push) in za sprožitev TCP povezav.

Aktivnost omrežja

Proces povabljanja nekoga

Alice želi povabiti Boba:

  1. Alice je dodala Boba v pogovor.

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

  3. Dve možnosti za pošiljanje sporočila a. Če ni povezano, preko DHT b. Drugače Alice pošlje na SIP kanal

  4. Bob je prejel povabilo, signal je izdan za stranko b. Ni povezan, zato ne bo nikoli prejel zahteve, ker Alice ne sme vedeti, če je Bob preprosto ignoriral ali blokiral Alice.

Proces, da pošljete sporočilo nekomu

Alice hoče poslati sporočilo Bobu:

  1. Alice doda sporočilo v repo, dajejo identifikacijo

  2. Alice dobi sporočilo (od sebe) če uspešno

  3. V obeh primerih se ustvari sporočilo: { „aplikacija/im-gitmessage-id“ : „{„id“:“\(convId", "pospeluje":"\)commitId“, „deviceId“: „$alice_device_hash“}“}. a. Če ni povezano, preko DHT b. Drugače Alice pošlje na SIP kanal

  4. Bob je v zvezi z Alice-om povezan z več kot 50 osebami, zato je Bob brez povezave z Alice-om. Če je zaupal Alice, prosite za novo povezavo in pojdite na b. b. Če je povezan, pojdite od Alice in oglasijte nove sporočila.

Izvajanje

[Diagram: šarmski klepetni razredi]

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

Klici

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

Opomba

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

-Kripto izboljšave.

Za resno skupinsko klepetno funkcijo potrebujemo tudi resno kripto. Če je z trenutnim oblikovanjem ukradeno potrdilo kot prejšnje vrednosti DHT v pogovoru, je lahko pogovor razšifriran. Morda moramo iti na nekaj kot Duple ratchet.

Opomba

A lib might exist to implement group conversations.

Potrebuje podporo ECC v OpenDHT

Uporaba

Dodatne vloge?

Skupinski klepet lahko uporabimo v dveh glavnih primerih:

  1. Nekaj takega kot Mattermost v podjetju, z zasebnimi kanali in nekaj vlogi (admin/spektator/bot/etc) ali za izobraževanje (kjer je aktivno le nekaj).

  2. Horizontalni pogovori so kot pogovor med prijatelji.

Jami will be for which one?

Ideja za izvajanje

Certifikat za skupino, ki uporabnika podpiše z zastavo za vlogo.

Pridružite se pogovoru.

  • Samo po neposredni povabi

  • Z povezovanjem/Kodom QR/karkoli

  • -Z imenom sobe?

Kaj potrebujemo

  • Potežnost: člani zunaj skupinskega klepet ne smejo brati sporočil v skupini

  • Zaščita: če je bilo ključa skupine ogrožena, bi morale prejšnje sporočila ostati zaupne ( kolikor je mogoče)

  • Obrejanje sporočil: Potrebno je imeti sporočila v pravilnem vrstnem redu

  • Sinhronizacija: Potrebno je tudi, da se prepričate, da imate vse sporočila čim prej.

  • Vztrajnost: v resnici sporočilo na DHT živi samo 10 minut. Ker je to najboljši čas izračunane za to vrsto DHT. Da bi ohranjali podatke, mora vozlišče ponovno postaviti vrednost na DHT vsakih 10 minut. Drugi način, da se to zgodi, ko je vozlišče offline, je, da vozlišče ponovno postavljajo podatke. Če pa po 10 minutah, 8 vozlišč so še vedno tukaj, bodo naredili 64 zahteve (in je eksponencialno).

Druge razdeljene poti

  • Potrebujem nekaj preiskav.

  • Potrebujem nekaj preiskav.

  • Potrebujem nekaj preiskav.

Na podlagi trenutnega dela, ki ga imamo,

Skupinski klepet lahko temelji na istih delih, ki jih že imamo za več naprav (a tukaj z skupinsko potrdilo).

  1. To mora premakniti bazo podatkov iz klijenta v demona.

  2. Če ni nihče povezan, sinhronizacija ne bo mogoče narediti in oseba nikoli ne bo videla pogovora.

Še ena posebna DHT

Kot DHT z super uporabnikom.

Prenos datotek

Trenutno je algoritem prenosa datotek temeljen na povezavi TURN (glejte Prenos datotek). V primeru velike skupine bo to slabo.

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

Resurse