Enregistrament

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

A swarm is defined by the following properties:

Ability to split and merge based on network connectivity.
History synchronization. Every participant must be able to send a message to the entire group.
No hi ha autoritat central, no es pot confiar en cap servidor.
Non-repudiation. Devices must be able to verify past messages” validity and to replay the entire history.
Perfect Forward Secrecy (PFS) is provided on the transport channels. Storage is handled by each device.

La idea principal és aconseguir un arbre de Merkle sincronizat amb els participants.

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

Scenaris

Crea un amas

Bob vol crear un nou enjame

Bob creates a local Git repository.
Després, crea un primer compromís signat amb el següent:
- La seva clau pública en /admins
- El seu certificat de dispositiu en ̀ /dispositius`
- El seu RLC en ̀ /crls`
El hash del primer comit es converteix en l’ID de la conversa
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.

A més d’un

Bob adds Alice

Bob adds Alice to the repo:
- A més, s’admet l’URI convidat en /invited
- A més, la LCR s’afegeix a /crls
Bob sends a request on the DHT.

Recebre una invitació

Alice gets the invite to join the previously created swarm

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

Enviar un missatge

Alice sends a message to Bob

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

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

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

Nota

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.

Recebre un missatge

Bob receives a message from Alice

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

Validació d’un compromís

Per evitar que els usuaris empenin alguns compromisos no desitjats (amb conflictes, missatges falsos, etc.), així és com cada compromis (des de l’antic a l’últim) DEVEU ser validat abans de fusionar una branca remota:

Nota

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

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

Prohibir un dispositiu

Important

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

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

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

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

Els sistemes similars (amb sistemes distribuïts de grups) no són tan molts, però aquests són alguns exemples:

[mpOTR no defineix com prohibir algú] (https://www.cypherpunks.ca/~iang/pubs/mpotr.pdf)
La senyal, sense cap servidor central per a la conversa de grup (EDIT: han canviat recentment aquest punt), no dóna la capacitat d’interdire a algú d’un grup.

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

Retirar un dispositiu de la conversa

Aquesta és l’única part que ha de tenir un consens per evitar la divisió de la conversa, com si dos membres es pateixen l’un a l’altre de la conversa, què veurà la tercera?

Això és necessari per detectar dispositius revocats, o simplement evitar que persones no desitjades siguin presents en una sala pública.

Alice retira Bob

Important

Alice MUST be an admin to vote.

Per fer-ho, crea el fitxer en /votes/ban/membres/uri_bob/uri_alice (els membres poden ser substituïts per dispositius per a un dispositiu, o convidats per invitacions o administradors per als administradors) i comprometeix
Després comprova si el vot està resolut. Això significa que >50% dels administradors estan d’acord a prohibir Bob (si és sola, segur que és més del 50%).
Si el vot és resolut, els arxius en /votes/ban poden ser eliminats, tots els arxius per a Bob en /membres, /admins, /invitats, /CRLs, /dispositius poden ser eliminats (o només en /dispositius si és un dispositiu que està prohibit) i el certificat de Bob pot ser posat en /banned/membres/bob_uri.crt (o /banned/devices/uri.crt si un dispositiu està prohibit) i comprometut al repo
Després, Alice informa altres usuaris (fora de 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
Després comprova si el vot està resolut. Això significa que >50% dels administradors estan d’acord a prohibir Bob (si és sola, segur que és més del 50%).
Si el vot és resolut, els arxius en /votes/unban es poden eliminar, tots els arxius per Bob en /membres, /admins, /invitats, /CRLs, es poden afegir de nou (o només en /dispositius si és un dispositiu que no està prohibit) i comprometre al repo

Eliminar una conversa

Salvar en convInfos removed=time::now() (com eliminarContact salva en contactes) que la conversa es retira i es sincroniza amb els dispositius d’altres usuaris
Ara, si es reben un nou compromés per a aquesta conversa es ignora
Ara, si Jami està en funcionament i el repo encara està present, la conversa no es anuncia als clients
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.
Quan ens hem de ser segurs que algú està sincronizat, eliminar borrat=time::now() i sincronizar amb els dispositius d’altres usuaris
Tots els dispositius propietat de l’usuari ara poden esborrar el repositori i arxius relacionats

Com especificar un mòde

Els mòdes no es poden canviar en el temps. O és una altra conversa. Així, aquestes dades es almacenen en el missatge inicial de commit. El missatge de commit serà el següent:

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

Per ara, «mode» accepta valors 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 are unable to be ignored:

El procés és el mateix, un compte pot afegir un contacte a través de addContact, després enviar una petició de confiança a través del DHT. Però dos canvis són necessaris:

La TrustRequest incorpora una «conversacióId» per informar al company quina conversa clonar quan accepta la petició
TrustRequest es retestaran quan el contacte torna a la xarxa. No és el cas avui (com no volem generar una nova TrustRequest si el peer descartar el primer). Així, si un compte rebia una petició de confiança, serà automàticament ignorada si la petició amb una conversa relacionada es rebutja (com convRequests es sincronizen)

Després, quan un contacte accepta la petició, és necessari un període de sincronizació, perquè el contacte ara necessita clonar la conversa.

removeContact() eliminarà el contacte i les converses 1:1 relacionades (amb el mateix procés que «Remove a conversation»).

Scenaris complicats

Hi ha alguns casos en què es poden crear dues converses.

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

o

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

Important

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() retornarà {{«sincronizació»: «veritable»}} si es sincroniza.
ConfigurationManager::getConversationMembers() will return a map of two URIs (the current account and the peer who sent the request).

Les converses demanen especificacions

Les peticions de converses estan representades per un Map<String, String> amb les següents tecles:

id: the conversation ID
from: URI of the sender
recepció: timestamp
títol: (opcional) nom de la conversa
Descripció: (opcional)
avatar: (optional) the profile picture

Sincronizació de perfil de la conversa

Per ser identificable, una conversa generalment necessita alguns metadades, com un títol (per exemple: Jami), una descripció (per exemple: alguns enllaços, què és el projecte, etc.), i una imatge (el logotip del projecte). Aquestes metadades són opcionals, però compartides entre tots els membres, per la qual cosa cal sincronizar-les i incorporar-les a les sol·licituds.

Emmagatzematge en el repositori

El perfil de la conversa es guarda en un fichier vCard clàssic a la raíz (/profile.vcf) com:

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

Sincronizació

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

Últimament visualitzat

En les dades sincronizades, cada dispositiu envia a altres dispositius l’estat de les converses. En aquest estat, l’últim visualitzat és enviat. No obstant això, ja que cada dispositiu pot tenir el seu propi estat per a cada conversa, i probablement sense el mateix últim compromis en algun moment, hi ha diversos escenaris per tenir en compte:

Es suporten 5 escenaris:

si l’última visualització enviada per altres dispositius és la mateixa que l’actual, no hi ha res que fer.
Si no hi ha cap últim display per al dispositiu actual, s’utilitza el missatge que es visualitza a distància.
si l’última distància mostrada no està present en el repo, significa que el commit serà recuperat més tard, així que emmagatzemar el resultat
si el telecomàndit ja està recollit, comprovem si l’últim local que es mostra és anterior en la història per reemplaçar-lo
Finalment, si s’anuncia un missatge del mateix autor, significa que hem de actualitzar l’últim que es va mostrar.

Preferències

Cada conversa té adjuntades preferències establertes per l’usuari. Aquestes preferències són sincronizades entre els dispositius de l’usuari. Aquest pot ser el color de la conversa, si l’usuari vol ignorar les notificacions, límit de mida de transferència de fitxers, etc. Per ara, les claus reconegudes són:

«color» - the color of the conversation (#RRGGBB format)
«ignoreNotifications» - ignorar notificacions de nous missatges en aquesta conversa
«símbol» - per definir un emoji predeterminat.

Aquestes preferències es guarden en un paquet MapStringString, emmagatzemat en accountDir/conversation_data/conversationId/preferences i només es transmeten entre els dispositius del mateix usuari a través de SyncMsg.

L’API per interactuar amb les preferències són:

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

Gestió de conflictes de fusió

Com que dos administradors poden canviar la descripció al mateix temps, un conflicte de fusió pot ocórrer en profile.vcf. En aquest cas, es triarà el commit amb el hash més alt (per exemple ffffff > 000000).

APIs

L’usuari té 2 mètodes per obtenir i ajustar les metadades de conversa:

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

on infos és un map<str, str> amb les següents tecles:

Mód: Només per llegir
títol
Descripció
avatar: the profile picture

Reimportar un compte (enllaç/exportació)

L’arxiu DEVEU contenir conversaId per poder recuperar converses en nous commits després d’una reimport (perquè no hi ha invitació en aquest punt).

La conversa està allà, en aquest cas, el dimó és capaç de clonar aquesta conversa
La conversaId està faltant, així que el demó demana (via un missatge {{"aplicació/invitar", conversaId}}) una nova invitació que l’usuari necessita (re) accepta

Important

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

Protocols utilitzats

Git

Per què aquesta decisió

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

Hem de sincronizar i ordenar missatges. L’arbre de Merkle és la estructura perfecta per fer-ho i pot ser linearizat mitjançant la fusió de branques. A més, perquè és utilitzat masivament per Git, és fàcil sincronizar entre dispositius.
Distribuïda per la natura, utilitzada en massa, amb molts fonaments i col·legables.
Pot verificar els compromisos a través de gancs i criptografia utilitzada masivament
Es pot emmagatzemar en una base de dades si és necessari
Els conflictes s’eviten utilitzant missatges de compromisos, no arxius.

El que hem de validar

Performance? git.lock pot ser baixa
Anxols en libgit2
Múltiples tires al mateix temps?

Limits

Per eliminar una conversa, el dispositiu ha de deixar la conversa i crear una altra.

No obstant això, els missatges no permanents (com els missatges legibles només per alguns minuts) es poden enviar a través d’un missatge especial a través del DRT (com les notificacions de TIP o de lectura).

Estructura

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

Transferència de fitxers

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.

Protocol

El remetent agrega un nou compromés a la conversa amb el següent 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";

i crea un enllaç en ${data_path}/conversation_data/${conversation_id}/${file_id} on file_id=${commitid}_${value["tid"]}.${extension}

Després, el receptor pot descarregar els arxius contactant els dispositius que hospedeixen el fitxer oberint un canal amb name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId i emmagatzemar la informació que el fitxer està esperant en ${data_path}/conversation_data/${conversation_id}/waiting

El dispositiu que rebi la connexió accepta el canal verificant si el fitxer pot ser enviat (si sha3sum és correcte i si el fitxer existeix). El receptor mantindrà el primer canal obert, tanca els altres i escriurà en un fitxer (amb el mateix camí que el remetent: ${data_path}/conversation_data/${conversation_id}/${file_id}) totes les dades entrants.

Quan la transferència està finalitzada o el canal tancat, el sha3sum es verifica per validar que el fitxer és correcte (o s’elimina).

En cas de fallida, quan un dispositiu de la conversa tornarà a estar en línia, demanarem tots els arxius d’espera de la mateixa manera.

Call in Swarm

Idea

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

«accountUri/deviceId/conversationId/confId» on accountUri/deviceId descriu l’hoste.

L’hoste pot ser determinat de dues maneres:

In the swarm metadatas. Where it’s stored like the title/desc/avatar (profile picture) of the room
O el primer que va trucar.

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)

Així que cada part rebrà la informació que una trucada ha començat i podrà unir-se a ella trucant-la.

Atacs?

Avoid Git bombs

Notes

La marca de temps d’un compromés es pot confiar perquè és editable. Només es pot confiar en la marca de temps de l’usuari.

TLS

Les operacions Git, control de missatges, arxius i altres coses utilitzarà un enllaç TLS v1.3 p2p amb només xifres que garanteixen PFS. Així que cada clau es renegocia per cada nova connexió.

DHT (UDP)

Utilitzat per enviar missatges per mòbils (per activar notificacions push) i per iniciar connexions TCP.

Activitat de xarxa

Process de convidar algú

Alice vol convidar Bob:

Alice agrega Bob a una conversa
Alice generates an invite: { «application/invite+json» : { «conversationId»: «$id», «members»: [{…}] }}
Dues possibilitats per enviar el missatge a. Si no està connectat, a través de la DHT b. Altrament, Alice envia en el canal SIP
Bob a. Recep la invitació, una senyal es emeteix per al client b. No està connectat, per tant mai rebut la petició perquè Alice no ha de saber si Bob acaba d’ignorar o bloquejar Alice.

Process per enviar un missatge a algú

Alice vol enviar un missatge a Bob:

Alice agrega un missatge en el repo, donant una identificació
Alice obté un missatge (de si mateixa) si és exitós
En tots dos casos es crea un missatge: { «application/im-gitmessage-id» : «{«id»:»$convId", "commit":"$commitId», «deviceId»: «$alice_device_hash»}»}.
Quatre possibilitats per a Bob: a. Bob no està connectat a Alice, així que si confia en Alice, demana una nova connexió i vai a b. b. Si està connectat, tracti d’Alice i anuncia nous missatges c. Bob no coneix aquesta conversa. Demana a través de la DHT per obtenir una invitació primer per poder acceptar aquesta conversa ({«aplicació/invitar», conversaId}) d. Bob està desconectat (nesses xarxes, o tan sols tancat).

Implementació

! Diagrama: classes de discurs en enjambres

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

Trucades

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

!! Vell projecte!!

Nota

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

Millora de criptografia.

Per a una funció de discurs de grup seria, també necessitem criptografia seria. Amb el disseny actual, si un certificat es roba com els valors DHT anteriors d’una conversa, la conversa pot ser descriptada. Potser hem de anar a alguna cosa com ** Double ratchet**.

Nota

A lib might exist to implement group conversations.

Necessitat de suport ECC en OpenDHT

Utilització

A més de papers?

Hi ha dos casos d’ús principals per a les converses de grup:

Algú com un Mattermost en una empresa, amb canals privats, i alguns papers (admin/spectador/bot/etc) o per a l’educació (on només uns pocs són actius).
Les converses horitzontals són com una conversa entre amics.

Jami will be for which one?

Idea d’aplicació

Certificat per a un grup que signe l’usuari amb una bandera per a un paper.

Jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo jo

Només per invitació directa
A través d’un enllaç/Códi QR/qualsevol
Per mitjà d’un nom de habitació?

El que necessitem

Confidencialitat: els membres fora del grup de discurs no han de poder llegir missatges en el grup
Segrecia: si alguna clau del grup es compromet, els missatges anteriors han de mantenir-se confidencials (al màxim possible)
Ordenació de missatges: cal tenir missatges en l’ordre correcte
Sincronizació: També cal assegurar-se que tots els missatges tinguin el més aviat possible.
Per a mantenir les dades, el node ha de tornar a posar el valor del DHT cada 10 minuts. Una altra manera de fer-ho quan el node està fora de línia és deixar que els nodes reponen les dades. Però, si després de 10 minuts, 8 nodes estan encara aquí, faran 64 peticions (i és exponencial).

Altres formes distribuïdes

IPS: Necessitem una investigació
Necessito una investigació.
Necessitem una investigació.

Basant-se en el treball actual que tenim

El chat de grup pot ser basat en el mateix treball que ja tenim per a múltiples dispositius (però aquí, amb un certificat de grup).

Això necessita traslladar la base de dades del client al daemon.
Si ningú està connectat, la sincronizació no es pot fer, i la persona mai veurà la conversa

Un altre DHT dedicat

Com un DHT amb un superusuari.

What’s next for file transfers

Currently, the file transfer algorithm is based on a TURN connection (See Transferència de fitxers). In the case of a big group, this will be bad. We first need a P2P connection for the file transfer. Implement the RFC for P2P transfer.

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

Enregistrament

Scenaris

Crea un amas

A més d’un

Recebre una invitació

Enviar un missatge

Recebre un missatge

Validació d’un compromís

Prohibir un dispositiu

Retirar un dispositiu de la conversa

Eliminar una conversa

Com especificar un mòde

Processes for 1:1 chats

Scenaris complicats

Les converses demanen especificacions

Sincronizació de perfil de la conversa

Emmagatzematge en el repositori

Sincronizació

Últimament visualitzat

Preferències

Gestió de conflictes de fusió

APIs

Reimportar un compte (enllaç/exportació)

Protocols utilitzats

Git

Per què aquesta decisió

El que hem de validar

Limits

Estructura

Transferència de fitxers

Protocol

Call in Swarm

Idea

Atacs?

Notes

TLS

DHT (UDP)

Activitat de xarxa

Process de convidar algú

Process per enviar un missatge a algú

Implementació

Supported messages

Initial message

Text message

Trucades

Add a file

Updating profile

Member event

Vote event

Millora de criptografia.

Utilització

A més de papers?

Idea d’aplicació

El que necessitem

Altres formes distribuïdes

Basant-se en el treball actual que tenim

Un altre DHT dedicat

What’s next for file transfers

Recursos