NWC PR: incorporate feedback

[kiwiidb]

I think I have included all the feedback from the discussion, while ensuring that the scope of the NIP stays manageable.

• JSON-RPCish payloads with a field indicating the type of the response.
• Info is a replaceable event.
• Only describe the pay_invoice command.
• Only use a single relay.
• Responses should have an e tag to indicate what they are responding to.

[Semisol]

I strongly believe that using numeric error codes is going to cause conflicts when a new type needs to be created. We should use text error codes instead. Don't change it if it is not broken.

Also, multiple relays should be supported.

[Semisol]

LGTM except a few small changes

[vitorpamplona]

Let's make sure we code this before merging.

[Semisol]

Just please apply this. Then merging is fine with me.

Encoding the type is redundant since the client will already have an in memory object for the request with whatever to pass the response to, a timeout, etc. so the client can also look up this field themselves.

The argument "the structure of the object has to be known beforehand" is redundant since most JSON libraries allow you to decode arbitrarily structured JSON and get things by their keys.

[bumi]

After doing some more experimentation on how the UX to connect could look like I think we should leave it up to the client and the wallet services to decide how the connection details are shared.
The environments where this could be used are quite different (mobile client, web client, CLI, ...).
So for example passing a secret in a URL is bad in the web but fine in the mobile case with a deep-link.
In the web the flow would be better where the web app creates the secret and passes the public key to the wallet service prompting the user to confirm it.

The important part is that client and wallet service need to exchange some connection information (wallet pubkey, relay and connection secret/pubkey). For maximum interoperability we should standardize the format for this in the nostr+walletconnect URI scheme.
But I don't think we need to define how this information is shared.

In a mobile case this could be through a deep-link from the wallet service back to the client or the user scanning a QR code
In a CLI case it could be the user copy&pasting the connection string
In a web client it could be a link from the client to the wallet service sharing the connection pubkey.

This should stay flexible and up to the developers.

I've tried to propose this in this PR: getAlby#1

edit: I was asked: why are secrets in URLs bad? because the URLs are cached on various levels starting with the browser history.

[jb55]

LGTM. Will try to code this up soon.

[vitorpamplona]

Happy to report the just released Amethyst 0.35.0 migrated from the original design to this one with JSON payloads back and forth.

[kiwiidb]

@Semisol or @fiatjaf it seems we have reached some consensus, can someone merge this PR into the other PR: #406 , and then also merge that one?

[fiatjaf]

@Semisol your call.

[Semisol]

Oops. Missed it. Merging now.

Adding an error code for failed payments after merging