Sääli

Tärkeä

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

Synospis

Tämän asiakirjan tavoitteena on kuvata, miten ryhmächatit (tai ”swarm chat”) toteutetaan Jamiin.

A swarm on ryhmä, joka voi keskustella ilman keskusviranomaista kestävällä tavalla. Jos kahdella henkilöllä ei ole yhteyksiä ryhmän muuhun osaan (eli Internet-katkaisu), mutta he voivat ottaa yhteyttä toisiinsa (esimerkiksi LAN-yhteydessä tai aliverkossa), he voivat lähettää viestejä toisilleen ja sitten synkronoida ryhmän muuhun osaan, kun se on mahdollista.

Joten swarm määritellään:

Kyky jakautua ja sulautua yhteyden jälkeen.
Jokainen voi lähettää viestin koko ryhmälle.
Ei keskusviranomaisia, ei palvelijoita.
Laitteiden on oltava kykeneviä tarkistamaan vanhojen viestejen pätevyyttä ja palaamaan koko historia.
Laitteen hallinnointi on laitteen hallinta.

Pääaine on synkronoida Merkle-puun osallistujien kanssa.

Olemme havainneet neljä ruuhka-chat-muotoa, joita haluamme toteuttaa:

**Joku, joka on, joka on, kun keskustelet ystävällesi
ADMIN_INVITES_ONLY yleensä luokka, jossa opettaja voi kutsua ihmisiä, mutta ei opiskelijoita
Kutsu vain yksityistä ystäviaryhää
Julkainen on avautunut foorumi

Scenarioita

Luotaan joukko

Bob haluaa luoda uuden joukon.

Bob creates a local Git repository.
Sitten hän tekee aluksi allekirjoitetun sitoumuksen seuraavasti:
- Hänen avaimensa on /admins
- Hänen laitteen todistuksensa ̀ / laitteissa `
- Hänen CRL:sä on ̀ /crls`
Ensimmäisen sitoutumisen hashista tulee keskustelun tunnus.
Bob ilmoittaa muille laitteilleen, että hän luo uuden keskustelun.

Lisää joku

Alice lisää Bobin.

Alice lisää Bobin repoon:
- Lisää kutsuttu URI /invited
- Lisää CRL:n /crls
Alice lähettää pyynnön DHT:lle

Kutsun vastaanottaminen

Alice saa kutsun liittyä aiemmin luomaan ruumalle

Hän hyväksyy kutsun (jos hän kieltäytyy, ei tee mitään, se jää vain kutsumaan ja Alice ei koskaan saa viestiä)
Alice ja Bob ovat yhteyksissä.
Alice pull the Git repo of Bob. WARNING this means that messages need a connection, not from the DHT like today.
Alice vahvistaa Bobin sitoumukset
Jotta Alice voi vahvistaa jäsenensä, hän poistaa kutsun /invited-katalogista ja lisää todistuksensa /members-katalogista.
Kun kaikki sitoumukset ovat vahvistettu ja hänen laitteessaan, muut ryhmän jäsenet löydetään Alice. Näiden vertaisten kanssa hän rakentaa DRT (selitetty alla) Bobin kanssa käynnistyskäytävänä.

Lähetä viesti

Alice lähettää viestin.

Viestiä lähettäminen on melko yksinkertaista.

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

and adds her device and CRL to the repository if missing (others must be able to verify the commit). Merge conflicts are avoided because we are mostly based on commit messages, not files (unless CRLS + certificates but they are located). Then she announces the new commit via the DRT with a service message (explained later) and pings the DHT for mobile devices (they must receive a push notification).

Toisten laitteiden pinging, lähettäjä lähettää muille jäsenille SIP viestiä mimetype = ”sovellus/im-gitmessage-id” sisältävä JSON ”laiteId” joka lähettää viestin, ”id” keskustelu liittyy, ja ”velvollistaminen”

Saamme viestin

Bob saa viestin Alicelta.

