[NIP-47] Add versioning and migrate to NIP-44.

[jklein24]

NIP-04 is deprecated and no longer recommended for use. Authors of NIP-44 have confirmed that it can act as a drop-in replacement for NIP-04 for NWC's use case.

Versioning for NIP-47 allows the protocol to evolve and even make breaking changes while maintaining backwards-compatibility where needed. Versions are represented as <major>.<minor> (e.g. 1.3). Major version bumps imply breaking changes that are incompatible with the previous major version. Minor version bumps, however, only include non-breaking feature additions or improvements which can maintain full compatibility with the previous minor version.

[vitorpamplona]

Ack

FYI, NIP-46 (#1248) is just dynamically figuring out if the encryption is nip-04 or nip-44.

fun isNIP04(ciphertext: String): Boolean {
    val l = ciphertext.length
    if (l < 28) return false
    return ciphertext[l - 28] == '?' && 
           ciphertext[l - 27] == 'i' && 
           ciphertext[l - 26] == 'v' && 
           ciphertext[l - 25] == '='
}

The migration over there has three steps:

1. Everybody decrypts both nip 04 and nip 44
2. Everybody starts encrypting with NIP44 in their own timeline.
3. Everybody drops support for encrypting and decrypting with nip04.

[jklein24]

Ack

FYI, NIP-46 (#1248) is just dynamically figuring out if the encryption is nip-04 or nip-44.

fun isNIP04(ciphertext: String): Boolean {
    val l = ciphertext.length
    if (l < 28) return false
    return ciphertext[l - 28] == '?' && 
           ciphertext[l - 27] == 'i' && 
           ciphertext[l - 26] == 'v' && 
           ciphertext[l - 25] == '='
}

The migration over there has three steps:

1. Everybody decrypts both nip 04 and nip 44
2. Everybody starts encrypting with NIP44 in their own timeline.
3. Everybody drops support for encrypting and decrypting with nip04.

Thanks, this also makes sense as the alternative path for NIP44 migration, and is certainly simpler. My main reason for not going this route right now is so that connections can use NIP44 right away if both sides indicate support, without needing to wait for a migration or try encrypting with NIP44 first, getting an error, and then re-encrypting with NIP-04.

I also think in general a versioning scheme will be useful for NWC for future breaking changes if they're needed, but I recognize that it adds complexity.

[rolznz]

Linking the notifications PR which ideally is merged (it has multiple implementations using it already) and has implications for versioning.

Because there is no communication from the client application to the wallet service to listen to notifications (the client application is simply subscribing to the relay), I think the simplest way would be to update the notifications PR to use a different notification event kind for version 1.0, and start including the tag in the notification event. That way, version v0.0 apps will not break by trying to decode v1.0 notifications.

I do not know how useful the version tag will be on notifications though, or if another breaking change in the future would require another change to the notification event kind, since the wallet service might still want to support the previous version.