Nostr Web Client

> If you are not working with the browser, you can ignore that nip just like I would ignore other nips that

In theory yes, but in reality how do you know that before you at least glanced at it? And there's so many of these NIPs already that it takes a toll. It isn't scalable at the moment.

I personally feel a big mental strain just looking at the nips repo: wouldn't want to invest time into that. How many people actually know what's going on in the big picture?

Mostly I just install a library and hope the doc comments tell me what I need.

Which brings me to my point: I think the rule for acceptance should be "implement a library (or add functionality to existing) to deal with the NIP". Then I wouldn't have to care to read any NIPs.

Leo Wandersleb 2y ago

The rule for acceptance currently is that it needs to be implemented in two clients and a relay (if relevant to relays). There are libraries, so of course many aspects are quickly adopted in the libraries, too.

Currently clients support all different sets of features and do things differently. But I would say that's acceptable. Let them experiment and eventually they will converge doing things more similarly.

Reply to this note

Please Login to reply.

Discussion

Lynn Zenn 2y ago

I'd think a library implementation as requirement for merge isn't a terrible idea.

E.g. "you want your NIP merged?" "Extend nostr-tools lib and mark your the implementation under `expermental`". A timesaver for developers to just care about the doc strings.

Leo Wandersleb 2y ago

It would be a lesser requirement than "client" but what really should be added as a requirement is to provider an **open source** implementation that is being used in production. By changing an existing client's code to include a feature is one thing. To have it being used in production is a much higher hurdle. Here is where it actually gets validated.