Swarm

Önemli

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

Synospis

Bu belgenin amacı grup sohbetlerinin (diğer adıyla swarm) Jami’de nasıl uygulanacağını açıklamaktır.

Swarm herhangi bir merkezi otorite olmadan esnek bir şekilde tartışabilen bir gruptur. Aslında, iki kişinin grubun geri kalanıyla herhangi bir bağlantısı yoksa (örneğin İnternet kesintisi) ancak birbirleriyle iletişim kurabiliyorlarsa (örneğin bir LAN’da veya bir alt ağda), birbirlerine mesaj gönderebileceklerdir. ve daha sonra mümkün olduğunda grubun geri kalanıyla senkronize edilebilecektir.

Yani, swarm şu şekilde tanımlanır:

Bağlantıyı takip ederek bölünme ve birleşme yeteneği.
Tarih sinkronlaması. Herkes tüm gruba bir mesaj gönderebilmelidir.
Merkez yetkisi yok, hiçbir sunucuya güvenemezsin.
Cihazlar eski mesajların geçerliliğini doğrulayabilir ve tüm tarihini tekrarlayabilir.
Transport üzerinde PFS. Depolama cihaz tarafından yönetilir.

Ana fikir, katılımcılarla senkronize bir Merkle ağacı elde etmek.

Tanımlamak istediğimiz swarm sohbeti için dört mod belirledik:

ONE_TO_ONE, esasen bugün bir arkadaşınızla konuşurken yaşadığımız durum
ADMIN_INVITES_ONLY genellikle öğretmenin insanları davet edebileceği bir sınıf, ancak öğrencileri davet edemez
KÜÇÜK bir arkadaş grubu davet eder
PÜBLİK esasen açık bir forum

Scenariler

Bir swarm oluştur

Bob yeni bir swarm oluşturmak istiyor

Bob creates a local Git repository.
Sonra, aşağıdaki ile ilk imzalanan bir taahhüt oluşturur:
- O’nun kamu anahtarı /admins
- Cihaz sertifikası ̀ / cihazlarda `
- CRL’si ̀ /crls`
İlk commit’in hashı sohbetin ** ID ** olur.
Bob, diğer cihazlarına yeni bir görüşme oluşturduğunu duyurur. Bu, DHT aracılığıyla o hesaba bağlı diğer cihazlara gönderilen swarm’a katılma daveti yoluyla yapılır.

Birini eklemek

Alice adds Bob

Alice Bob’u repo’ya ekliyor:
- /invited olarak davet edilen URI eklenir
- CRL’yi /crls’ye ekler
Alice, DHT’de bir talep gönderdi.

Bir daveti alıyorum

Alice gets the invite to join the previously create swarm

davetini kabul eder (eğer reddederse, hiçbir şey yapmazsa, davetli olarak kalır ve Alice hiçbir mesaj alamayacaktır)
Alice ve Bob arasında bir eş-bir ilişki tamamlandı.
Alice pull the Git repo of Bob. WARNING this means that messages need a connection, not from the DHT like today.
Alice Bob’dan alınan kararları doğruluyor.
Alice’in üye olduğunu onaylamak için davetini /invited dizisinden kaldırır, ardından sertifikasını /members dizisine ekler.
Tüm işlemler doğrulanıp cihazında olduğunda, grubun diğer üyeleri Alice tarafından keşfedilmiştir. Bu yaşıtlarla birlikte, Bob’la birlikte DRT’yi (aşağıda açıklanmıştır) bir bootstrap olarak inşa edecek.

Mesaj göndermek

Alice sends a message

Mesaj göndermek oldukça basit. Alice aşağıdaki formatta bir commit mesajı yazar:

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

Diğer cihazları ping etmek için, gönderen diğer üyelerine mesajı gönderir. SIP mesajı mimetype = “app/im-gitmessage-id” ile mesajı gönderen “deviceId” ile bir JSON içerir.

Bir mesaj alıyorum

Bob receives the message from Alice

