isn't that something the relays shouldn't accept either?

For all the people who are eager to reply that Nostr should be able to handle bad practices otherwise it is already dead, or to say that "please" won't work, or these sort of comments, I must tell you that Nostr is not "antifragile", it is indeed very fragile, as all open protocols (including Bitcoin).

Although Nostr is much more fragile than Bitcoin, specially while it is small. Hopefully, while it is small, I do expect that "please" and civil discussions will work, as most people here want Nostr to succeed, and keeping it simple will increase these chances.

error fetching invoice

🫱🏼‍🫲🏽

Your article doesn’t really capture how bad it gets. It assumes good intent - but there is an adversarial scenario that comes about the same way. I have bad memories from the browser wars, where ms did the same thing with IE. The problem is you need one well funded party with malintent to cause convergence on the client and pass the overhead on to others who simply can’t keep up. We have to protect the protocol and adherence as religiously as bitcoin.

More examples are: kind:0 metadata fields. relay formats, REQ limits and options, and relay URL formats.

It may be time for us to create a NIP working group whose task it is to evaluate all the NIP PRs, accept or deny them, and communicate to client devs in some more organized fashion.

>From: fiatjaf at 03/12/23 06:42:43 on wss://relay.nostriches.org

>---------------

>Please do not accept invalid events in your client. Do not accept non-integer "created_at" values, do not accept non-string-array on "tags", do not accept bech32-encoded keys as tag values. Every time you do that, Nostr dies a little.

>For more information on how this kills Nostr, read https://fiatjaf.com/27598e6f.html

The question is? How to drop events? I'm not quite sure, I'll check, if there is such a thing in nostr-relay-rs.

Maybe there should be a nostr-core, like bitcoin core, with the recent accepted consensus.

I queried many relays and found that some tags were stored with incompatible pub keys either because they were stored as bech32 or because they were just wrong. I didn’t know it would be a problem like that but I was surprised that this was happening

Agree, the Internet was built on the premise of: be liberal with what you receive, and conservative with what you send.

Having test vectors people can easily test against and maybe a more machine readable spec (e.g. JSON schema) would help with that. My experience with Nostr and LNURL has been one of reverse-engineering and trying to understand the author's intentions so far (human language sucks for specs).

There's only so much time people spend on spec compliance if it works(tm), being compliant should be the easiest path to "it works".

In some cases, the spec really needs to be more clear. https://github.com/nostr-protocol/nips/issues/354 #nostr

#[0]

It's not so fun when you just want to type plaintext but random clients absolutely want to imagine it's markdown and completely butcher your note. I'd be mostly fine with it if they'd stick to only modifying the style and not the text itself. Cf. #[2]

Idea: Relay that only serves events that are slightly corrupted in different ways, if your client accepts any of them, it's broken

#[0]

今後、新しいクライアントを実装する場合、以前よりも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]