Skarm

Vigtigt

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

Synospis

Formålet med dette dokument er at beskrive, hvordan gruppechat (også kendt som swarm chat) vil blive implementeret i Jami.

En swarm er en gruppe, der kan diskutere uden nogen central myndighed på en robust måde. Hvis to personer ikke har nogen forbindelse til resten af gruppen (det vil sige internetudbrud), men de kan kontakte hinanden (i et LAN for eksempel eller i et subnetværk), vil de være i stand til at sende meddelelser til hinanden og derefter, vil være i stand til at synkronisere med resten af gruppen, når det er muligt.

Så, den swarm er defineret af:

1. Evne til at splittet og fusioneret efter forbindelsen.

2. Alle skal kunne sende en besked til hele gruppen.

3. Ingen central myndighed, ingen server.

4. Enhederne skal kunne kontrollere, at gamle meddelelser er gyldige og genbruge hele historien.

5. PFS on the transport. Storage is managed by the device.

Hovedidéen er at få et synkroniseret Merkle-træ med deltagerne.

Vi har identificeret fire modus til swarm chat, som vi vil implementere:

• ONE_TO_ONE, det er i grunden den sag, vi har i dag, når du diskuterer med en ven

• ADMIN_INVITES_ONLY generelt en klasse, hvor læreren kan invitere folk, men ikke eleverne

• INVITER_ONLY en privat gruppe venner

• Public er i det væsentlige et åbent forum

Scenarier

Skab en flok

Bob vil skabe en ny sværm

1. Bob creates a local Git repository.

2. Så opretter han et første underskrevet engagement med følgende:

   • Hans offentlige nøgle i /admins

   • Hans udstyrsertifikat i ̀ /apparater `

   • Hans CRL i ̀ /crls`

3. Hashet i det første indlæg bliver samtaleens ID

4. Bob meddeler sine andre enheder, at han opretter en ny samtale. Dette sker via en invitation til at slutte sig til sværmen sendt gennem DHT til andre enheder forbundet med den konto.

Tilføjelse af nogen

Alice tilføjer Bob

1. Alice tilføjer Bob til repo:

   • Tilføj den indkaldte URI i /invited

   • Lægger CRL til /crls

2. Alice sender en anmodning om DHT

At modtage en invitation

Alice får invitationen til at slutte sig til den tidligere skabte sværm

1. Hun accepterer invitationen (hvis han afviser, gør han ingenting, så bliver han inviteret, og Alice får aldrig nogen besked)

2. En peer-to-peer forbindelse mellem Alice og Bob er færdig.

3. Alice pull the Git repo of Bob. WARNING this means that messages need a connection, not from the DHT like today.

4. Alice bekræfter Bobs forpligtelser

5. For at bekræfte, at Alice er medlem, fjerner hun invitationen fra /invited-registeret, og føjer derefter sit certifikat til /members-registeret.

6. Når alle forpligtelser er valideret og på hendes enhed, andre medlemmer af gruppen opdaget af Alice.

Sende en besked

Alice sender en besked

Alice skriver en commit-melding i følgende format:

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

For pinging andre enheder, sender afsenderen til andre medlemmer en SIP-meddelelse med mimetype = »applikation/im-gitmessage-id« indeholdende en JSON med »deviceId« som sender meddelelsen, »id« af samtalen relateret, og »forpligt«

Jeg modtager en besked

Bob modtager beskeden fra Alice

1. Bob do a Git pull on Alice

2. Forpligtelser skal kontrolleres via en krog

3. Hvis alle commits er gyldige, gemmes og vises commits.

4. If all commits are not valid, pull is canceled. Alice must reestablish her state to a correct state.

Validering af et tilsagn

For at undgå, at brugere skubber nogle uønskede commits (med konflikter, falske meddelelser, osv.), er det sådan, at hver commit (fra den ældste til den nyeste) MÅS være valideret før fusion af en fjerngren:

Bemærk

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 hver forpligtelse skal du kontrollere, at det anlæg, der forsøger at sende forpligtelsen, er godkendt på dette tidspunkt, og at certifikaterne er til stede (i/enhederne for anordningen og i/medlemmer eller/administratorer for udstederen).

