群れ

シンオスピス

この文書の目的は,Jamiでグループチャット (swarm chat**) がどのように実施されるかを説明することです.

swarmは,中心的な権威なしに,柔軟な方法で議論できるグループです.実際,もし2人がグループ内の他の部分と接続がない (インターネット断電) が互いの連絡をとることができる場合 (例えばLANまたはサブネットワーク) は,互いにメッセージを送信することができ,可能な限りグループ内の他の部分と同期することができます.

群れは以下のように定義されます

接続をフォローして分割・合併する能力
記録を同期する誰でもグループ全体にメッセージを送れるはずです
サーバーに頼るわけにはいかない
古いメッセージの有効性を確認し,全履歴を再現できる必要があります.
輸送機のPFS 保存装置によって管理されます

メインアイデアは参加者とのマークルツリーを同期することです

群れチャット用の4つのモードを特定しました

友達と話すときのケースです
ADMIN_INVITES_ONLY 一般的に教師が人を招待できるクラスですが,生徒は招待できない
** 友達を私的なグループに招待するだけ**
公衆基本的にオープンなフォーラム

シナリオ

群れを作れ

ボブは新しい群れを作りたい

ボブは地元のギットリポジトリを作成します
その後,彼は次の署名による最初のコミットメントを作成します
- /admins の公钥
- 装置証明書 ̀ /デバイス`
- /crls` のCRL
最初のコンタクトのハッシュは会話のIDになります
ボブは他のデバイスに新しい会話が作成されると告げる.これはDHTを通じて送信された他のデバイスにそのアカウントに接続された群れに加わるよう招待状を通じて行われる.

誰かを追加する

♪アリスはボブを添加する♪

アリスはボブをレポに追加します
- /invited で招待された URI を追加する
- /crls にCRLを追加する
アリスはDHTの要求を送信

招待状を受け入れる

アリスは以前作った群れに加わるよう招待された

彼女は招待状を受け入れて (拒否するなら,何もしない,それは招待状に残る,そしてアリスは決してメッセージを受け取らない)
アリスとボブとの間のピアツーピア接続が完了しました
アリスはボブのリポを引っ張ります. これはメッセージが接続が必要であることを意味します.
アリスはボブから約束を検証
アリスが会員であることを確認するために,彼女は招待状を /invitedディレクトリから削除し,その後に証明書を /membersディレクトリに追加します
すべてのコミットメントが検証され,彼女のデバイスに載ると,グループの他のメンバーがアリスによって発見されます. これらの同級者と一緒に,彼女はボブをブートストラップとしてDRT (以下説明) を構築します.

メッセージを送る

アリスがメッセージを送った

アリスは以下の形式でコミットメッセージを書きます.

TODO形式不明

合併衝突は,主にファイルではなく,コミットメッセージに基づいているため回避されます (CRLS+証明書が存在しない場合を除く).その後,彼女はサービスメッセージ (後で説明される) で DRTを通じて新しいコミットを発表し,モバイルデバイスにDHTをピンします (彼らはプッシュ通知を受け取らなければならない).

他のデバイスをピンする場合は,送信者は他のメンバーに,メッセージを送信する"deviceId",関連する会話の"id"および"commit"を含むJSONを含む"application/im-gitmessage-id"をミメタイプ ="application/im-gitmessage-id"でSIPメッセージを送信します.

メッセージを受け取る

♪ボブはアリスからメッセージを受け取った♪

ボブがアリスに手を伸ばす
約束はハックで確認されなければならない
メッセージは,すべてのコンビットが有効である場合,コンビットが保存され表示されます.その後,Bobは他のデバイスに DRTを通じてメッセージを発表します.
引き出はキャンセルされます. アリスは状態を正常に回復する必要があります.

コミットメントの検証

ユーザが不必要なコンビット (紛争,偽メッセージなど) を押し付けないようにするために,各コンビット (古いから新しいまで) は,リモートブランチを統合する前に,このように検証する必要があります.

注:検証が失敗すると,取取は無視され,分子を合併しない (データを取り除く) と,ユーザに通知される注2:取は大きすぎると,完成しない (TODO)

