Great question. The beauty of Nostr is that is so simple, it is basically only NIP-01, so any change must keep that in mind. Going by parts:
1) kind 2: recommend_server. This seems to be an optional feature, and optional features are bad to begin with in any spec (imo).
This one seems not to have a good chance to be "correctly" implemented.
If a relay is behaving good or badly, we can just advertize that in the community?
No need to be written in spec. And if no one uses it, then yes, get rid of it (that's the first thing I do when a function
is depecretated, remove it from the code base).
2) NIP-12. when adding new features to a spec, we should ask. What are the pros and cons? Does it make the spec more complex?
With complexity, we loose adopters. But by adding useful but not essentially required features to a functional spec, we gain
adopters. So, it's a trade-off. In this case, NIP-12 seems to have *very* good use cases, like the
#g ("geohash") tag to associate a post with a physical location (See Leaflet of Google Maps). Maye an alternative in the middle between
putting this NIP and others into the main NIP and leaving it alone, could be to do a "Core NIPS" or "Top 5" kind of thing. Don't know.
3) NIP-20. This one seems super important too, an acknowledgement reponse (just noticed that is not required in Nostr).
I think most Internet protocols, like HTTP or FTP, have a response built in, which seems critical in life saving missions
or money transactions (but not posting cat pictues to a relay). So, same answer as 2) , either in main NIP or "top 3".
** Inserting an idea for NIP-01 here **. Add a boolean key/pair "response": true/false that says , I do require a response or not. This
fits nicely into JSON, boolean types (it seems Nostr has none) . Is this a good idea? If yes, I'll write a proposed change to NIP-01.
4) NIP-16 replaceable events. Maybe not a Top one, don't know.
Pedro Vicente
npub1f6…uaq28
2023-07-18 00:34:28
in reply to nevent1q…nujf
Author Public Key
npub1f65y84223ldt8x4ytaslr8el77wvryu9xu8k5fedm2ql4hs2q54s7uaq28Published at
2023-07-18 00:34:28Event JSON
{
"id": "aa678a3d55c0f420e34726670d91a17280481df8206a39dff22e17c0e9001ebb",
"pubkey": "4ea843d54a8fdab39aa45f61f19f3ff79cc19385370f6a272dda81fade0a052b",
"created_at": 1689640468,
"kind": 1,
"tags": [
[
"e",
"2254a246760fbf36ae108791768ab1cbbaafbf2e1059c3b25b08ab3afc6eebe0"
],
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
],
[
"t",
"g"
]
],
"content": "Great question. The beauty of Nostr is that is so simple, it is basically only NIP-01, so any change must keep that in mind. Going by parts:\n1) kind 2: recommend_server. This seems to be an optional feature, and optional features are bad to begin with in any spec (imo). \nThis one seems not to have a good chance to be \"correctly\" implemented. \nIf a relay is behaving good or badly, we can just advertize that in the community?\nNo need to be written in spec. And if no one uses it, then yes, get rid of it (that's the first thing I do when a function\nis depecretated, remove it from the code base). \n\n2) NIP-12. when adding new features to a spec, we should ask. What are the pros and cons? Does it make the spec more complex? \nWith complexity, we loose adopters. But by adding useful but not essentially required features to a functional spec, we gain\nadopters. So, it's a trade-off. In this case, NIP-12 seems to have *very* good use cases, like the \n#g (\"geohash\") tag to associate a post with a physical location (See Leaflet of Google Maps). Maye an alternative in the middle between\nputting this NIP and others into the main NIP and leaving it alone, could be to do a \"Core NIPS\" or \"Top 5\" kind of thing. Don't know. \n\n3) NIP-20. This one seems super important too, an acknowledgement reponse (just noticed that is not required in Nostr).\nI think most Internet protocols, like HTTP or FTP, have a response built in, which seems critical in life saving missions\nor money transactions (but not posting cat pictues to a relay). So, same answer as 2) , either in main NIP or \"top 3\". \n\n** Inserting an idea for NIP-01 here **. Add a boolean key/pair \"response\": true/false that says , I do require a response or not. This\nfits nicely into JSON, boolean types (it seems Nostr has none) . Is this a good idea? If yes, I'll write a proposed change to NIP-01. \n\n4) NIP-16 replaceable events. Maybe not a Top one, don't know.",
"sig": "cbe258577a25621698177d632e6d9d033fa0b5e2c7310f24e0447def0180016e34f1ee6ce6bba299d2cf40ec282218466b954091daa51db0e038acd8c62df540"
}