• Det er en fusion, der ikke kan bekræftes.

• Kommitten har 0 forældre, det er den oprindelige forpligtelse:

  • Kontroller, at admin certificering er tilføjet

  • Kontroller, at enhedcertifikat er tilføjet

  • Kontrol CRL’er tilføjet

  • Tjek, at der ikke er tilføjet andre filer

• Kommit har 1 moderskab, kommit budskab er en JSON med en type:

  • Hvis tekst (eller anden mime-type, der ikke ændrer filer)

    • Kontrol af undertegnelse fra certifikatet i repo

    • Tjek at ingen mærkelige fil er tilføjet uden for enhed certificering eller fjernet

  • Hvis man stemmer

    • Kontroller, at voteType understøttes (forbud, afbannelse)

    • Kontroller, at stemmen er for den bruger, der underskriver forpligtelsen

    • Check that vote is from an admin and device present and not banned

    • Tjek, at ingen mærkelige fil er tilføjet eller fjernet

  • Hvis medlem

    • Hvis tilføjer

      • Kontroller, at bindelsen er underskrevet korrekt

      • Kontroller, om certificatet er tilføjet i / inviteret

      • Tjek, at ingen mærkelige fil er tilføjet eller fjernet

      • Hvis ONE_TO_ONE, tjek at vi kun har en administrator, et medlem

      • Hvis ADMIN_INVITES_ONLY, tjek at invitationen er fra en admin

    • Hvis det tilslutter sig

      • Kontroller, at bindelsen er underskrevet korrekt

      • Kontroller, at enheden er tilføjet

      • Kontroller, om invitationen er flyttet til medlemmer

      • Tjek, at ingen mærkelige fil er tilføjet eller fjernet

    • Hvis det er forbudt

      • Tjek, om afstemningen er gyldig.

      • Kontroller, at brugeren er forbudt via en admin

      • Kontroller, om medlemss- eller udstyrscertifikat er flyttet til forbuddet/

      • Kontroller, at kun filer relateret til afstemningen fjernes

      • Tjek, at ingen mærkelige fil er tilføjet eller fjernet

  • Hvis du ikke kan få adgang til en version, skal du underrette brugeren om, at den er blevet sendt med en gammel version eller at en anden bruger har forsøgt at sende uønskede kommentarer.

Banned en enhed

Alice, Bob, Carla og Denys er i en sværm.

Det er et af de vanskeligste scenarier i vores sammenhæng, og uden central myndighed kan vi ikke stole på:

1. Tidsstempler på de genererede forpligtelser

2. Hvis flere administrationsapparater er til stede, og hvis Alice kan tale med Bob, men ikke Denys og Carla; Carla kan tale med Denys; Denys forbyder Alice, Alice forbyder Denys, hvad vil det være, når de 4 medlemmer vil slå samtalen sammen.

3. En enhed kan blive kompromitteret, stjålet eller certificeret, og vi bør kunne forbyde en enhed og undgå, at den lyver om, at den er udløbet eller sender meddelelser i fortiden (ved at ændre certificeret eller tidsstemplet på sit engagement).

Der er ikke så mange lignende systemer (med distribuerede gruppesystemer), men her er nogle eksempler:

• [mpOTR definerer ikke, hvordan man forbyder nogen]

• Signal, uden nogen central server til gruppechat (EDIT: de ændrer det punkt for nylig), giver ikke mulighed for at forbyde nogen fra en gruppe.

Dette stemmeret kræver en menneskelig indsats for at forbyde nogen eller skal baseres på de CRL-oplysninger fra arkivet (for vi kan ikke stole på eksterne CRL’er)

Fjern en enhed fra en samtale

Det er den eneste del, der skal være enighed om at undgå en splittelse, som hvis to medlemmer sparker hinanden fra samtalen, hvad vil det tredje?

Dette er nødvendigt for at opdage tilbagekaldte enheder, eller blot undgå at få uønskede personer til stede i et offentligt rum.

Alice fjerner Bob

Vigtigt

Alice MUST be an admin to vote.