Bob do a Git pull on Alice
Bağışlar bir kanca ile doğrulanmalıdır.
Eğer tüm commit geçerli ise, commitler saklanır ve görüntülenir. Bob mesajı diğer cihazlar için DRT üzerinden duyururur.
If all commits are not valid, pull is canceled. Alice must reestablish her state to a correct state.

Bağışlamanın doğrulanması

Kullanıcıların istenmeyen bazı commit’leri (koşullar, yanlış mesajlar vb.) zorlamasını önlemek için, her commit’in (en eskiden en yeniye kadar) uzak bir dalı birleştirmeden önce nasıl doğrulanması gerekir:

Not

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.

Her bir commit için, commit göndermeye çalışan cihazın şu anda yetkili olup olmadığını ve sertifikaların mevcut olup olmadığını kontrol edin ( cihaz için cihazlarda ve emiten için / üye veya / yöneticilerde).
3 dava. 2 ebeveyn var. Bu bir birleşim.
Komitimin 0 ebeveyn olduğu için, ilk komitimin:
- Admin sertifikası eklendiğini kontrol edin
- Cihaz sertifikası eklendiğini kontrol edin
- Kontrol CRL’leri eklendi
- Başka dosya eklenmediğini kontrol et
commit’in 1 ana babası vardır, commit mesajı bir türü olan JSON’dur:
- Eğer metin (veya dosyaları değiştirmeyen diğer meme türü)
  - Reklamda sertifika imzası kontrol edilsin
  - Cihaz sertifikası dışında herhangi bir garip dosyanın eklenmediğini veya kaldırıldığını kontrol edin
- Oy kullanırsak
  - VoteType desteklendiğini kontrol edin (ban, unban)
  - Komitimi imzalayan kullanıcıya ait olduğunu kontrol edin.
  - Check that vote is from an admin and device present and not banned
  - Hiç garip dosyanın eklenmediğini veya kaldırıldığını kontrol et
- Üye
  - Eklerse
    - Komitimin doğru şekilde imzalandığını kontrol edin
    - Sertifika eklendiğini kontrol edin / davet edildi
    - Hiç garip dosyanın eklenmediğini veya kaldırıldığını kontrol et
    - Eğer ONE_TO_ONE, sadece bir admin, bir üye var mı kontrol edin
    - Eğer ADMIN_INVITES_ONLY ise, davetin bir admin tarafından gönderildiğini kontrol edin
  - Eğer katılırsa
    - Komitimin doğru şekilde imzalandığını kontrol edin
    - Cihazın eklendiğini kontrol edin
    - Davetin üyeler için aktarıldığını kontrol edin
    - Hiç garip dosyanın eklenmediğini veya kaldırıldığını kontrol et
  - Yasaklıysa
    - Oylama geçerli olup olmadığını kontrol et.
    - Kullanıcının bir admin aracılığıyla yasaklandığını kontrol edin
    - Üye veya cihaz sertifikasının yasaklama yerine geçildiğini kontrol edin.
    - Sadece oylama ile ilgili dosyaların kaldırıldığını kontrol edin
    - Hiç garip dosyanın eklenmediğini veya kaldırıldığını kontrol et
- İstifadeden önce, kullanıcıya eski bir sürümde olabileceğini veya istenmeyen komutları göndermeye çalıştığını bildirin.

Bir cihazı yasaklayın

Alice, Bob, Carla ve Denys bir swarmda. Alice Denys’i yasakladı

Bu, bağlamımızda en zor senaryolardan biridir.

Oluşan yükümlülüklerin zaman damgası
Eğer birden fazla yönetim cihazı varsa ve Alice Bob ile konuşabilir ama Denys ve Carla değilse; Carla Denys ile konuşabilirse; Denys Alice’i yasaklıyor, Alice Denys’i yasaklıyorsa, 4 üye konuşmayı birleştirdiklerinde durum ne olacak.
Bir cihaz tehlikeye girebilir, çalınabilir veya sertifikası sona erebilir.Bir cihazı yasaklayabilir ve sona ermesi veya geçmişte mesaj göndermesi (sertifika veya commit’in zaman damgasını değiştirerek) önlenebilir.

