Kumulynja

I am also not seeing it in this package, but you can use this: [https://pub.dev/packages/nip06](https://pub.dev/packages/nip06). It does just that standalone and nothing more 👍

@i5hi @ethicnology Thinking about the "linking" part some more, I really think we should just do the linking in a Usecase `getAllTransactionRelatedLabelsUseCase` or something similar, and it just uses the...

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

> Why do you think it would be so easy to get a new major version merged as a NIP? I don't know that, just as you don't know it...

Another concern I have with versions like this instead of just optional add-ons/changes that are backwards compatible or can be signalled for individually is that I might like one thing...

> I see your update and am glad you're rethinking things. I'll just note that I'm totally open to other suggestions to update NWC to NIP-44 if you see another...

@jklein24 wrote out a quick initial draft that also explains how to know which encryption to use: https://github.com/nostr-protocol/nips/compare/master...kumulynja:nips:client-info-event The main advantage it has over strict versioning is the flexibility to...

> @kumulynja I think the client info event increases complexity as it requires the client to send this event and the server to maintain states about different client capabilities. I...

To give another example: Let's say the latest version of nip47 is 2.5 and a client or wallet is still on 2.1, but it needs just one new addition for...

> While I agree that versioning the entire NWC in one number is bad So we agree that explicit versioning for NWC is bad 👍 > It is still very...