各コミットについては,コミットを送信しようとするデバイスが現在承認されていること,証明書が存在していること (デバイスの/デバイス,および発行者の/メンバーまたは/管理者) を確認してください.
合併は,再確認できない
初期設定は 0 の親を持つ
- 管理者証明書が追加されているか確認
- デバイス証明書が追加されていることを確認する
- チェックCRL追加
- 他のファイルが追加されていないことを確認する
メッセージは JSON で,タイプがあります.
- テキスト (またはファイルを変更しない他のミームタイプ)
  - 証明書から確認された署名
  - デバイスの証明書の外に奇妙なファイルが追加されず削除されていないことを確認します
- 投票するなら
  - voteTypeがサポートされているか確認する (禁止,解除)
  - 署名するユーザーに投票が与えられているか確認する
  - 投票は管理者やデバイスから来たか確認し,禁止されていない
  - 変なファイルが追加されず削除されていないことを確認する
- メンバー
  - 追加する
    - 約束が正しく署名されているか確認
    - 証明書が追加されているか確認する
    - 変なファイルが追加されず削除されていないことを確認する
    - 管理者,メンバーが1人だけ
    - ADMIN_INVITES_ONLY では,招待は管理者から来たことを確認します
  - 加入した場合
    - 約束が正しく署名されているか確認
    - デバイスが追加されていることを確認する
    - 招待状が会員に転送されているか確認
    - 変なファイルが追加されず削除されていないことを確認する
  - 禁止された場合
    - 投票が有効かどうかを確認する
    - 管理者によるユーザの禁止を確認
    - メンバーまたはデバイスの証明書は禁止に移動されているか確認してください.
    - 投票に関連するファイルのみ削除されていることを確認します
    - 変なファイルが追加されず削除されていないことを確認する
- ユーザは古いバージョンでいるかもしれないと通知し,またはそのピアが不必要なコミットを送信しようとした

装置を禁止する

アリス,ボブ,カーラ,デニスが群れだアリスはデニスを禁止してる

これは我々の状況において最も難しいシナリオの一つです中央権力がなければ信頼できないのです

作成されたコミットメントのタイムスタンプ
禁止されたデバイスとの衝突.複数の管理器が存在し,アリスがボブと話すことができても,デニスとカルラとは言えない場合.カーラがデニスと話すことができる場合.デニスがアリスを禁止し,アリスはデニスを禁止します.4人のメンバーが会話を統合するときに,状態はどのようなものになるのでしょうか.
デバイスが侵害され,盗まれ,証明書が期限切れになる可能性があります. デバイスを禁止し,その期限切れについて嘘をつかず,過去のメッセージを送信することを避ける必要があります (証明書またはコミットのタイムスタンプを変更することによって).

類似したシステム (分散型グループシステム) はあまりないが,以下はいくつかの例です.

[mpOTRは誰かを禁止する方法を定義していない]
グループチャット用の中央サーバーがないため (EDIT:最近その点を変更しました) グループから誰かを禁止する機能は与えません

この投票システムには,人を禁止する人間の行動が必要か,または,リポジトリからCRLの情報に基づいてなければならない (我々は外部CRLを信用できないからです)

会話からデバイスを削除する

議論の分裂を避けるために合意が必要とする唯一の部分です例えば2人のメンバーが会話から互いを蹴った場合第三者はどうでしょう

削除されたデバイスを検出するために,または公共の部屋に不必要な人が登場するのを避けるために必要なものです.メンバーとデバイスの間のプロセスはかなり類似しています.

♪アリスがボブを連れ去る ♪

投票するにはアリスは管理者にならなければなりません

投票はボブを禁止する.そのために,彼女はファイルを /votes/ban/members/uri_bob/uri_alice (メンバーはデバイスのためのデバイスに置き換えることができる,または招待状や管理者への招待状に招待される) で作成し,
投票が決まったかどうかを確認します. これは,管理者の50%以上がボブを禁止することに同意していることを意味します (彼女が一人なら,それは50%以上です).
投票が解決された場合, /votes/ban のファイルは削除され, /members, /admins, /invited, /CRL, /device の Bob のすべてのファイルは削除され (または禁止されたデバイスの場合のみ /device で) そして, Bob の証明書は /banned/members/bob_uri.crt に置き, repo に委託され,
その後,アリスは他のユーザーに (ボブ以外)

*アリス (管理者) はボブ (禁止メンバー) を追加しました