Bob do a Git pull on Alice
sitoumukset on oltava tarkistettu hakun avulla
Jos kaikki commitit ovat voimassa, commitit tallennetaan ja näytetään.
If all commits are not valid, pull is canceled. Alice must reestablish her state to a correct state.

sitoumuksen vahvistaminen

Jotta käyttäjät eivät tule tekemään toisiaan vastaan epätoivottuja sitoumuksia (sota konflikteja, väärä viestiä jne.), jokainen sitoumus (vanhempista uusimmille) on oltava todennettu ennen kauko-alueen yhdistämistä:

Muista

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.

Tarkista, onko jokaisen sitoumuksen lähettävä laitteen käyttö tällä hetkellä hyväksytty ja onko todistukset läsnä (toimituksen laitteissa ja liikkeeseenlaskijan jäsenissä tai hallinnoijissa).
Komitea on kahden vanhemman kanssa, joten se on sulautuminen.
The commit has 0 parents, it’s the initial commit:
- Tarkista, että admin- todistus on lisätty
- Tarkista, että laitteen sertifikaatti on lisätty
- Lisätyt tarkistuskysymyksiä
- Tarkista, ettei muita tiedostoja lisätä
Comitin on 1 vanhempi, commit-viesti on JSON:n tyypin kanssa:
- Jos teksti (tai muu mime-tyyppinen, joka ei muuta tiedostoja)
  - Tarkista vakuutusasiakirjan allekirjoitus
  - Tarkista, ettei mitään outoa tiedostoa ole lisätty tai poistettu laitteen ulkopuolella
- Jos äänestetään
  - Tarkista, että voteType on tukenut (kiellytys, kiellytys)
  - Tarkista, että äänestys on käyttäjälle, joka allekirjoittaa sitoumuksen.
  - Check that vote is from an admin and device present and not banned
  - Tarkista, ettei mitään outoa tiedostoa ole lisätty tai poistettu
- Jos jäsen
  - Jos lisätään
    - Tarkista, onko sitoumus allekirjoitettu oikein
    - Tarkista, että todistuksen on lisätty / kutsuttu
    - Tarkista, ettei mitään outoa tiedostoa ole lisätty tai poistettu
    - Jos ONE_TO_ONE, tarkista, että meillä on vain yksi admin, yksi jäsen
    - Jos ADMIN_INVITES_ONLY, tarkista, että kutsu on adminilta
  - Jos liitetään
    - Tarkista, onko sitoumus allekirjoitettu oikein
    - Tarkista, että laite on lisätty
    - Tarkista, että kutsu siirretään jäsenille
    - Tarkista, ettei mitään outoa tiedostoa ole lisätty tai poistettu
  - Jos kiellettyä
    - Tarkista äänestys.
    - Tarkista, että käyttäjä on kielletty admin
    - Tarkista, onko jäsen- tai laitteen sertifikaatti siirtynyt kielletyn/
    - Tarkista, että poistetaan vain äänestysasiakirjat
    - Tarkista, ettei mitään outoa tiedostoa ole lisätty tai poistettu
- ilmoittaa käyttäjälle, että hän voi olla vanhan version kanssa tai että vertaisikin yritti lähettää ei-toivottuja sitoumuksia

Kieltäkää laitteet

Alice, Bob, Carla ja Denys ovat joukossa.

Tämä on yksi vaikeimmista tilanteista, joita meillä on.

Luotujen sitoumusten aikavarat
Jos useat hallintokoneet ovat läsnä ja jos Alice voi puhua Bobin kanssa mutta ei Denys ja Carla; Carla voi puhua Denysin kanssa; Denys kieltää Alice, Alice kieltää Denys, mikä on tilanne, kun 4 jäsentä yhdistää keskustelut.
Laitteen voi olla luopunut, varastettu tai todistuksensa voimassaoloa voi olla.

Samaa järjestelmää (joilla on jakautuneet ryhmäjärjestelmät) ei ole niin paljon, mutta tässä on muutamia esimerkkejä:

