C-toxcore: 新しいポータブルでシンプルな標準のtox保存形式を作成します

さらに別の外部依存関係？ 大野！ お願いします！
単純なjsonライター/リーダーを作成するだけです。 また、クライアント間のメタデータ転送にも役立ちます。
そしてトリッキーな質問：他のクライアントによるこの強化をどのようにサポートしますか？ 私が知っているように、誰もTokTokを使用していません（Isotoxinはオリジナルとtoktokのコードを混合して独自のものを使用しています）

この形式は、クライアントがユーザー名、オンラインステータス、ステータスメッセージ、フレンドエイリアスのリストなどを保存できる単純なKey-Valueストアを提供する必要があると思います（＃112も参照）。 次に、クライアントの相互運用性を確保するために、いくつかの標準キーがTCSによって定義されます。

https://github.com/TokTok/c-toxcore/issues/112#issuecomment-257151226を投入し

@isotoxin攻撃/バグの表面を広げているだけなので、安全な通信の処理を担当するライブラリにJSONパーサーを実装しようとするのは間違っているようです。 たとえば、JSON構成が必要な場合は、JSONを処理する（およびJSONを_のみ_処理する）ことを目的とした、適切に保守されたライブラリにそれを延期することをお勧めします。 https://github.com/akheron/jansson/は、JSONの場合の理想的な候補のようです。 toxcoreと同じように移植性があり、組み込みプラットフォームにも適しています。

ドキュメントを読んだ後、私は現在のフォーマットがひどいものであり、死ななければならないことに同意します。

最小限のクライアントに実装するために必要なものを最小限に抑えるには、ファイルを2つの部分に分割する必要があると思います。

• 基本部分
• オプションパーツ

基本的な部分には、クライアント間で友人（未定）を単純な形式（おそらくバイナリ）で転送するための最小限のデータが含まれ、解析するために外部ライブラリを必要としないようにする必要があります。

オプションの部分は基本部分に追加され、JSON（またはその他）でエンコードされます。 前回オンラインでエイリアスなど、すべてのクライアントに必要ないくつかのキー...

議論。

JSON形式のアイデアは、（人間にとって）読みやすく、それ自体でクロスプラットフォームで安全であるため、気に入っています。 実際、追加の外部ライブラリが1つ必要ですが、少なくとも場合によっては、クライアントが同じライブラリを使用して、構成処理の独自の部分（構成のオプション部分）を処理できます。 また、おそらくリッチコンテンツを含むクロスプラットフォーム構成ファイルの処理が外部ライブラリ（JSON、msgpack、protobufなど）なしで行われる場合を考えるのに苦労しています。

toxsave形式には2つの部分が含まれる可能性があるというsudden6のアイデアが気に入っています。
基本的な部分-アカウントを機能させるために不可欠で絶対に必要なデータの部分がすべて含まれています（toxcoreによって実際に解釈される部分のみ）この基本的な部分は、新しいバージョンのtoxcoreが古いバージョンによって理解されない属性を持つことができるようにバージョン管理することもできます問題なく。

オプションのパーツ-クライアント固有の情報または物事を機能させるために必要とされないその他の情報を含めることができるパーツ。 このオプションの部分は、クライアントがtoxcoreに要求できるものです。 クライアントは、構成のこの部分に何かを格納するようにtoxcoreに要求することもできます。 オプションの構成のどの部分もtoxcoreによって解釈されるべきではありませんが、coreはそれを文字列としてクライアントに提供します。 クライアントはそれを好きなように扱うことができます。

JSON形式では、保存ファイルの暗号化は簡単です。 Toxcoreは、ユーザーが指定したパスワードで一般的に使用される対称暗号化アルゴリズムを使用して、保存ファイルを暗号化できます。 同時に、ユーザーが保存ファイルを暗号化したくない場合は暗号化は必要ありません。この場合、toxcoreは暗号化/復号化フェーズをスキップできます。

2部構成のアイデアのセキュリティについて。 configに2つの別個の部分が含まれる場合、toxcoreによって実際に解釈されるのは基本部分だけです。 この部分から、toxcoreはその内部構造へのすべての属性を読み取り、toxcoreが保存ファイルを保存するときにこの部分が構築されます。 保存ファイルのオプション部分については、toxcoreはクライアント用のgetおよびput関数のみを導入します。 これらの関数は、クライアントがオプションの構成パーツを取得して提供するために使用されます。 Toxcoreは、JSONライブラリ関連の関数をクライアント側に公開したり、オプションの部分を解釈しようとしたりしないでください。 ただし、toxcoreは、クライアントが無効な構成セクションを含めようとしているケースを検出するために、オプション部分のJSON構文を検証する必要があります。 私が正しければ、JSONの無効なセクションがあると、JSON構造全体が無効になります。 これはtoxcoreによって検出される必要があり、無効な包含を割り当ててはなりません。 JSONの構文検証は、非常に単純で安全であり、おそらくライブラリですでに利用可能である必要があります。