• For det første stemmer hun for at forbyde Bob. For at gøre det opretter hun filen i /votes/ban/members/uri_bob/uri_alice (medlemmer kan erstattes med enheder til en enhed, eller inviteres til invitationer eller admins til admins) og forpligter

• Så kontrollerer hun, om afstemningen er afgjort. Det betyder, at >50% af administratorer er enige om at forbyde Bob (hvis hun er alene, er det sikkert mere end 50%).

• Hvis afstemningen er løst, kan filer i /votes/ban fjernes, alle filer til Bob i /members, /admins, /invited, /CRLs, /devices kan fjernes (eller kun i /devices hvis det er en enhed, der er forbudt) og Bobs certifikat kan placeres i /banned/members/bob_uri.crt (eller /banned/devices/uri.crt hvis en enhed er forbudt) og indsættes til repo

• Så informerer Alice andre brugere (uden 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

• Så kontrollerer hun, om afstemningen er afgjort. Det betyder, at >50% af administratorer er enige om at forbyde Bob (hvis hun er alene, er det sikkert mere end 50%).

• Hvis afstemningen er løst, kan filer i /votes/unban fjernes, alle filer til Bob i /members, /admins, /invited, /CRLs, kan føjes tilbage (eller kun i /devices hvis det er en enhed, der er ubanned) og indsættes til repo

Fjern en samtale

1. Gem i convInfos fjernet=tid::nu() (som fjernKontakt gemmer i kontakter) at samtalen fjernes og synkroniseres med andre brugerens enheder

2. Hvis der er en ny besked, ignoreres den.

3. Hvis Jami starter og repo er stadig til stede, bliver samtalen ikke annonceret til kunderne.

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. Når vi er sikre på, at nogen er synkroniseret, fjern de er slettet = time::now() og synkronisere med andre brugers enheder

6. Alle enheder ejet af brugeren kan nu slette arkivet og relaterede filer

Sådan angives en modus

Moderne kan ikke ændres gennem tiden. Eller det er en anden samtale. Så, disse data gemmes i den oprindelige commit budskab.

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

For nu accepterer »modus« værdier 0 (ONE_TO_ONE), 1 (ADMIN_INVITES_ONLY), 2 (INVITES_ONLY), 3 (PUBLIC)

Processes for 1:1 swarms

Målet her er at holde den gamle API (addContact/removeContact, sendTrustRequest/acceptTrustRequest/discardTrustRequest) til at generere en sværm med en peer og dens kontakt. Dette indebærer stadig nogle ændringer, som vi ikke kan ignorere:

Processen er stadig den samme, en konto kan tilføje en kontakt via addContact, og derefter sende en TrustRequest via DHT. Men to ændringer er nødvendige:

1. TrustRequest indlejrer en »conversationId« for at informere peer om hvilken samtale man skal klone, når man accepterer anmodningen

2. TrustRequest bliver genprøvet, når kontakten kommer tilbage online. Det er ikke tilfældet i dag (som vi ikke ønsker at generere en ny TrustRequest, hvis peer kasserer den første). Så hvis en konto modtager en tillidsforespørgsel, vil den automatisk ignoreres, hvis anmodningen med en relateret samtale afvises (som convRequests synkroniseres)

Når en kontakt accepterer anmodningen, er der en synkroniseringsperiode, fordi kontakten nu skal klone samtalen.

removeContact() fjerner kontakten og relaterede 1:1-samtaler (med samme proces som »Remove a conversation«). Den eneste note her er, at hvis vi forbyder en kontakt, vi ikke venter på synkronisering, vi bare fjerner alle relaterede filer.

Trællige scenarier

Der er nogle tilfælde, hvor der kan ske to samtaler.

1. Alice adds Bob.

2. Bob accepts.

3. Alice removes Bob.

4. Alice adds Bob.

eller

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

I dette tilfælde genereres to samtaler. Vi ønsker ikke at fjerne meddelelser fra brugere eller vælge en samtale her. Så nogle gange vil to 1:1-sværm mellem de samme medlemmer vises. Det vil generere nogle fejl i overgangstiden (som vi ikke ønsker at bryde API, vil den afledte samtale være en af de to vist samtaler, men for nu er det »ok-ish«, vil blive rettet, når klienter fuldt ud håndterer samtaleId for alle API’er (opkald, filoverførsel, osv.).

Vigtigt

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() returnerer {{»synkronisering«: »rigtig«}} hvis synkronisering.

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

Samtaler kræver specifikation

Forlangelser til samtale er repræsenteret med en Map<String, String> med følgende nøgler:

• id: the conversation ID

• from: URI of the sender

• modtaget: tidsstempel

• Titel: (valgfrit) navn på samtalen

• Beskrivelse: (valgfrit)

• Avatar: (valgfrit)

Samtalernes profil synkronisering

For at være identificerbar, har en samtale generelt brug for nogle metadata, såsom en titel (f.eks. Jami), en beskrivelse (f.eks. nogle links, hvad projektet er osv.) og et billede (projektets logo).

Lagring i lageret

Profilen af samtalen gemmes i en klassisk vCard-fil i roten (/profile.vcf) som:

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

Synkronisering

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

Sidst vist

I de synkroniserede data sender hver enhed til andre enheder samtalernes tilstand. I denne tilstand sendes den sidste, der vises.

Der er støtte til fem scenarier:

• Hvis den sidste af de andre enheder, der er sendt, er den samme som den nuværende, er der intet at gøre.

• Hvis der ikke er en sidste visning for den aktuelle enhed, anvendes den fjernvisede besked.

• Hvis den fjerntliggende last vises ikke er til stede i repo, betyder det, at commit vil blive hentet senere, så cache resultatet

• Hvis fjernbetjeningen allerede er hentet, tjekker vi, at den sidste lokale vises er før i historien for at erstatte den

• Endelig, hvis en meddelelse fra den samme forfatter bliver annonceret, betyder det, at vi skal opdatere den sidste, der er vist.

Fortrinsret

Hver samtale har knyttet præferencer, der er indstillet af brugeren. Disse præferencer synkroniseres på brugerens enheder. Dette kan være samtalen farve, hvis brugeren ønsker at ignorere meddelelser, filoverførsel størrelse grænse, osv. For nu er de anerkendte nøgler:

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

• »ignoreNotifications« - at ignorere meddelelser om nye meddelelser i denne samtale

• »symbol« - at definere en standard emoji.

Disse præferencer gemmes i en MapStringString-pakke, der gemmes i accountDir/conversation_data/conversationId/preferences og kun sendes over enheder af samme bruger via SyncMsg.

API’erne til at interagere med præferencerne er:

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

Fusionskonfliktstyring

Da to admins kan ændre beskrivelsen samtidig, kan der opstå en fusionskonflikt på profile.vcf. I dette tilfælde vil det blive valgt det commit med den højere hash (ffffff > 000000).

API’er

Brugeren fik 2 metoder til at få og indstille samtale metadata:

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

hvor infos er et map<str, str> med følgende nøgler:

• Modus: LÆS-ENIG

• Titel

• Beskrivelse

• avatar

Indførsel af en konto (link/export)

Arkivet MÅSTE indeholde conversationId for at kunne hente samtaler på nye commits efter en reimport (for der er ingen invitation på dette tidspunkt).

• Samtalen er der, i dette tilfælde kan dæmonen klone denne samtale igen.

• KonversationId er væk, så daemon spørger (via en besked {{"applikation/invit", conversationId}}) en ny invitation, som brugeren skal (re) acceptere

Vigtigt

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

Brugen af protokoller

Git

Hvorfor dette valg

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

1. Merkle Tree er den perfekte struktur til at gøre det og kan linearieres ved at smelte grene sammen.

2. Massivt brugt, mange baggrunde og pluggable.

3. Kan verificere engagementer via hooks og massivt brugt kryptovaluta

4. Kan lagres i en database, hvis det er nødvendigt

5. Konflikter undgårs ved at bruge commit-meddelelser, ikke filer.

Hvad vi skal bekræfte

• Performance? git.lock kan være lav

• Højker i libgit2

• Flere træk på samme tid?

Grænser

For at slette en samtale, må enheden forlade samtalen og oprette en ny.

Ikke-permanente meddelelser (som for eksempel meddelelser, der kun kan læses i nogle minutter) kan dog sendes via en særlig meddelelse via DRT (som for eksempel indtømmelses- eller læse-meddelelser).

Struktur

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

Fileroverførsel

Swarm ændrer massivt filoverførsel. Nu synkroniserer hele historien, hvilket giver alle enheder i samtalen mulighed for nemt at hente gamle filer. Disse ændringer giver os mulighed for at flytte fra en logik, hvor afsenderen skubbede filen på andre enheder, via at forsøge at forbinde til deres enheder (dette var dårligt, fordi det ikke var rigtig modstandsdygtigt mod forbindelser ændrer / fejl og havde brug for en manuel genprøve) til en logik, hvor afsenderen tillader andre enheder at downloade.

Protokol

Afsenderen tilføjer et nyt commit i samtalen med følgende format:

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

og opretter et link i ${data_path}/conversation_data/${conversation_id}/${file_id} hvor file_id=${commitid}_${value["tid"]}.${extension}

Derefter kan modtageren nu downloade filerne ved at kontakte de enheder, der er vært for filen ved at åbne en kanal med name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId og gemme den information, at filen venter i ${data_path}/conversation_data/${conversation_id}/waiting

Enheden, der modtager forbindelsen, accepterer kanalen ved at kontrollere, om filen kan sendes (hvis sha3sum er korrekt og hvis filen eksisterer). Modtageren vil holde den første åbne kanal, lukke de andre og skrive i en fil (med den samme vej som afsenderen: ${data_path}/conversation_data/${conversation_id}/${file_id}) alle indgående data.

Når overførslen er afsluttet eller kanalen lukket, verifiseres sha3sum for at bekræfte, at filen er korrekt (eller det er slettet). Hvis den er gyldig, fjernes filen fra ventetiden.

Hvis vi ikke kan, vil vi, når en enhed i samtalen kommer tilbage, bede om alle ventede filer på samme måde.

Ring til swarm

Ideer

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

»accountUri/deviceId/conversationId/confId«, hvor accountUri/deviceId beskriver værten.

Værten kan bestemmes på to måder:

• I sværmen er metadata gemt som værelset.

• Eller den første opkaldt.

Når en opkald startes, tilføjer værten en ny forpligtelse til sværmen, med URI til at deltage (accountUri/deviceId/conversationId/confId). Dette vil være gyldigt indtil afslutningen af opkaldet (anonseret af en forpligtelse med varigheden at vise)

Hver del vil modtage informationen om, at en opkald er startet, og kan deltage ved at ringe til den.

Angreb?

• Avoid Git bombs

Noter

Tidsstemplet på et commit kan stole på, fordi det kan redigeres. Kun brugernes tidsstemplet kan stole på.

TLS

Git-operationer, kontrolbeskeder, filer og andre ting vil bruge en p2p TLS v1.3 link med kun ciphere, der garanterer PFS. Så hver nøgle bliver genforhandlet for hver ny forbindelse.

DHT (UDP)

Bruges til at sende meddelelser til mobiltelefoner (til at udløse push-meddelelser) og til at initiere TCP-forbindelser.

Netværksaktivitet

Indkaldelse af en person

Alice vil invitere Bob:

1. Alice tilføjer Bob til en samtale

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

3. To muligheder for at sende meddelelsen a. Hvis ikke forbundet, via DHT b. Ellers sender Alice på SIP-kanalen

4. To muligheder for Bob a. Modtager invitationen, udsendes et signal til klienten b. Ikke forbundet, så vil aldrig modtage anmodningen, fordi Alice må ikke vide, om Bob bare ignorerede eller blokerede Alice. Den eneste måde er at regenerere en ny invitation via en ny besked (jf. næste scenario)

Forløb for at sende en besked til nogen

Alice vil sende en besked til Bob:

1. Alice tilføjer en besked i repo, giver en ID

2. Alice får en besked modtaget (fra sig selv) hvis det lykkes

3. I begge tilfælde er der oprettet en besked: { »application/im-gitmessage-id« : »{»id«:«\(convId", "commit":"\)commitId«, »deviceId«: »$alice_device_hash«}«}. a. Hvis ikke forbundet, via DHT b. Ellers sender Alice på SIP-kanalen

4. Bob har fire muligheder: a. Bob er ikke forbundet med Alice, så hvis han stoler på Alice, så spørg om en ny forbindelse og gå til b. b. Hvis han er forbundet, hent fra Alice og meddel ny meddelelser c. Bob kender ikke den samtale. Spørg gennem DHT for at få en invitation først for at kunne acceptere den samtale ({»ansøgning/invitation«, samtaleId}) d. Bob er afkoblet (ingen netværk, eller bare lukket). Han vil ikke modtage den nye besked, men vil forsøge at synkronisere, når den næste forbindelse vil forekomme

Udførelse

! [Diagram: swarm chat klasser](billeder/ swarm chat-klass-diagram.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"
}

Opkald

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

---

!! OLD DRAFT!!

Bemærk

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

Kryptoforbedringer.

Hvis et certifikat bliver stjålet som tidligere DHT-værdier i en samtale, kan samtalen decrypteres. Måske skal vi gå til noget som Double Ratchet.

Bemærk

A lib might exist to implement group conversations.

Behov for ECC-støtte i OpenDHT

Brugen

Add Roles?

Der er to vigtige anvendelsesmuligheder for gruppechat:

1. Et andet eksempel er et Mattermost i et selskab, med private kanaler, og nogle roller (admin/spektor/bot/etc) eller for uddannelse (hvor kun få er aktive).

2. Horisontale samtaler er som en samtale mellem venner.

Jami will be for which one?

Implementeringsideen

Et certifikat for en gruppe, der signerer en bruger med et flag for en rolle.

Tag med i en samtale

• Kun via en direkte invitation

• Ved hjælp af en link/QR-kode/hvad som helst

• Via a room name? (a hash on the DHT)

Hvad vi har brug for

• Fortrolighed: medlemmer uden for gruppen bør ikke kunne læse meddelelser i gruppen

• Forward secrecy: Hvis en nøgle fra gruppen er blevet kompromitteret, bør tidligere meddelelser forblive fortrolige (så vidt muligt)

• Beskedsløsning: Der er behov for at have beskeder i den rigtige rækkefølge

• Synkronisering: Der er også behov for at sikre sig at have alle meddelelser så hurtigt som muligt.

• Persistence: Faktisk varer en besked på DHT kun 10 minutter. Fordi det er den bedste tidsplan beregnet for denne type DHT. For at persist data, må knudelet genindføre værdien på DHT hver 10 minutter. En anden måde at gøre, når knudelet er offline, er at lade knudelet genindføre data. Men hvis efter 10 minutter, 8 knudelet er stadig her, vil de gøre 64 anmodninger (og det er eksponentielt). Den nuværende måde at undgå spam for det er forespørgsel. Dette vil stadig gøre 64 anmodninger, men begrænse max redundance til 8 knudeletter.

Andre fordeltes veje

• IPFS: Jeg har brug for en undersøgelse

• Jeg har brug for en undersøgelse.

• Maidsafe: Need some investigation

På baggrund af det nuværende arbejde, vi har

Gruppenchat kan baseres på det samme arbejde, vi allerede har for flere enheder (men her med et gruppecertifikat).

1. History sync. This needs to move the database from the client into the daemon.

2. Hvis ingen er forbundet, kan synkroniseringen ikke ske, og personen vil aldrig se samtalen

Endnu en dedikeret DHT

Som en DHT med en superbruger.

Fileroverførsel

I øjeblikket er filoverførselsalgoritmen baseret på en TURN-forbindelse (se Fileroverførsel). I tilfælde af en stor gruppe vil dette være dårligt. Vi har først brug for et p2p implementeret til filoverførslen. Implementere RFC til p2p overførsel.

Andre problemer: der er for øjeblikket ingen implementering af TCP-støtte til ICE i PJSIP. Dette er obligatorisk for dette punkt (i pjsip eller hjemmelavet)

Ressourcer

• Det er en stor del af den europæiske fælles markedsordning.

• Robust distribueret synkronisering af netværksbundne lineære systemer med intermitterende oplysninger (Sean Phillips og Ricardo G.Sanfelice)