Nostr Web Client

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.

nostr:nevent1qqspv6sma6atmdax3apc009rv4u9xqsa7zs5ejgdh8jdw4umassx83cppemhxue69uhkummn9ekx7mp0qgsdv8emcke7k3qqaldwv956tstu40ejg663gdsaayuuujs6pknw7jsrf43u3

Reply to this note

Please Login to reply.

Discussion

elsat 1y ago

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?

PABLOF7z 1y ago

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"

elsat 1y ago

So we would:

1) have a pre-defined feature template, and

2) let devs self-declare via signature into it

Is this correct?

Vanessa 1y ago

👀

elsat 1y ago

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

PABLOF7z 1y ago

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.

Vitor Pamplona 1y ago

+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.

Derek Ross 1y ago

Right. Details are important here.

Derek Ross 1y ago

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.

PABLOF7z 1y ago

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”

PABLOF7z 1y ago

(Before the “oh nooooo anyone can claim anything!!!!! Dooooom! Who’s going to think about the children?!

WoT filtering 🙄)

Derek Ross 1y ago

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 nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac 🥹

ManiMe 1y ago

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

ManiMe 1y ago

The “social onboarding” client I’m about to push will do exactly this. (In a not to distant stable release)

Gzuuus 1y ago

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.

Mark Camper 1y ago

Could DVM replace super-elsat here?

hzrd149 1y ago

Could we use the wiki articles for this? If we had a good UI for proposing and accepting changes It should be really easy to maintain a decent page. also markdown has tables 🤔

miljan 1y ago

this could work

sandwich 1y ago

yes.

U 1y ago

Haha this is basically what I suggested already back at #nostrasia with my NIP211 😇

I'm still working on it btw 🫡