基本セクションとオプションセクションを含むJSON構成ファイルの長所と短所について考えてみましょう。
長所

• 人間が読める形式
• 動的なconfigをバージョン管理して、新しい属性が異なるバージョンのtoxcoreによって理解されない場合にスキップされるようにすることができます。
• シンプル（属性が明確に定義されている構成の少なくとも基本的な部分）
• 本質的にクロスプラットフォーム
• 一般的に使用される形式、多くの異なる言語で利用可能な多くのライブラリと実装。
• テキスト形式であるため、比較的サイズ効率が良い
• toxcoreは、必要に応じて、いつでも単純なバージョンの保存ファイルを保存できます。 その保存ファイルには、オプション部分のない構成の基本部分のみが含まれます。 （構成の肥大化を防ぎ、バージョンに依存しません）

短所

• 外部ライブラリが必要
• 基本およびオプションの分割により、セキュリティ上の懸念が生じます
• バイナリデータには非効率的です（友達のアバター？）
• クライアントが設定保存ファイルのオプション部分に必要なものを自由に含めることができる場合、大量の炭水化物になる可能性があります（長所->単純なバージョンの保存を参照）。
• toxcoreは構文を検証する必要がありますが、オプションの部分を解釈することはできません

結局のところ、私はtox保存ファイルのJSON形式のアイデアが好きです。 ただし、実装は慎重に行う必要があります。 もっと議論してください...

バイナリデータには非効率的です（友達のアバター？）

現在、IIRCアバターは* .toxファイルに保存されていません。そのため、構成ファイルに大量のデータを保存するのは非常に悪い考えだと思います。

基本およびオプションの分割により、セキュリティ上の懸念が生じます

どうして？

クライアントが設定保存ファイルのオプション部分に必要なものを自由に含めることができる場合、大量の炭水化物になる可能性があります（長所->単純なバージョンの保存を参照）。

うん、それは大きな問題に発展する可能性があります。

toxcoreは構文を検証する必要がありますが、オプションの部分を解釈することはできません

また、考えられる解決策は、クライアントが選択したライブラリを使用してJSON解析を処理し、適切な構成構造体/関数を使用してtoxcoreを初期化することです。 しかし、出力ファイルに互換性があることが保証されていないため、これが適切なアプローチであるかどうかはよくわかりません。

もう1つのアイデアは、「Tox Save File」の概念を廃止し、「ToxExportFile」を提供することです。 クライアントが起動するたびに保存ファイルからすべてを保存/ロードする代わりに、クライアントは自身のデータベース/保存ファイルからtoxcore操作に必要なデータをロードし、他のクライアントと交換するために指定された形式でデータをインポート/エクスポートする方法のみを提供しますクライアント。
長所

• より少ない設定ファイル
• パーサーライブラリへの強い依存関係はありません

短所

• すべてのクライアントがインポート/エクスポートを実装するという保証はありません

全体として、保存方法に取り組む前に、まずこのファイルに何を保存する

@ master-passeli

JSON形式では、保存ファイルの暗号化は簡単です。

データ形式に関係なく、暗号化/復号化は簡単です。

@ sadden6

また、考えられる解決策は、クライアントが選択したライブラリを使用してJSON解析を処理し、適切な構成構造体/関数を使用してtoxcoreを初期化することです。

エラー、いいえ、解決策ではありませんが、間違った方法で物事を行っています。

tox保存ファイルにアバターを保存するのは悪い考えかもしれませんが、アバターは単なる例であることに同意します。 現在、保存ファイルに保存したいバイナリデータは考えられませんが、将来的には保存する可能性があります。 将来を予測するのは少し難しいです。 :)

オプションパーツがクライアントが自由に追加できるものである場合、基本パーツとオプションパーツにはセキュリティ上の懸念があります。これにより、バグのあるクライアントが巧妙に作成されたデータやバグのあるデータを提供することで、toxコアを危険にさらす方法がいくつか開かれます。 クライアントによって追加されたパーツがtoxcoreによって解釈されないようにし、toxcoreがクライアントが含めたいパーツを構文的に検証することで、この可能性を最小限に抑えることができると信じています。

@ sadden6

つまり、クライアントは、toxcoreによってファイルに保存され、ファイルからロードされる独自の構成部分に対して、任意の解析方法を使用できるということです。 たとえば、Qtにはすでに独自のJSONパーサーがあると思うので、qToxには外部JSONパーサーは必要ありません。 また、クライアントが他の言語で記述されている場合は、ネイティブJSONパーサーを所有することができ、Cパーサーライブラリはそこで物事をより複雑にします。

クライアントが独自のエクスポートファイルを実装するという考えは好きではありません。 そうすることで、互換性のないエクスポートファイルが大量に発生し、混乱が生じるのではないかと心配しています。 これはtoxcoreの責任と機能である必要があります。

この種の基本的な部分とオプションの部分の分離がリスクが高すぎる場合でも、JSON形式に+1を付けます。 私はあまりにも多くのb * tXML構成またはバイナリ*の山を見てきました。