[mpOTR ei määritä, miten kieltää joku]
Signal, ilman keskitettua serveriä ryhmäkeskustelulle (EDIT: he muuttivat tuota kohtaansa hiljattain), ei anna mahdollisuutta kieltää jotakuta ryhmältä.

Tämä äänestysjärjestelmä tarvitsee ihmisen toimet kieltää joku tai on perustuttava CRL:n tietoihin säilytyslaitoksesta (sillä emme voi luottaa ulkoisiin CRL:ihin)

Poista puhelimesta laitteen

Tämä on ainoa osa, jossa on oltava yhteinen päätös, jotta keskustelu ei jakaudu. Jos kaksi jäsentä potkii toisiaan, mitä kolmas näkee?

Tämä on tarpeen peruutetun laitteen havaitsemiseksi tai yksinkertaisesti välttää haluttomien ihmisten läsnäolon julkisessa huoneessa.

Alice poistaa Bobin.

Tärkeä

Alice MUST be an admin to vote.

Hän äänesti Bobin kieltoa varten ja luo tiedoston /votes/ban/members/uri_bob/uri_alice (jäseniä voidaan korvata laitteilla laitteelle tai kutsua kutsuille tai hallinnoille) ja sitoutuu
Hän tarkistaa, onko äänestys ratkaistu, mikä tarkoittaa, että > 50%:n hallitsijoista suostuu kielteeseen Bobin (jos hän on yksin, se on varmasti yli 50%).
Jos äänestys ratkaistaan, tiedostoja /votes/ban voidaan poistaa, kaikki Bobin tiedostot /members, /admins, /invited, /CRLs, /devices voidaan poistaa (tai vain /devices, jos se on laite, joka on kielletty) ja Bobin todistus voidaan sijoittaa /banned/members/bob_uri.crt (tai /banned/devices/uri.crt, jos laite on kielletty) ja sitoutua repo
Sitten Alice ilmoittaa muille käyttäjille (Bobin ulkopuolella)

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
Hän tarkistaa, onko äänestys ratkaistu, mikä tarkoittaa, että > 50%:n hallitsijoista suostuu kielteeseen Bobin (jos hän on yksin, se on varmasti yli 50%).
Jos äänestys ratkaistaan, tiedostoja /votes/unban voidaan poistaa, kaikki Bobin tiedostot /jäsenissä, /admins, /invited, /CRLs, voidaan lisätä uudelleen (tai vain / laitteissa, jos se on laitetta, joka on kielletty) ja sitoutua repo

Poista keskustelu

Säästä convInfos removed=time::now() (kuten poistatKontakti säästää yhteystoimissa) että keskustelu poistetaan ja synkronoidaan muiden käyttäjien laitteiden kanssa
Jos uusi sitoumus tulee, se ei ole huomioitu.
Jos Jami käynnistää ja repo on yhä läsnä, keskustelu ei ilmoiteta asiakkaille.
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.
Kun olemme varmoja, että joku on synkronoitu, poista erased=time::now() ja synkronoida muiden käyttäjien laitteiden kanssa
Kaikki käyttäjän omistamat laitteet voivat nyt poistaa tallennus ja niihin liittyvät tiedostot

Miten määrittää toimintatapa

Muotintoa ei voi muuttaa ajan kuluessa tai se on toinen keskustelu.

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

Tällä hetkellä ”modus” hyväksyy arvoja 0 (ONE_TO_ONE), 1 (ADMIN_INVITES_ONLY), 2 (INVITES_ONLY), 3 (PUBLIC)

Processes for 1:1 swarms

Tavoitteena on säilyttää vanha API (addContact/removeContact, sendTrustRequest/acceptTrustRequest/discardTrustRequest) tuottamaan ruuhkaa vertaisella ja sen yhteyteen. Tämä tarkoittaa edelleen muutoksia, joita emme voi sivuuttaa:

