Pedro Vicente on Nostr: Great question. The beauty of Nostr is that is so simple, it is basically only ...
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.
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.