投票してボブを禁止する.そのために,彼女はファイルを /votes/unban/members/uri_bob/uri_alice (メンバーはデバイスのためのデバイスに置き換えることができる,または招待状や管理者へのアドミンのために招待される) で作成し,
投票が決まったかどうかを確認します. これは,管理者の50%以上がボブを禁止することに同意していることを意味します (彼女が一人なら,それは50%以上です).
投票が解決された場合, /votes/unban のファイルは削除され, /members, /admins, /invited, /CRL の Bob のすべてのファイルが,再添加され, /device にのみ追加され, repo にコミットされます.

話しを削除する

convInfos remove=time::now() で保存します (削除Contactは連絡先で保存します) 会話が削除され,他のユーザーのデバイスと同期されます
もしこの会話に新しい約束が受け取られたら無視される
ジュミがスタートアップしてレポがまだ存在しているなら顧客に会話が発表されない
2つのケース: a.会話で他のメンバーがいない場合は,リポジトリを直ちに削除できます b.他のメンバーがいる場合は,会話を終了することを約束し,少なくとも別のデバイスがこのメッセージを同期するのを待ってください.これは他のメンバーがまだ有効なメンバーとしてユーザーを検出し,新しいメッセージ通知を送信する事実を回避します.
確認すると,削除された=time::now() を削除し,他のユーザーのデバイスと同期します
ユーザー所有するすべてのデバイスは,現在,リポジトリと関連ファイルを削除することができます

モードを指定する方法

設定は変更できません.または別の会話です.このデータは最初のコミットメッセージに保存されます.

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

現在, "モード" は値 0 (ONE_TO_ONE), 1 (ADMIN_INVITES_ONLY), 2 (INVITES_ONLY), 3 (PUBLIC) を受け入れます

1:1スワームのプロセス

目標は,古いAPI (addContact/removeContact, sendTrustRequest/acceptTrustRequest/discardTrustRequest) を残して,ピアとその接触を群れに生成することです.これは,無視できないいくつかの変更を意味しています:

プロセスはまだ同じですアカウントは addContact で連絡先を追加し,DHT で TrustRequest を送信できます.しかし,二つの変更が必要になります.

TrustRequest は,要求を受け入れたときにどの会話をクローンするか,同級者に知らせる"会話Id"を組み込みます
TrustRequest は,連絡がオンラインに戻ると再試されます.今日ではそうではありません (同級者が最初の TrustRequest を捨てると新しい TrustRequest を生成したくないので).したがって,アカウントが信頼要求を受け取ると,関連する会話による要求が拒否された場合自動的に無視されます ( convRequests が同期されるので)

連絡先が要求を受け入れたらシンクロレーション期間が必要になります連絡先が会話をクローンする必要があるからです

連絡先を削除する (Contact) は,連絡先と関連した 1:1 会話 ("会話を削除する"と同じプロセスで) を削除します. ここで唯一注意するのは,連絡先を禁止した場合,同期を待つのではなく,関連するファイルすべて削除するということです.

難しいシナリオ

議論の2つの場面がある場合少なくとも2つのシナリオです

アリスはボブを添加する
ボブは受け入れます
アリスはボブを連れ去りました
アリスはボブを添加する

及び

1 アリスはボブとボブが同時にアリスを追加する,しかし両者は一緒に接続されていない

この場合は,2つの会話が生成されます.ユーザからのメッセージを削除したり,ここで1つの会話を選択したりはしません.したがって,時には同じメンバー間の2つの 1:1スワームが表示されます.移行期間にいくつかのバグを生成します (APIを壊したくないので,推論された会話は表示された2つの会話の1つになりますが,現在は"OK-ish"です.クライアントがすべてのAPI (コール,ファイル転送,など) の会話Idを完全に処理するときに修正されます).

シンクロレーション中に注意

通信の要求を受け入れた後,デモンがリモートリポジトリを回収する必要がある時期があります.この期間中に,クライアントはユーザーに情報を伝えるために同期表示を表示する必要があります.注意,同期中に:

ConfigurationManager::getConversations() は,同期中に会話のIDを返します
ConfigurationManager::conversationInfos() は,同期した場合, {{"同期": "真"}} を返します.
ConfigurationManager::getConversationMembers() は,2つのURIの地図を返します (現在のアカウントとリクエストを送信した同級者)

協議は仕様要求

会話の要求は,次のキーで Map<String,String> で表現されます.