Prosessi on edelleen sama, tili voi lisätä yhteydenpito addContactin kautta ja lähettää sitten TrustRequest DHT:n kautta.

TrustRequest-ohjelmassa on ”talkIde”, joka kertoo, minkä keskustelun kloonaaminen on tehtävä, kun pyydetty hyväksyy
TrustRequest-pyyntö tehdään uudelleen, kun yhteys tulee takaisin verkkoon. Tämä ei ole tapaus tänään (esimerkiksi emme halua luoda uutta TrustRequest-pyyntöä, jos vertaisemme hylkäävät ensimmäisen). Jos tili saa luottamuspyyntöä, se jätetään automaattisesti, jos pyyntö liittyy asiaan liittyvään keskusteluun hylätään (kun convRequests synkronoidaan)

Kun yhteys hyväksyy pyynnön, synkronointi on tarpeen, koska yhteydenotto tarvitsee nyt kloonaation.

removeContact() poistaa yhteyden ja siihen liittyvät 1:1-puhujat (samalla prosessilla kuin ”Poista keskustelu”).

Kiusallisia skenaarioita

Joskus voidaan luoda kaksi keskustelua, ja tässä on ainakin kaksi tällaista skenaaria:

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

tai

Alice adds Bob and Bob adds Alice at the same time, but both are not connected together.

Tässä tapauksessa syntyy kaksi keskustelua. Emme halua poistaa viestejä käyttäjiltä tai valita yhtä keskustelua täällä. Joten joskus kaksi 1:1-sarjaa saman jäsenen välillä näytetään. Se tuottaa joitakin virheitä siirtymäajassa (kuten emme halua rikkoa API:tä, johtopäätetty keskustelua tulee olemaan yksi kahdesta näytetystä keskustelusta, mutta toistaiseksi se on ”ok-ish”, korjattu, kun asiakkaat käsittelevät täysin keskustelua ID:tä kaikille API:lle (soinnot, tiedostojen siirto jne.).

Tärkeä

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() palauttaa {{”syncing”: ”true”}} synkronoinnin yhteydessä.
ConfigurationManager::getConversationMembers() will return a map of two URIs (the current account and the peer who sent the request).

Keskusteluiden pyyntö

Keskustelukysymykset on ilmaistava Map<String, String>** seuraavasti:

id: the conversation ID
from: URI of the sender
vastaanotettu: aikavarmuus
otsikko: (valinnainen) keskustelun nimi
kuvaus: (valinnainen)
Avatari: (valinnainen)

Keskustelun profiilijärjestely

Jotta keskustelu olisi tunnistettavissa, se tarvitsee yleensä metatietoja, kuten otsikon (esim. Jami), kuvauksen (esim. linkit, mikä on projekti jne.) ja kuvan (hankkeen logo).

Säilytys säilytyslaitossa

Keskustelun profiili tallennetaan klassiseen vCard-tiedostoon juuressa (/profile.vcf) kuten:

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

Synkronointi

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

Viimeinen kuvaus

Synkronoituissa tietoihin jokainen laite lähettää muiden laitteiden keskustelun tilaa. Tässä tilassa lähetetään viimeinen näytetty.

Tuetaan viisi skenaariota:

Jos viimeinen, jonka lähettävät muut laitteet, on sama kuin nykyinen, ei ole mitään tehtävää.
Jos nykyisen laitteen viimeinen näyttö ei ole, käytetään kaukosäyttöön näytettävää viestiä.
Jos viimeinen näytetty kaukosähkö ei ole repo-lehdessä, se tarkoittaa, että commit otetaan myöhemmin, joten se tallentaa tuloksen
Jos etäkautta on jo hakenut, tarkistamme, onko viimeinen näytetty paikallinen aikaisemmin historiassa korvaaakseen sen
Lopuksi, jos sama kirjailija ilmoittaa viestin, se tarkoittaa, että meidän on päivitettävä viimeinen näytetty.

Asetukset

Jokaisessa keskustelussa on liitetty käyttäjän asettamia mieltymykset. Nämä mieltymykset synkronoidaan käyttäjän laitteiden välillä. Tämä voi olla keskustelun väri, jos käyttäjä haluaa jättää huomautukset huomiotta, tiedostojen siirron koon rajoitus jne. Tällä hetkellä tunnetaan avaimet ovat:

”color” - the color of the conversation (#RRGGBB format)
”ignoreNotifications” - jättää huomiotta uudet viestejä koskevia ilmoituksia tässä keskustelussa
”symboli” - määritellä oletusarvoinen emoji.

Nämä ennakkot tallennetaan MapStringString-pakettiin, joka tallennetaan accountDir/conversation_data/conversationId/preferences ja lähetetään vain saman käyttäjän laitteiden välillä SyncMsg:n kautta.

API:n käyttöä, jolla on vuorovaikutus mieltymyksineen, 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*/);
};

