Oddbean new post about login | logout 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 @Highlighter 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 @elsat , 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. nostr:nevent1qqspv6sma6atmdax3apc009rv4u9xqsa7zs5ejgdh8jdw4umassx83cppemhxue69uhkummn9ekx7mp0qgsdv8emcke7k3qqaldwv956tstu40ejg663gdsaayuuujs6pknw7jsrf43u3
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?
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?
@PABLOF7z 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 @santos 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 @sandwich @nourspace @miketwenty1 https://image.nostr.build/a4bb3cd57aa10742fc23a47317b682f07c35b6a1dbbd6f4465eefa34c58cfb2e.png
a cool byproduct of this is that we could have kind:1 discussions tagging a particular feature in a particular client. E.g., there could be a discussion around how a feature is integrated in Primal such that someone could see what people are saying about how mute lists are supported and provide all the nuance.
+1 Clients can make declarations of compliance and users can react to them with replies, reactions and even reports if they are wrong. But we need to make it so that nuance is taken in to account. Many NIPs can are probably are just partially implemented and being able to declare what exactly should work and what will not is key.
Right. Details are important here.
Sir, I actually like this idea, but then here's the kicker, we have to have devs support this feature to keep their clients change log and feature list up to date.
Not really, you could create a NIP-89 for someone else’s app and publish these “features events for it Or probably there’s no need for the owner of the nip-89 to publish the feature events, it could be essentially “Derek Ross claims amethyst supports live streams”
(Before the “oh nooooo anyone can claim anything!!!!! Dooooom! Who’s going to think about the children?! WoT filtering 🙄)
My thoughts exactly. See, this is why you get paid the big zaps. What do we have to do to get this added to nostrapps.com @Karnage 🥹
I had this idea months ago. Published an interactive wireframe for all to see. Scrounged up just enough funding that I could get MVP out the door on my own. Have been working non stop for months to get alpha stable. Just saying … this is actually in the works. nostr:note1n56dpv3ck393nz9axmf5j9esnyaj642sfawqne4zs9ufy9865cvqu056gx
The “social onboarding” client I’m about to push will do exactly this. (In a not to distant stable release) https://image.nostr.build/040103cfeaa85e6afae8c37c0cfbb98c6f8dbdc0b8a0ee9074509f284defda91.jpg https://image.nostr.build/aa7ce9810093d1a3b18a1b54d27dc3479c16eb90a0da98acb211ec64f7f1b88e.jpg https://image.nostr.build/aa7ce9810093d1a3b18a1b54d27dc3479c16eb90a0da98acb211ec64f7f1b88e.jpg
I would like to extend the possibilities of nip89 in this way, also as a way to interact directly with the client and its development, for example using a ln addres directly in it, and also the possibility to use it to do some kind of zapversting if the client allows it, and advertise things in that way... Can help clients monetise their development.
