How being "flexible" can bloat a protocol
How being “flexible” can bloat a protocol
(A somewhat absurd example, but you’ll get the idea)
Iimagine some client decides to add support for a variant of nip05 that checks for values at /.well-known/nostr.yaml besides /.well-known/nostr.json. “Why not?”, they think, “I like YAML more than JSON, this can’t hurt anyone”.
Then some user makes a nip05 file in YAML and it will work on that client, they will think their file is good since it works on that client. When the user sees that other clients are not recognizing their YAML file, they will complain to the other client developers: “Hey, your client is broken, it is not supporting my YAML file!”.
The developer of the other client, astonished, replies: “Oh, I am sorry, I didn’t know that was part of the nip05 spec!”
The user, thinking it is doing a good thing, replies: “I don’t know, but it works on this other client here, see?”
Now the other client adds support. The cycle repeats now with more users making YAML files, more and more clients adding YAML support, for fear of providing a client that is incomplete or provides bad user experience.
The end result of this is that now nip05 extra-officially requires support for both JSON and YAML files. Every client must now check for /.well-known/nostr.yaml too besides just /.well-known/nostr.json, because a user’s key could be in either of these. A lot of work was wasted for nothing. And now, going forward, any new clients will require the double of work than before to implement.
Published at
2023-02-10 22:47:01Event JSON
{
"id": "d25463cc06f04ea8b653605c22e88320acc6486756f054404659b10f0dae6f6f",
"pubkey": "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
"created_at": 1676065621,
"kind": 30023,
"tags": [
[
"d",
"27598e6f"
],
[
"title",
"How being \"flexible\" can bloat a protocol"
],
[
"published_at",
"1676065620"
],
[
"t",
"nostr"
]
],
"content": "\n# How being \"flexible\" can bloat a protocol\n\n(A somewhat absurd example, but you'll get the idea)\n\nIimagine some client decides to add support for a variant of nip05 that checks for values at /.well-known/nostr.yaml besides /.well-known/nostr.json. \"Why not?\", they think, \"I like YAML more than JSON, this can't hurt anyone\".\n\nThen some user makes a nip05 file in YAML and it will work on that client, they will think their file is good since it works on that client. When the user sees that other clients are not recognizing their YAML file, they will complain to the other client developers: \"Hey, your client is broken, it is not supporting my YAML file!\".\n\nThe developer of the other client, astonished, replies: \"Oh, I am sorry, I didn't know that was part of the nip05 spec!\"\n\nThe user, thinking it is doing a good thing, replies: \"I don't know, but it works on this other client here, see?\"\n\nNow the other client adds support. The cycle repeats now with more users making YAML files, more and more clients adding YAML support, for fear of providing a client that is incomplete or provides bad user experience.\n\nThe end result of this is that now nip05 extra-officially requires support for both JSON and YAML files. Every client must now check for /.well-known/nostr.yaml too besides just /.well-known/nostr.json, because a user's key could be in either of these. A lot of work was wasted for nothing. And now, going forward, any new clients will require the double of work than before to implement.\n",
"sig": "3c016e660803835c1830029fe61178289ac4e492f0bfb3ad80ad68eff0ae503bf35c967e5da478c9a8c82102a42a236b18b72fe49405ffd123010a19f5b96d2a"
}
