今後、新しいクライアントを実装する場合、以前よりも2倍の作業が必要になるかもしれない理由。

JSONとYAML filesの違いは？

JSONとYAMLは、データを表現するための人間と機械の両方にとって読みやすいフォーマットです。しかし、いくつかの主要な違いがあります。

構文の違い:

JSONはJavaScript Object Notationの略で、JavaScriptのオブジェクト構文をベースにしています。一方、YAMLはYAML Ain't Markup Languageの略で、独自の構文を持っています。YAMLは、インデント、ハイフン、コロンなどの特殊な文字を使用して、リスト、マップ、スカラー値を表します。JSONは、中括弧、角括弧、コンマ、コロンなどの特殊な文字を使用して、オブジェクト、配列、スカラー値を表します。

データ表現の柔軟性:

YAMLは、JSONよりも柔軟で、複雑なデータ構造を表現することができます。例えば、YAMLは、複数行の文字列やブロックスタイルのリストなど、より高度な機能を提供します。

拡張性の違い:

JSONは、JavaScriptに基づいているため、JavaScriptに対してより適しています。一方、YAMLは、拡張性が高く、多言語で使用されるため、多くのプログラミング言語やツールに適しています。

読みやすさの違い:

YAMLは、可読性が高く、コードのインデントによって構造を示すため、より読みやすいです。JSONは、構造が複雑になると、読みにくくなる傾向があります。

ファイルサイズの違い:

YAMLは、JSONよりも冗長であるため、同じデータを表現する場合、ファイルサイズが大きくなる可能性があります。

これらの違いにもかかわらず、どちらの形式を使用するかは、プロジェクトの要件と個人の好みによって異なります。

柔軟性がプロトコルを肥大化させるということ

(やや無茶な例ですが、お分かりいただけると思います)

あるクライアントが、/.well-known/nostr.jsonの他に/.well-known/nostr.yamlの値をチェックするnip05の変種のサポートを追加しようと決めたとします。「JSONよりもYAMLの方が好きだし、誰も損しないだろう」と考えたとします。

あるユーザーがYAMLでnip05ファイルを作成し、それがそのクライアントで動作した場合、そのクライアントで動作するのだから自分のファイルは良いものだと思うでしょう。他のクライアントが自分のYAMLファイルを認識しないのを見たとき、そのユーザーは他のクライアントの開発者に文句を言うでしょう。「おい、お前のクライアントは壊れている、私のYAMLファイルをサポートしていない！」。

もう一方のクライアントの開発者は、驚いてこう答えます。"ああ、すみません、それがnip05の仕様の一部だとは知りませんでした！"

いいことをしていると思ったユーザーは、こう答えます。"よくわからないけど、この他のクライアントではうまくいっているんだ、わかる？"

今度は、他のクライアントがサポートを追加する。このサイクルは、より多くのユーザーがYAMLファイルを作成し、より多くのクライアントがYAMLサポートを追加するという形で繰り返されています。

この結果、nip05はJSONファイルとYAMLファイルの両方をサポートすることを公式に要求することになりました。ユーザの鍵はこのどちらにもある可能性があるため、すべてのクライアントは /.well-known/nostr.json だけでなく /.well-known/nostr.yaml もチェックしなければならなくなりました。多くの作業が無駄になりました。そして今、今後、新しいクライアントを実装する場合、以前よりも2倍の作業が必要になります。

#[0]