This is the most nuanced take I've seen on this subject yet.
First of all, yes, I agree github is not ideal and we should move NIPs elsewhere. But so far no one has stepped up to build a viable replacement, so for now we have to deal with the two-tier system through culture, by encouraging devs not to worry about things not getting merged. I personally have 10+ unmerged open PRs which are in varying levels of implementation in my stuff. Having them unmerged is 1. an invitation to collaborate, and 2. a signal that they're not adopted widely.
As far as lexicons go, when I was designing my own protocol that was the direction I was taking things. I'm still sympathetic to the idea, except for what you pointed out about control over the lexicon. Numeric identifiers are much better, because they're neutral — *if* we can get into a good habit of publicly signaling their use and adoption. That's not trivial of course, and points back to my first paragraph.
As far as specificity, the terseness and ambiguity is (I think) one of nostr's strengths. I could be wrong about this, because it basically goes against all the conventional wisdom of specification writing, so we'll see if it works out in practice. But specifying the minimum interoperability surface area allows there to be more flexibility in how a given data format can be used. This can lead to inconsistent UX, which is a problem but something devs are motivated to work through because it aligns with their interests, or it can lead to innovative new ideas. In either case though, it forces devs to be more conservative about how they treat events, encouraging defensive coding (in case of deliberately malformed events as an attack) and wider interoperability. This is an adaptive approach rather than a validate-and-throw-away approach.
hodlbod /
npub1jl…jynqn
2025-03-27 18:23:30
in reply to nevent1q…wcmw
Author Public Key
npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqnPublished at
2025-03-27 18:23:30Event JSON
{
"id": "59ffb56bd1f14a304935046206236494e981b91482af8bfe785a01e22d8983d0",
"pubkey": "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322",
"created_at": 1743099810,
"kind": 1,
"tags": [
[
"p",
"b90c3cb71d66343e01104d5c9adf7db05d36653b17601ff9b2eebaa81be67823",
"wss://nos.lol/",
"JoeRuelle"
],
[
"e",
"366fe02bd10911c59b7eb9e6adc4c96e17e7c0b44f23b30fa8f72ed3cd067334",
"wss://relay.nostr.band/",
"root",
"b90c3cb71d66343e01104d5c9adf7db05d36653b17601ff9b2eebaa81be67823"
],
[
"client",
"Coracle",
"31990:97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322:1685968093690"
]
],
"content": "This is the most nuanced take I've seen on this subject yet.\n\nFirst of all, yes, I agree github is not ideal and we should move NIPs elsewhere. But so far no one has stepped up to build a viable replacement, so for now we have to deal with the two-tier system through culture, by encouraging devs not to worry about things not getting merged. I personally have 10+ unmerged open PRs which are in varying levels of implementation in my stuff. Having them unmerged is 1. an invitation to collaborate, and 2. a signal that they're not adopted widely.\n\nAs far as lexicons go, when I was designing my own protocol that was the direction I was taking things. I'm still sympathetic to the idea, except for what you pointed out about control over the lexicon. Numeric identifiers are much better, because they're neutral — *if* we can get into a good habit of publicly signaling their use and adoption. That's not trivial of course, and points back to my first paragraph.\n\nAs far as specificity, the terseness and ambiguity is (I think) one of nostr's strengths. I could be wrong about this, because it basically goes against all the conventional wisdom of specification writing, so we'll see if it works out in practice. But specifying the minimum interoperability surface area allows there to be more flexibility in how a given data format can be used. This can lead to inconsistent UX, which is a problem but something devs are motivated to work through because it aligns with their interests, or it can lead to innovative new ideas. In either case though, it forces devs to be more conservative about how they treat events, encouraging defensive coding (in case of deliberately malformed events as an attack) and wider interoperability. This is an adaptive approach rather than a validate-and-throw-away approach.",
"sig": "eb232a99f51f9ffbbdc708391a6778feabed00c53e0379000d5ca31768e7f54c6c8e46e2d02d7906fe8d78993949398bb56e7d1179b26e670ec7a0a23c5cad93"
}