id:会話 id
発送者の uri
受け取った: タイムスタンプ
タイトル: (オプション) 会話の名前
記述: (オプション)
アバター: (オプション)

会話のプロフィール同期

識別可能になるためには,会話は一般的にタイトル (例えば,Jami) や説明 (例えば,いくつかのリンク,プロジェクトとは何か,など) や画像 (プロジェクトのロゴ) などのようなメタデータが必要です.これらのメタデータはオプションであるが,すべてのメンバーと共有されるため,同期し,要求に組み込む必要があります.

倉庫の保存

会話のプロフィールは, vCardファイルで root (/profile.vcf) に保存されます.

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

シンクロニズ

vCardを更新するには,十分な権限を持つユーザ (デフォルトでは =ADMIN) が /profile.vcf.を編集し,ミメタイプの (application/update-profile) とファイルをコミットする.新しいメッセージは同じメカニズムを通じて送信され,すべての同級生はデモンからの MessageReceived信号を受け取る.commitは他のファイルを含んでいる場合,または大きすぎると,または未承認メンバーが実行した場合 (デフォルトでは: <ADMIN).

最後に表示

通信の状態は,通信の状態を他のデバイスに送信する.この状態では,最後の表示が送信されます.しかし,各デバイスは,それぞれの会話に対して独自の状態を持つことができるため,おそらく同じ最後のコミットを何らかの時点でせずに,いくつかのシナリオが考慮に入れる:

5つのシナリオがサポートされています.

他のデバイスから送信された最後の表示が現在のものと同じなら,何もできない.
現在のデバイスに最後の表示がない場合,リモート表示されたメッセージが使用されます.
削除されたリモコンがリポに表示されていない場合,commitが後で取得されるので,結果をキャッシュします.
移動したリモコンが既に取れた場合, 移動したリモコンが過去に表示されていることを確認します.
最後に同じ作者からのメッセージが発表されると, 最後に表示されたメッセージを更新する必要があるということです.

優先順位

ユーザーによって設定された好評がすべての会話に添付されています.これらの好評はユーザーのデバイスに同期されます.これは,ユーザーが通知を無視したい場合,ファイル転送サイズ制限などの場合,会話の色かもしれません.現在,認識されたキーは:

"color" - the color of the conversation (#RRGGBB format)
"無知通知" - この会話で新しいメッセージの通知を無視する
"シンボル" - デフォルトエモジを定義する

accountDir/conversation_data/conversationId/preferencesで保存され,同ユーザーのデバイスにSyncMsg を介してのみ送信されます.

優先順位と相互作用するAPIは:

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

合併紛争管理

profile.vcfでは2つの管理者が同時に記述を変更できるので,合併衝突が発生する.この場合,より高いハッシュ (例えば ffffff > 000000) を持つ commit が選択されます.

API

ユーザは会話のメタデータを入手し設定するための 2 つの方法を持っています:

       <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は,次のキーを持つ map<str,str>である.

モード: 読み込みのみ
タイトル
記述
アバター

口座を再輸入 (リンク/輸出)

ファイルは,再輸入後,新しいコンビットの会話を回収できるように,会話ID を含めなければならない (この時点で招待状はありません).

この会話は存在し,この場合,デモンはこの会話を再クローンすることができます
会話Id が欠落しているため,デモンは (メッセージ {{"アプリケーション/招待",会話Id}}) に新しい招待状を要求し,ユーザが (再) 受け入れなければならない

連絡先や他のデバイスが存在すれば会話が取り戻せるか忘れられるか

使用されたプロトコル

ゲート

なぜこの選択

議論はギットリポジトリになります. この選択は:

メッセージの同期と注文が必要です. メークルツリーはそのための完璧な構造であり,枝を合併することによって線性化できます. さらに,Gitで大量に使用されているため,デバイス間の同期が簡単です.
自然に配布され大量に使われバックエンドが多く
ハックや大量に使用された暗号を使ってコミットを確認できます
必要に応じてデータベースに保存できます
衝突はファイルではなくメッセージを入力することで回避されます

確認すべきことは

git.lockは低くなってしまいます
リビギット2のハック
複数の引き出しを同時に?

制限

履歴は削除できません. 会話を削除するには,デバイスは会話から離れ,別の会話を作成する必要があります.

しかし,非常時メッセージ (例えば数分しか読めないメッセージ) は,DRT (タイピングまたは読み書き通知) を介して特別なメッセージを通じて送信できます.

構造

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

ファイル転送

Swarm はファイル転送を大量に変更しています. 現在,すべての歴史は同期しており,会話中のすべてのデバイスが簡単に古いファイルを回収することができます.これらの変更は,送信者が他のデバイスでファイルを押しつけた論理から,デバイスに接続しようとすることで移動することを可能にします (これは接続の変更/失敗に本当に抵抗性がないため,手動リテージが必要でした).さらに,送信者が他のデバイスをダウンロードすることを許可する論理に.さらに,ファイルを持つデバイスは他のデバイスのホストとなり,送信者がいない場合でもファイルを取得することができます.

議定書

送信者は次の形式で会話に新しいコミットを追加します:

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

${data_path}/conversation_data/${conversation_id}/${file_id}でリンクを作成します.

その後,受信者は,ファイルをホストするデバイスに連絡して, name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileIdでチャネルを開いて,ファイルが待っているのかの情報を ${data_path}/conversation_data/${conversation_id}/waitingで保存できます.

接続を受け取るデバイスは,ファイルを送信できるかどうかを確認することによってチャンネルを受信します (sha3sumが正しいとファイルが存在している場合).受信者は最初の開いたチャンネルを保持し,他のチャンネルを閉じて,送信者と同じパスでファイルに書き込む (${data_path}/conversation_data/${conversation_id}/${file_id}) すべての受信データ.

転送が完了またはチャンネルが閉ざされたとき,ファイルが正しいかどうかを確認するためにsha3sumが確認されます (または削除されます).有効であれば,ファイルは待機から削除されます.

失敗の場合会話のデバイスが再びオンラインになると同じ方法で待ちファイルのすべてを要求します

群れを呼んで

名前サーバーの部分

発想

群れの会話には複数の rendez-vous が可能である. rendez-vous は以下の uri によって定義される.

"accountUri/deviceId/conversationId/confId"では,accountUri/deviceIdがホストを記述する.

ホストは次の2つの方法で決定できます

部屋のタイトル/デスク/アバターのように保存されている
初めの電話者でも

コール開始時に,ホストは,URIを加入する新しいコミットを追加します (accountUri/deviceId/conversationId/confId). これは,コール終了まで有効になります (表示される期間のあるコミットによって発表されます).

呼び出しが開始されたと連絡を受け取り呼び出しで加入することができます

攻撃?

爆弾を避ける

記号

設定のタイムスタンプは編集可能なので信頼できます. ユーザーのタイムスタンプだけが信頼できます.

TLS

Git操作,制御メッセージ,ファイル,その他のものは,P2p TLS v1.3 リンクを使用し,PFS を保証する暗号のみを使用します.したがって,各新しい接続のために各鍵が再交渉されます.

DHT (UDP)

携帯にメッセージを送信 (プッシュ通知を起動) や TCP 接続を開始するために使用されます.

ネットワーク活動

招待するプロセス

アリスはボブを招待したい

アリスはボブを会話に加え
Alice generates an invite: { "application/invite+json" : { "conversationId": "$id", "members": [{...}] }}
通信の2つの可能性 A.接続されていない場合,DHT b.別途,アリスはSIPチャンネルで送信
誘いを受信すると,クライアントに信号が発信される b.接続されていないので,決して誘いを受信しない.アリスは,ボブはアリスを無視したかどうかわからない必要があります.唯一の方法は,新しいメッセージを通じて新しい誘いを再生することです (次のシナリオ参照)

誰かにメッセージを送信するプロセス

アリスはボブにメッセージを送りたい

アリスはレポにメッセージを追加し,IDを表示します
アリスは成功した場合 (自分自身から) のメッセージを受け取る
アリスとボブが接続されているか否か.両例ではメッセージが作成されます. {"アプリケーション/im-gitmessage-id" : "{"id":"$convId", "コミット":"$commitId", "deviceId": "$alice_device_hash"}"}.
ボブには4つの可能性があります. a.ボブはアリスに接続していないので,アリスに信頼している場合は,新しい接続を頼んでbへ行きなさい.b.接続されている場合は,アリスから連絡を取り,新しいメッセージを発表してください. c.ボブはその会話を知らない.DHTを通じ最初に招待状を取得してその会話を受け入れるようにお願いします ({"アプリケーション/招待状",会話Id}) d.ボブは接続を断ち切っている (ネットワークがない,または単に閉鎖されている).彼は新しいメッセージを受け取らないが,次の接続が起こるときに同期しようとします

実施

図書: 群衆チャット教室

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

発信

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": "uri of the host",
    "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": "uri of the member",
    "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": "uri of the member",
    "action": "ban/unban"
}

