Thanks to visit codestin.com
Credit goes to github.com

Skip to content

NWC PR: incorporate feedback #437

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 9 commits into from
Apr 27, 2023
Merged

NWC PR: incorporate feedback #437

merged 9 commits into from
Apr 27, 2023

Conversation

@kiwiidb
Copy link
Contributor

@kiwiidb kiwiidb commented Apr 13, 2023

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.

@kiwiidb kiwiidb mentioned this pull request Apr 13, 2023
Merged
Semisol
Semisol suggested changes Apr 15, 2023
View reviewed changes
Copy link
Contributor

@Semisol Semisol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@kiwiidb kiwiidb force-pushed the 7-wallet-connect-patch branch from 9ea86eb to ecc16b5 Compare April 16, 2023 15:55
@kiwiidb kiwiidb force-pushed the 7-wallet-connect-patch branch from ecc16b5 to a0a44b6 Compare April 16, 2023 15:55
@kiwiidb kiwiidb requested a review from Semisol April 16, 2023 15:56
Semisol
Semisol suggested changes Apr 16, 2023
View reviewed changes
Copy link
Contributor

@Semisol Semisol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM except a few small changes

kiwiidb and others added 2 commits April 17, 2023 09:29
@kiwiidb @Semisol
Update 47.md
607daf9 
Co-authored-by: Semisol <[email protected]>
@kiwiidb @Semisol
Update 47.md
5825af6 
Co-authored-by: Semisol <[email protected]>
vitorpamplona
vitorpamplona reviewed Apr 18, 2023
View reviewed changes
@vitorpamplona
Copy link
Collaborator

Let's make sure we code this before merging.

Semisol
Semisol approved these changes Apr 19, 2023
View reviewed changes
Copy link
Contributor

@Semisol Semisol left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link

bumi commented Apr 20, 2023 •
edited
Loading

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
Copy link
Contributor

jb55 commented Apr 24, 2023

LGTM. Will try to code this up soon.

@vitorpamplona
Copy link
Collaborator

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
Copy link
Contributor Author

kiwiidb commented Apr 25, 2023

@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
Copy link
Member

fiatjaf commented Apr 25, 2023

@Semisol your call.

Semisol
Semisol approved these changes Apr 27, 2023
View reviewed changes
Copy link
Contributor

@Semisol Semisol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. Missed it. Merging now.

Adding an error code for failed payments after merging

@Semisol Semisol merged commit de095e4 into nostr-protocol:47-wallet-connect Apr 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@vitorpamplona vitorpamplona vitorpamplona approved these changes

+1 more reviewer

@Semisol Semisol Semisol approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@kiwiidb @vitorpamplona @bumi @jb55 @fiatjaf @Semisol