Solujen konfliktien hallinta

Koska kaksi administrattoria voi muuttaa kuvausta samanaikaisesti, profile.vcf:ssä voi esiintyä fuusiongelmaa. Tässä tapauksessa valitsee commit, jossa on korkeampi hash (esim. ffffff > 000000).

API:t

Käyttäjä sai 2 menetelmää saadakseen ja asettamaan keskustelun metatatat:

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

jossa infos on map<str, str> seuraavasti:

Luku: Luku-aine
nimikkeen
kuvaus
Avatari

Tilin uudelleenviennittäminen (link/vienti)

Arkiivin on oltava conversationId, jotta uusien commit-ohjelmien keskustelut voidaan saada takaisin uudelleen tuoteen jälkeen (sillä tässä vaiheessa ei ole kutsua).

Keskustelu on olemassa. Tässä tapauksessa demoni pystyy klonoimaan keskustelun uudelleen.
KeskusteluId on kadonnut, joten demoni pyytää (viestin kautta {{"sovelluksen/ kutsu", keskusteluId}}) uutta kutsua, jonka käyttäjä tarvitsee (yhdisteltään) hyväksyä

Tärkeä

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

Käytetty protokolli

Git

Miksi tämä valinta

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

Merkle-puun avulla voidaan synkronoida sivujen yhdistäminen, koska Git käyttää sitä paljon, ja sen avulla laitteiden välillä on helppo synkronoida.
Luonto on sitä, joka jakaa, käyttää, käyttää, käyttää ja käyttää.
Voidaan tarkistaa sitoumukset hakkien ja massiivisesti käytettyjen kryptovaluutan avulla
Se voidaan tallentaa tietokannassa tarvittaessa
Konflikteja vältetään käyttämällä commit-viestejä, ei tiedostoja.

Mitä meidän on vahvistettava

git.lock voi olla alhainen
Liibgit2 -hakka
Monenlaiset vetävät samanaikaisesti?

Rajoitukset

Historiasta ei voi poistaa.

Ei-vaikaiset viesteet (esimerkiksi vain muutaman minuutin lukemattomat viesteet) voidaan kuitenkin lähettää erityisen viestin kautta DRT:n kautta (esimerkiksi kirjoitus- tai lukemiskirjeet).

Rakenne

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

Tiedostojen siirto

Swarm muuttaa tiedostojen siirtoa massiivisesti. Nyt koko historia synkronoidaan, jolloin kaikki keskustelun laitteet voivat helposti saada vanhat tiedostot. Nämä muutokset mahdollistavat siirtyä logiikasta, jossa lähettäjä työnsi tiedoston muihin laitteisiin, yrittämällä yhdistää laitteisiin (tämä oli huono, koska ei todella vastusta yhteyksiä muutoksia / epäonnistumisia ja tarvitsi manuaalista uudelleenkoetta) logiikkaan, jossa lähettäjä sallii muiden laitteiden latautua. Lisäksi, mikä tahansa laite on tiedosto voi olla toisten laitteiden isännö, mikä mahdollistaa tiedostojen palauttamisen, vaikka lähettäjä ei ole siellä.