!! 古いドラフト!!

注: 次の注記はまだ整理されていません.

暗号化改良

グループチャット機能では,重要な暗号も必要です.現在のデザインでは,会話の以前のDHT値として証明書が盗まれた場合,会話が解読されることがあります.

グループ会話の実行のためのリビーは存在するかもしれない

OpenDHTでECC支援が必要

使用

役を追加する?

グループチャットには 2つの主要な用途があります

企業におけるマターモストのようなもの, プライベートチャンネル, 特定の役割 (admin/spectator/bot/etc) または教育 (少数が活動している)
横向きな会話は友人の会話のように

Jami will be for which one?

実施アイデア

役割の旗でユーザーをサインするグループのための証明書.追加または撤回することもできます.

話し合いに参加する

直接招待のみ
リンク/QRコード/何であれ
部屋名で?

必要なもの

秘密主義:グループチャット以外のメンバーはグループ内のメッセージを読むことができない
秘密保持: グループからの鍵が侵害された場合,以前のメッセージは機密に保たれる (可能な限り)
メッセージの順序: メッセージの順序が正しい必要がある
通信を同期する: また,できるだけ早くすべてのメッセージが届くようにする必要があります.
持続性:実際には,DHT上のメッセージは10分しか続かない.この種のDHTのために計算された最高のタイミングであるため.データを維持するには,ノードは10分ごとにDHTの値を再設定する必要があります.ノードがオフラインであるときに行うもう一つの方法は,ノードがデータを再入力することを許すことです.しかし,10分後,8ノードがまだここにある場合は,64のリクエストを行います (それは指数値です).そのためのスパムを避ける現在の方法はクエリです.これはまだ64のリクエストを行いますが,最大冗長を8のノードに制限します.

他の分布式方式

IPFS: 調べる必要がある
調べる必要がある
捜査が必要

既存の作業に基づいて

グループチャットは,既に複数のデバイスで実施されている同じ作業に基づいたもの (しかし,ここでグループ証明書を使用します).

データベースをクライアントからデイモンに移動させる
接続ができない場合,同期は行われず,その人は会話を見ることができません

専用DHTの1つ

超ユーザの DHT みたいだ

ファイル転送

現在,ファイル転送アルゴリズムは TURN接続 (参照ファイル転送) に基づいています.大きなグループの場合,これは悪いでしょう. まずファイル転送のためにp2pインプルトメントが必要です.p2p転送のためにRFCを実装します.

他の問題:現在,PJSIPでICEのTCPサポートが実装されていない.この点 ( pjsipまたは自作) に必須です

資源

電子書籍の作成
ネットワーク化された線形システムの断続的な情報との強力な分散同期化 (Sean PhillipsとRicardo G.Sanfelice)

群れ

シンオスピス

シナリオ

群れを作れ

誰かを追加する

招待状 を 受け入れる

メッセージを送る

メッセージを受け取る

コミットメントの検証

装置を禁止する

会話からデバイスを削除する

話しを削除する

モードを指定する方法

1:1スワームのプロセス

難しいシナリオ

シンクロレーション中に注意

協議は仕様要求

会話のプロフィール同期

倉庫の保存

シンクロニズ

最後に表示

優先順位

合併紛争管理

API

口座を再輸入 (リンク/輸出)

使用されたプロトコル

ゲート

なぜこの選択

確認すべきことは

制限

構造

ファイル転送

議定書

群れを呼んで

名前サーバーの部分

発想

攻撃?

記号

TLS

DHT (UDP)

ネットワーク活動

招待するプロセス

誰かにメッセージを送信するプロセス

実施

Supported messages

Initial message

Text message

発信

Add a file

Updating profile

Member event

Vote event

暗号化改良

使用

役を追加する?

実施アイデア

話し合いに参加する

必要なもの

他の分布式方式

既存の作業に基づいて

専用DHTの1つ

ファイル転送

資源

招待状を受け入れる