Oddbean new post about | logout
 There is a NIP for the client/relay/provider standard

https://github.com/nostr-protocol/nips/blob/master/47.md

The difference is whats happening on the provider.

Alby and LNbits (nwcprovider extension) support defining budgets for each NWC configuration, and allow multiple configs per wallet and overall granular control.

Coinos has provided basic support, auto creating NWC connect string for the wallet, but no budget (unlimited spend), no permissions conatraints (full access) and only one for the wallet.

In time I anticipate coinos enhancing that capability to bring it up to the standards of other implementations.

Subscriptions using NWC for automating periodic pulls should only be configured with those wallets offering granular control. 
 Could that granular control also be codified into a NIP? 
 Maybe, but its not really a nostr issue.
Its not a lightning or LUD issue either.
Its a provider feature for their custodial accounts. NIPs are best as bare minimum specs for building blocks, vs documenting implementation specific options.

As an example, I wouldnt want NIP96 for file servers to standardize and force those kinds of providers to implement transforms for downscaling, text parsing, transcript producing either. Those features are nice to have, but not essential for core function. The more bloat to a NIP, the more moat building it creates for incumbents

What may be appropriate would be a NIP standard for discovering client/relay/services, and their feature sets. Individual domains would need to self regulate though, so it may just be passing the buck on the issue