C-toxcore: toxcoreからToxDNSおよび関連するものを削除します

@ tux3は、toxdnがなくなった場合、qToxを気にしますか？

qToxはHTTPSルックアップを使用しているため、問題はありません。

qToxがtoxdnsライブラリの使用を削除したときに削除します。

qToxはHTTPS「toxme」APIをサポートしているため、toxdns3サポートを問題なく削除できるはずです。
HTTPSシステムは、依然として同じ集中化と信頼の問題に悩まされています（キーピンニングをサポートしていないため、間違いなく悪化します）。利便性を犠牲にすることなく、安全に交換できることを嬉しく思います。

具体的には、アクティブに保守されているクライアントとライブラリがtoxdnを使用しなくなったときに、toxdnを削除します。 メンテナンスコストが非常に低いため、人のコードを壊さないようにすることができます。 利害関係者がtoxdnsに応じてアプリケーションが停止した場合にこのバグを書き込むとよいので、いつ削除できるかを知っています。

uToxでのHTTP [S]名ルックアップのサポートを作成する予定はありません。

そうは言っても、可能であれば、名前検索APIをtoxcoreに書き込む予定です。 そして、その機能と同時にuToxを開発します。 それが終わったら、uToxからDNS名のサポートをやめる予定です。

いいえ、名前の検索はtoxcoreで処理しないでください。

@GrayHatterなぜ、クライアントではなくtoxcoreがルックアップ機能を提供する必要があると思いますか？

名前の検索がDHTを活用し、完全に分散された方法で実行できる場合、それがtoxcoreに属する理由は明らかです。 ただし、toxcoreは、サーバー/サードパーティのサービスを扱うことの近くに行くべきではありません。

名前の検索はtoxcoreで処理すべきではないと彼が言ったとき、私は@ ovalseven8に同意します。 メッセンジャーがtoxcoreによって処理されるべきではないことに彼が同意する場合。

まず、アプリケーションとしてのメッセンジャーは使いやすいものである必要があります。
そして：ToxIDは使いやすいものではありません。
したがって、メッセンジャーはそれらを簡単にする必要があります。

単純な名前の検索/解決は、なじみのある便利なソリューションだと思います。

技術者以外の人に対処する場合、ルックアップはtoxにとって不可欠です。 特に電話でより多くの人にtoxを使用するように説得するには、電話番号/本-> toxidソリューションが必要です。 そうでなければ、私の家族や友人の誰もが切り替わります。
そしてそれをクライアントに任せることは悲惨な結果に終わるでしょう。