I like this very much.
One thing I’ve found is that NIP-XX can have multiple different, or partial implementations. How might we capture this?
what if... (and you probably know what I'm going to say...)
we publish these features on nostr.
Say for example I add "pin-note" support to nostr:npub1w0rthyjyp2f5gful0gm2500pwyxfrx93a85289xdz0sd6hyef33sh2cu4x
I publish a new event kind tagging my NIP-89 entry of Highlighter. Thus I signal that Highlighter supports that feature.
That way, say for example I later add "mute-list" support; I could just publish the event.
There is NO WAY someone, not even nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5 , will be able to keep up with all the clients and all the features we are all constantly pushing.
But we can push it to the edges, me as a developer, it is basically no extra work to publish an event indicating the new feature when I cut a new version.
Discussion
yeah, that's why I didn't go with "NIP", because some nips are quite broad, e.g. if you say you support nip-51, what does that mean? *all* the kinds nip-51 defines?
instead a simple "mute list" feature flag would be more precise
the main problem with this idea would be standardizing around names, e.g. "mute list" vs "mute-list", but we can easily normalize this like we did for the wiki nip.
and ultimately developers can take a very simple quick look to see how other developers spelled "mute list"
So we would:
1) have a pre-defined feature template, and
2) let devs self-declare via signature into it
Is this correct?
👀
nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft I still think this will be useful. Lmk how I can help. We can use nostrability repo if you like.
Thinking about this through the day, self-signed attestations are still in the “trust me, bro” universe. Useful, necessary, and insufficient.
I foresee compatibility issues due to differing implementations of the same functionality.
Ideally instead of self-attestations in nostr we have an automated scorecard of how nostr app A interacts with a pre-defined rubric of “correct” or more likely “acceptable” and “non-acceptable” behavior (“ erify, don’t trust”).
I coined this #nostrCI and hopefully nostr:npub1fkvjh50p9amcvce5eclalcszqduehlhmsjm76hx3zy5sx3g40ddqqednwk and team will have the BBB workshop talk ready soon for me to share with yall.
To assuage doubts I am not in crazy land at least three CI/devops bros have either chatted with me about this, or independently come to an understanding of the nostrCI problem, and thought about solutions.
cc nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx nostr:npub1q2s36929z99tv0pfjkqf8jgmn7yxrrjklmsr0wwjl2707vhk965sp7dx3u nostr:npub128a25achgxk429gwuwy7tgrwh44z5s42js2260cxdstk7tpxv9ds497erh