Benzer sistemler ( dağılmış grup sistemleri ile) pek fazla değildir, ancak bunlar bazı örnekler:

[mpOTR birisini nasıl yasaklayacağınızı tanımlamıyor]
Grup sohbetleri için herhangi bir merkezi sunucu olmadan (EDIT: son zamanlarda bu noktayı değiştirdiler), bir gruba kimsenin katılmasını yasaklama yeteneği vermez.

Bu oylama sistemi, birisini yasaklamak için insan eylemine ihtiyaç duyar veya depodan gelen CRL bilgileri üzerine kurulmalıdır (çünkü dış CRL’lere güvenemeyiz)

Bir konuşmadan bir cihazı çıkar

Bu konuşmanın bölünmesini önlemek için bir fikir birliği olması gereken tek bölüm. İki üye konuşmadan birbirini tekmelediğinde üçüncü kişi ne olacak?

Bu, iptal edilen cihazları tespit etmek veya sadece istenmeyen insanları kamu odasına getirmekten kaçınmak için gereklidir.

Alice removes Bob

Önemli

Alice MUST be an admin to vote.

İlk olarak Bob’u yasaklamak için oy veriyor. Bunu yapmak için dosyayı /votes/ban/members/uri_bob/uri_alice olarak oluşturur (memberler bir cihaz için cihazlar ile değiştirilebilir veya davetler veya yöneticiler için yöneticiler için davet edilebilir) ve
Sonra oyunun çözülüp çözülmediğini kontrol eder. Bu, yöneticilerin %50’inin Bob’u yasaklamaya razı olduğu anlamına gelir (tek başına ise, bu %50’den fazla olduğundan emin).
Eğer oylama çözülürse, /votes/ban dosyaları kaldırılabilir, Bob için tüm dosyalar /members, /admins, /invited, /CRLs, /device’ler kaldırılabilir (veya sadece /device’ler yasaklanmış bir cihazsa) ve Bob’un sertifikası /banned/members/bob_uri.crt’e yerleştirilir (veya /banned/devices/uri.crt bir cihaz yasaklanmışsa) ve repo’ya ödeneklenebilir
Sonra Alice diğer kullanıcıları (Bob dışında) bilgilendiriyor

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
Sonra oyunun çözülüp çözülmediğini kontrol eder. Bu, yöneticilerin %50’inin Bob’u yasaklamaya razı olduğu anlamına gelir (tek başına ise, bu %50’den fazla olduğundan emin).
Eğer oylama çözülürse, dosyalar /votes/unban kaldırılabilir, Bob için tüm dosyalar / üyeleri, /admins, /invited, /CRLs, yeniden eklenebilir (veya sadece / cihazlar eğer yasaklanmamış bir cihazsa) ve repo’ya bağlı olabilir

Bir konuşmayı kaldır

Konuşmanın silinmesini ve diğer kullanıcıların cihazlarıyla senkronize edilmesini convInfos remove=time::now() (Contact silinmesi gibi)
Eğer bu konuşma için yeni bir söz verilirse, bu dinlenmez.
Jami’nin başlangıcı ve repo hala mevcutsa, konuşma müşterilere duyurulmaz.
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.
Birisinin senkronize edildiğinden emin olduğumuz zaman, silinmiş=time::now() kaldırın ve diğer kullanıcıların cihazlarıyla senkronize edin
Kullanıcıya ait tüm cihazlar artık deposu ve ilgili dosyaları silebilir

Modu nasıl belirlenebilir

Bu modlar zaman içinde değiştirilemez. ya da başka bir sohbet. Bu nedenle, bu veriler ilk commit mesajında depolanır. commit mesajı aşağıdaki gibi olacaktır:

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

