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"

Reply to this note

Please Login to reply.

Discussion

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