Jeremy Klein

> Linking [the notifications PR](https://github.com/nostr-protocol/nips/pull/1164) which ideally is merged (it has multiple implementations using it already) and has implications for versioning. > > Because there is no communication from the...

> Notifications got merged , #1164 so here it needs to adapt to new spec, conflicts resolved, and there is the issue of which kind of encryption to use on...

> > 3. Client makes some request (get_info) which indicates a v tag of 1.x. > > The wallet service can optionally cache this version as its notification version as...

> @jklein24 I would not do client-side deduping, just use the `get_info` call first to figure out if the wallet service supports NIP-44 or not, and then only subscribe to...

> Nack at first sight, I think adding versioning like this will make contributors lazy and make them think less about backwards-compatibility since their new update can just get a...

After chatting through this more, I've whipped up a [quick alternative PR](https://github.com/nostr-protocol/nips/pull/1780) which implements the simplest possible alternative like @kumulynja is suggesting. I think this is a pretty reasonable alternate...

> @jklein24 @kumulynja this alternate idea seems like a better option and more consistent with how we indicate supported methods and notifications. I will see if we can update our...

> I greatly admire the linux application development principle of "make libraries that do one thing and do it well" > > Frontend devs can stitch together different libraries to...

> Looks good to me. But we have no implementations yet, right? > > I have added an issue to Alby Hub to implement this. Thanks! We have it implemented...

> > Looks good to me. But we have no implementations yet, right? > > I have added an issue to Alby Hub to implement this. > > Thanks! We...