Şimdilik “mod” değerleri kabul eder 0 (ONE_TO_ONE), 1 (ADMIN_INVITES_ONLY), 2 (INVITES_ONLY), 3 (PUBLIC)

Processes for 1:1 swarms

Buradaki amaç, eski API’nin (addContact/removeContact, sendTrustRequest/acceptTrustRequest/discardTrustRequest) bir eş ve onun bağlantısıyla swarm oluşturmasını sağlamak. Bu hala göz ardı edemeyeceğimiz bazı değişiklikleri ima ediyor:

Bu işlem hala aynıdır, bir hesap addContact üzerinden bir iletişim ekleyebilir, sonra DHT üzerinden bir güven talebi gönderebilir.

TrustRequest, çağrıyı kabul ederken hangi konuşmayı klonlaması gerektiğini eşlerine bildirmek için bir “conversationId” ekler.
TrustRequest, bağlantı çevrimiçi olduğunda tekrar deneniyor. Bu gün durum böyle değildir (eğer bir rekabet ilkini atarsa yeni bir TrustRequest oluşturmak istemeyiz). Bu nedenle, bir hesap güven talebi alırsa, ilgili bir konuşma ile ilgili bir talebi reddedilirse otomatik olarak göz ardı edilir (convRequests senkronize edildiği için)

Sonra, bir iletişim isteği kabul ettiğinde, bir senkronizasyon süresi gereklidir, çünkü iletişim artık konuşmayı klonlamalıdır.

removeContact() bağlantıyı ve ilgili 1:1 sohbetlerini (bir sohbet kaldırmak gibi aynı işlemle) kaldırır. Burada tek not, bir bağlantıyı yasaklarsak senkronize beklemiyoruz, tüm ilgili dosyaları kaldırıyoruz.

Zor senaryolar

Bazı durumlarda iki konuşma yapılabilir.

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

veya

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 1:1 swarm 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)).

Önemli

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() senkronize edilirse {{“sinkronlama”: “gerçek”}} gönderir.
ConfigurationManager::getConversationMembers() will return a map of two URIs (the current account and the peer who sent the request).

Konuşmalar, spesifikasyon talep ediyor

Konuşma istekleri aşağıdaki tuşlarla Map<String, String> ile temsil edilir:

id: the conversation ID
from: URI of the sender
Alındı: Zaman damgası
Başlık: (İsteğe bağlı) konuşma adı
Açıklama: (İsteğe bağlı)
Avatar: (İsteğe bağlı)

Konuşma profilini senkronize et

Bir konuşmanın tanımlanabilmesi için genellikle bir başlık (örneğin Jami), bir açıklama (örneğin: bazı bağlantılar, proje nedir vb.) ve bir görüntü (projenin logosu) gibi bazı metadata ihtiyaç vardır.

Depoda depolanmak

Konuşmanın profilleri, klasik bir vCard dosyasında kök (/profile.vcf) gibi saklanır:

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

Senkronizasyon

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

Son Gösterilen

Sinkronleşmiş verilerde, her cihaz diğer cihazlara konuşmaların durumunu gönderir. Bu durumda, son görüntülenen gönderilir. Ancak, her cihazın her konuşma için kendi durumuna sahip olabileceği ve muhtemelen aynı son commit olmadan bir noktada, dikkate alınması gereken birkaç senaryo vardır:

5 senaryo desteklenir:

Eğer diğer cihazlar tarafından gönderilen son görüntü mevcut olanla aynı ise, hiçbir şey yapılmaz.
Eğer mevcut cihaz için son görüntülenmemişse, uzaktan görüntülenen mesaj kullanılır.
Eğer son görüntülenen uzaktan mesafe repo’da bulunmazsa, commit daha sonra alınır demektir, bu yüzden sonuç önbelleğe alınır
Eğer uzaktan uzaktan ayarlanmışsa, son gösterilen yerel geçmişte daha önce olup olmadığını kontrol ederek değiştiririz.
Son olarak, aynı yazardan bir mesaj duyurulursa, son görüntülenmiş mesajı güncelleme ihtiyacımız olduğu anlamına gelir.