pöytäkirja

Lähettäjä lisää keskustelussa uuden sitoutumisen seuraavalla muodolla:

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 luo linkin ${data_path}/conversation_data/${conversation_id}/${file_id} jossa file_id=${commitid}_${value["tiid"]}.${extension}

Sitten vastaanottaja voi nyt ladata tiedostot ottamalla yhteyttä tiedoston vastaanottaviin laitteisiin avaamalla kanava name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId ja tallentaa tiedot tiedostosta odottavasta ${data_path}/conversation_data/${conversation_id}/waiting

Sähköyhteyden vastaanottava laite hyväksyy kanavan tarkistamalla, voidaanko tiedosto lähettää (jos sha3sum on oikea ja jos tiedosto on olemassa). vastaanottaja pitää ensimmäisen avatun kanavan, sulkee muut ja kirjoittaa tiedostolle (samalla polulla kuin lähettäjä: ${data_path}/conversation_data/${conversation_id}/${file_id}) kaikki saapuvat tiedot.

Kun siirto on valmis tai kanava suljettu, sha3sum tarkistetaan, että tiedosto on oikea (tai se poistetaan). Jos se on voimassa, tiedosto poistetaan odottamisesta.

Jos puhelu epäonnistuu, kun puhelu-laite on taas käynnissä, pyydämme kaikki odottamislaitteet samalla tavalla.

Soita joukko.

Ajatus

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

”tunnusUri/laitteenId/käsittelyId/selvä” jossa accountUri/laitteenId kuvailee isäntä.

Isäntä voidaan määrittää kahdella tavalla:

Metatat ovat huoneen otsikon/avatarin kaltaisia.
Tai ensimmäinen soittaja.

Kun puhelu käynnistetään, isännöijä lisää uuden sitoumuksen joukkoon, johon liittyy URI (accountUri/deviceId/conversationId/confId). Tämä on voimassa puhelun loppuun asti (ohjattu sitoumuksella, jonka ajanjakso näyttää)

Jokainen osa saa tiedon, että puhelu on käynnistynyt ja voi liittyä siihen soittamalla.

Hyökkäykset?

Avoid Git bombs

Huomattaukset

Kun commit-tiedosto on laadittu, se on muokkavissa.

TLS

Git-operaatioissa, ohjausviesteissä, tiedostoissa ja muissa asioissa käytetään p2p TLS v1.3 -linkkiä, joissa on vain kytkät, jotka takaavat PFS: n.

DHT (UDP)

Käytetään lähettämään viestejä mobiileille (työttömyysilmoituksia käynnistämiseen) ja TCP-yhteyksiä käynnistämiseen.

Verkostoteollisuus

Process to invite someone

Alice haluaa kutsua Bobin.

Alice lisää Bobia keskustelulle
Alice generates an invite: { ”application/invite+json” : { ”conversationId”: ”$id”, ”members”: [{…}] }}
Jos ei ole yhteydessä DHT b:n kautta, Alice lähettää SIP-kanavalla
Bob a. Saatii kutsun, signaali lähetetään asiakkaan b. Ei ole yhteydessä, joten ei koskaan saa pyytää, koska Alice ei saa tietää, jos Bob vain huomioinut tai estänyt Alice.

Lähetysprosessi

Alice haluaa lähettää viestin Bobille:

Alice lisäsi viestin repoon, antamalla tunnisteen
Alice saa viestin, jos se onnistuu.
A. Jos se ei ole yhteydessä DHT b:n kautta, Alice lähettää SIP-kanavalla
Bobilla on neljä mahdollisuutta: a. Bob ei ole yhteydessä Alicelle, joten jos hän luottaa Alicelle, pyydä uutta yhteyttä ja mene b. b. Jos hän on yhteydessä, ota Aliceiltä ja ilmoita uudet viestejä c. Bob ei tunne tätä keskustelua. Pyydä DHT:tä saada kutsu ensin voidakseen hyväksyä sen keskustelun ({”hakemus/kutsun”, keskustelunId}) d. Bob on eronnut (ei verkko, tai vain suljettu). Hän ei saa uutta viestiä, mutta yrittää synkronoida, kun seuraava yhteys tapahtuu