Tercihler

Her konuşmada kullanıcı tarafından belirlenen tercihler eklenmiştir. Bu tercihler kullanıcı cihazları arasında senkronize edilir. Bu, kullanıcı bildirimleri görmezden gelmek istiyorsa konuşmanın rengi olabilir, dosya transfer boyut sınırı vb.

“color” - the color of the conversation (#RRGGBB format)
“İgnoreNotifications” - bu konuşmada yeni mesajlar için bildirimleri görmezden gelmek
“simbol” - varsayılan bir emoji tanımlamak için.

Bu tercihler MapStringString paketinde depolanır, accountDir/conversation_data/conversationId/preferences’de depolanır ve yalnızca aynı kullanıcının cihazları arasında SyncMsg üzerinden gönderilmektedir.

Tercihleri etkileşime geçiren API’ler:

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

Birleştirme çatışmaları yönetimi

İki yöneticinin aynı anda açıklamayı değiştirebileceği için profile.vcf’de bir birleşme çatışması meydana gelebilir. Bu durumda, daha yüksek hash (örneğin ffffff > 000000) ile commit seçilir.

API’ler

Kullanıcı konuşmanın metadatalarını almak ve ayarlamak için 2 yöntem elde etti:

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

info aşağıdaki tuşlarla map<str, str>’dir:

Mod: Sadece okunur
başlık
Açıklama
avatar

Hesap yeniden ithal edilmesi (link/export)

Arşiv, yeniden ithalat edildikten sonra yeni commit’lerde konuşmaları geri alabilmek için conversationId içermelidir.

Konuşma orada, bu durumda, şeytan bu konuşmayı yeniden klonlayabilir.
KonuşmaId eksik, bu yüzden şeytan (eğitim {{"tapplikasyon/ davet", konuşmaId}}) kullanıcının (daha) kabul etmesi gereken yeni bir davet istiyor

Önemli

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

Kullanılan protokoller

Git

Neden bu seçimi

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

Mesajları senkronize etmek ve sipariş etmek zorundayız. Merkle Ağacı bunu yapmak için mükemmel bir yapı ve dalları birleştirerek doğrusal hale getirilebilir. Dahası, Git tarafından büyük ölçüde kullanıldığı için, cihazlar arasında senkronize etmek kolaydır.
Distributed by nature. Massively used. Lots of backends and pluggable.
Haklar ve büyük ölçüde kullanılan kripto aracılığıyla commits doğrulayabilir
Gerekirse bir veritabanında depolanır
Çatışmaların önlenmesi için dosyaları değil, commit mesajları kullanılır.

Neyi onaylamalıyız

Performans? git.lock düşük olabilir
Libgit2’de kaçaqlar
Aynı anda birden fazla çekim mi?

Sınırlar

Tarih silinemez. Bir konuşmayı silmek için cihaz konuşmayı terk edip başka bir konuşma oluşturmalıdır.

Bununla birlikte, kalıcı olmayan mesajlar (örneğin sadece birkaç dakika okunur mesajlar) DRT üzerinden özel bir mesaj (örneğin Yazma veya Oku bildirimleri) ile gönderilebilir.

Yapı

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

Dosya aktarımı

Swarm, dosya aktarımını büyük ölçüde değiştiriyor. Artık tüm geçmiş senkronize ediliyor ve görüşmedeki tüm cihazların eski dosyaları kolayca almasına olanak sağlanıyor. Bu değişiklikler, gönderenin, kendi cihazlarına bağlanmayı deneyerek dosyayı diğer cihazlara aktardığı bir mantıktan (Bu kötüydü çünkü bağlantı değişikliklerine/arızalarına karşı pek dirençli değildi ve manuel olarak yeniden denemeyi gerektiriyordu) gönderen diğer cihazların indirmesine izin verir. Ayrıca, dosyaya sahip olan herhangi bir cihaz, diğer cihazların ana bilgisayarı olabilir ve gönderen orada olmasa bile dosyaların alınmasına olanak tanır.

Protokol

Gönder, sohbette aşağıdaki biçimle yeni bir commit ekler:

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

ve ${data_path}/conversation_data/${conversation_id}/${file_id}’de bir bağlantı oluşturur.

Ardından, alıcı şimdi dosyayı barındıran cihazlarla iletişim kurarak dosyayı indirerek name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId ile bir kanal açabilir ve dosyanın beklediği bilgiyi ${data_path}/conversation_data/${conversation_id}/waiting

Bağlantıyı alan cihaz, dosyanın gönderilebileceğini doğrulayarak kanalı kabul eder (sha3sum doğruysa ve dosya varsa). Alıcı ilk açılan kanalı tutar, diğerlerini kapatır ve gelen tüm verileri bir dosyaya yazar (yurtananla aynı yolla: ${data_path}/conversation_data/${conversation_id}/${file_id}).

Transfer tamamlandığında veya kanal kapatıldığında, dosyanın doğru olduğunu doğrulamak için sha3sum doğrulanır (ya da silinir). Eğer geçerli ise, dosya bekleme sırasında silinecektir.

Başarısızlık durumunda, konuşmanın bir cihazı tekrar çevrimiçi olduğunda, tüm bekleme dosyalarını aynı şekilde isteyeceğiz.

Call in swarm

Fikir

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

“accountUri/deviceId/conversationId/confId” hesabUri/deviceId’in barındırmayı tanımladığı yer.

Ev sahibi iki şekilde belirlenebilir:

In the swarm metadatas. Where it’s stored like the title/desc/avatar of the room
Ya da ilk arayan.

Bir çağrı başlatıldığında, ev sahibi, URI’yi (accountUri/deviceId/conversationId/confId) ile birlikte, bir yeni commit ekleyecektir. Bu çağrı sona kadar geçerlidir (gelişme süreyi göstermek için bir commit tarafından duyurulur).

Böylece her birim bir çağrı başladığı bilgileri alacak ve çağrı yaparak ona katılabilecek.

Saldırı mı?

Avoid Git bombs

Notlar

Bir commit’in zaman damgasına güvenebilirsiniz çünkü düzenlenebilir. Sadece kullanıcının zaman damgasına güvenebilirsiniz.

TLS

Git işlemleri, kontrol mesajları, dosyalar ve diğer şeyler, PFS’i garanti eden sadece şifre ile p2p TLS v1.3 bağlantısını kullanacak.

DHT (UDP)

Cep telefonları için mesaj göndermek (push bildirimlerini tetiklemek) ve TCP bağlantıları başlatmak için kullanılır.

Ağ faaliyeti

Birini davet etme süreci

Alice Bob’u davet etmek istiyor:

Alice konuşmaya Bob’u ekliyor.
Alice generates an invite: { “application/invite+json” : { “conversationId”: “$id”, “members”: [{…}] }}
Mesajı göndermek için iki olasılık a. Eğer bağlantılı değilse, DHT b. Yoksa Alice SIP kanalı üzerinden gönderir
Bob için iki olasılık a. davet alıyor, bir sinyal gönderilir istemci b. Bağlı değil, bu yüzden asla isteği almayacak çünkü Alice Bob’un Alice’i görmezden geldiğini veya engellediğini bilmemesi gerekir. Tek yol yeni bir mesaj aracılığıyla yeni bir davet yeniden üretmektir (bakınız sonraki senaryo)

Birine mesaj gönderme süreci

Alice Bob’a bir mesaj göndermek istiyor:

Alice, repo’ya bir mesaj ekliyor, kimlik veriyor.
Alice başarılı olursa bir mesaj alır
İki olasılık, Alice ve Bob bağlantılı veya bağlantılı değil. Her iki durumda da bir mesaj oluşturulur: { “application/im-gitmessage-id” : “{“id”:”$convId", "commit":"$commitId”, “deviceId”: “$alice_device_hash”}”}.
Bob için dört olasılık: a. Bob Alice’e bağlanmamıştır, bu yüzden Alice’e güvenirse, yeni bir bağlantı isteyin ve b. b’ye gidin. Eğer bağlanmışsa, Alice’den getir ve yeni mesajlar duyurun. c. Bob bu konuşmayı bilmiyor.

Uygulama

Şekil: Swarm sohbet dersleri

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

Çağrılar

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

!! Eski taslak!!

Not

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

Kripto gelişmeleri.

Ciddi bir grup sohbet özelliği için, ciddi kripto da gerekir. mevcut tasarımla, bir konuşmanın önceki DHT değerleri olarak bir sertifika çalındığında, konuşma şifreli hale gelebilir. Belki de ** Double ratchet** gibi bir şeye gitmemiz gerekir.

Not

A lib might exist to implement group conversations.

OpenDHT’de ECC desteğine ihtiyaç duyuyor

Kullanım

Roller ekle?

Grup sohbetleri için iki önemli kullanım alanı vardır:

Özel kanallar ve bazı roller (admin/seyirci/bot/b.d.) veya eğitim için (sadece birkaç kişinin aktif olduğu) bir şirkette bir Mattermost gibi bir şey.
Düzsel konuşmalar arkadaşlar arasındaki konuşma gibi.

Jami will be for which one?

Uygulama fikri

Bir rol için bayraklı bir kullanıcı imzalayan bir grup için bir sertifika.

Bir sohbete katılın.

Sadece doğrudan davet yoluyla
Bağlantı/QR kodu/her ne olursa olsun
Bir oda adı ile mi?

Neye ihtiyacımız var

Gizlilik: grup sohbetinden dışındaki üyeleri gruptaki mesajları okuyamamalıdır
Önceki gizlilik: Eğer gruptan herhangi bir anahtar tehlikeye girerse, önceki mesajlar gizli kalmalıdır (mümkün olduğunca)
Mesaj düzenlemesi: Mesajların doğru sırada olması gerekir
Senkronizasyon: Tüm mesajların mümkün olduğunca kısa sürede ulaştığını da emin olmak gerekir.
Persistence: Actually, a message on the DHT lives only 10 minutes. Because it’s the best timing calculated for this kind of DHT. To persist data, the node must re-put the value on the DHT every 10 minutes. Another way to do when the node is offline is to let nodes re-put the data. But, if after 10 minutes, 8 nodes are still here, they will do 64 requests (and it’s exponential). The current way to avoid spamming for that is queried. This will still do 64 requests but limit the max redundancy to 8 nodes.

Diğer dağıtılı yollar

IPFS: Biraz soruşturma gerekiyor
Biraz soruşturma lazım.
Biraz soruşturma lazım.

Şu anda yaptığımız işlere dayanarak

Grup sohbetleri, çoklu cihazlar için zaten yaptığımız aynı çalışmaya dayanarak yapılabilir.

Bu veri tabanını istemciden daemon’a taşıyor.
Eğer kimse bağlanmıyorsa senkronizasyon yapılmaz ve kişi konuşmayı asla görmez.

Başka bir özel DHT

Bir DHT’nin süper kullanıcısı gibi.

Dosya aktarımı

Dosya aktarım algoritması şu anda bir TURN bağlantısına (Doku Dosya aktarımı) dayanmaktadır. Büyük bir grup durumunda bu kötü olacaktır. Önce dosya aktarımı için p2p uygulaması gerekir. p2p aktarımı için RFC uygulamasını uygulayın.

Diğer bir sorun: şu anda PJSIP’de ICE için TCP desteği uygulanmıyor. Bu noktada zorunludur (pjsip veya ev yapımı)

Kaynaklar

Bu sayede, bu sayede bir diğer ürün de elde edilebilir.
Ağlı çizgisi sistemlerin, geçici bilgi ile sağlam dağıtılmış senkronizasyonu (Sean Phillips ve Ricardo G.Sanfelice)