Käytäntöönpano

! [Diagramma: ruumis-chat-luokat]

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

Puhelut

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

!! Vanha luonnoksella!!

Muista

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

Kriptovaluuttot.

Jos kyseessä on DHT-arvo, joka on ennen keskusteluja, keskustelu voidaan decryptata. Ehkä meidän täytyy mennä johonkin kuin Double ratchet.

Muista

A lib might exist to implement group conversations.

Tarvitaan ECC:n tukea OpenDHT:ssä

Käyttö

Lisää rooleja?

Ryhmäpuheissa on kaksi suurta käyttötapahtumaa:

Jotain kuin Mattermost yrityksessä, yksityiskanavilla ja joillakin rooleilla (admin/spectator/bot/etc) tai koulutukselle (jos vain muutamia ovat aktiivisia).
Horisontaaliset keskustelut ovat kuin ystävien keskustelut.

Jami will be for which one?

Käytännöksen idea

Kirjan lisättäminen tai peruuttaminen voidaan tehdä myös.

Liity keskusteluun

Vain suoraan kutsuttu
Linkin/QR-koodin/joka tahansa
Via a room name? (a hash on the DHT)

Mitä tarvitsemme

Luottamuksellisuus: ryhmän chatin ulkopuolella olevien jäsenten ei pitäisi voida lukea ryhmässä olevia viestejä
Siihen asti, kun avain on hajottu, aikaisemmat viestit tulisi säilyttää luottamuksellisina (mikä suurempi kuin mahdollista).
Viestien järjestäminen: Viestejä on oltava oikeassa järjestyksessä
Synkronisation: On myös tarpeen varmistaa, että kaikki viestejä on saatavilla mahdollisimman pian.
Kestävyys: Itse asiassa DHT:n viesti kestää vain 10 minuuttia. Koska tämä on tämäntyyppisen DHT:n laskettu paras aika. Kestävyyden vuoksi tietot täytyy siirtää uudelleen DHT:n arvon joka 10 minuutin välein. Toinen tapa tehdä, kun node on offline, on antaa nodeille siirtää uudelleen tiedot. Mutta jos 10 minuutin kuluttua 8 node on vielä täällä, ne tekevät 64 pyyntöä (ja se on eksponentiaalinen).

Muut jakautuneet keinot

Tarvitsen tutkimusta.
Tarvitsen tutkimusta.
Tarvitsen tutkimusta.

Tällä hetkellä meillä on

Ryhmächatti voidaan perustaa samaan työhön, jota meillä on jo monenlaisiin laitteisiin (mutta tässä ryhmäsertifikaattiin).

Tämä siirtää tietokannan asiakkaan ja demonin.
Jos kukaan ei ole yhteydessä, synkronointi ei voi tapahtua, eikä henkilö koskaan näe keskustelua

Toinen erikoistunut DHT

Like a DHT with a superuser. (Not convinced)

Tiedostojen siirto

Tällä hetkellä tiedostojen siirto algoritmi perustuu TURN-yhteykseen (ks. Tiedostojen siirto).

Toinen ongelma: tällä hetkellä ei ole TCP-tuesta ICE:lle PJSIP:ssä. Tämä on pakollista tässä kohdassa (pjsipissä tai kotitekoisessa)

Varain

Tämä on myös yksi niistä tärkeimmistä tekijöistä, jotka ovat:
Verkkojen lineaaristen järjestelmien vahva ja hajautettu synkronointi välittömän tiedon kanssa (Sean Phillips ja Ricardo G. Sanfelice)