-
Notifications
You must be signed in to change notification settings - Fork 33
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.
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
Add CoinOS connector #263
Comments
Hey @rolznz I'd like to give this a go. If anyone isn't working on it yet |
@Dayvvo I don't think anyone is, please go ahead! |
Hey @rolznz I went though the code in the past week, looking at how existing connectors are setup. I was able to contact the guys at coinos and they'd like to have a connect option like Alby's which has the best UX on bitcoin-connect. Looking at the setup it looks like I'd have to create a corresponding issue on getAlby/js-sdk in order o add config options for a sign in api like the one done in NWCClient.ts here. Will create a PR when I have it all figured out. Let me know what you think! |
@Dayvvo awesome that you contacted them. We are currently planning an open protocol for connecting to wallets which should support deep links like the existing Alby one. We should have some updates here in the next couple of weeks, if you are able to wait. Instead of hardcoding authorization URLs like it is done currently in the JS SDK that you linked, it would be possible to find the authorization URL just by typing the lightning address of your CoinOS/Alby/etc. wallet. |
Hey @rolznz thanks for this info. would it be possible to get a bit more context on how this would work? We were kinda looking at the convenience of the current alby login where a click redirects to the alby login and user doesn't need to copy and paste a string. I'm not exactly sure how it works but from what you said I'm getting that it seems like a 2 step process where the user will have to copy and paste his lightning address and then get redirected to a login screen which he/she may have to enter login credentials again. Is that how the flow would work? |
@Dayvvo I agree and prefer the original flow. It seems like we will go with this one rather than the lightning address idea. The reason why we were considering this is because we also want to support self-hosted hubs which might not have a publicly accessible URL, but we have found a different way to do this. Our current documentation for deeplink parameters are here: https://github.com/getAlby/hub/?tab=readme-ov-file#client-created-secret - it would be great to create a spec around this. There are two ways the connection url (relay and wallet pubkey) can be returned (via the return_to property or via a message from an auth popup) One essential thing is that the clientside (here bitcoin connect) generates the secret key, and only gives the pubkey when doing the login. We will have to update the JS SDK to return the wallet service pubkey since at least in the hub, it's now different for every app. I will make a PR for this soon. Please let me know if you have any questions! I will update here when I have PRs and more information. |
@Dayvvo I've started a PR in Alby JS SDK to simplify executing the auth flow here: getAlby/js-sdk#297 CoinOS would need to do a few things:
|
The CoinOS connector should be able to be simple like the old Alby Connector ( its
|
Alright. So to clarify this snippet here
is to trigger a successful login for internal logic handing that in the auth api page of a provider like coinos and not to send a message to the opener. that part is handled by the Also this is much clearer to me. tbh I have been through the code that facillitates the alby login flow and from what I saw it seemed like the secret was being generated by the client and the walletpubkey and relay url are also hardcoded in the js-sdk code. So basically the nwc string was not being returned from the opened window that authorizes a user. I was really confused about how that worked to authorize a specific user. but this new flow seems to return the NWC string from the provider api page that is Opened which seems much simpler. I will notify the guys at coinos about this. Also let me know what you think @rolznz. Happy to hear your input or further explanation about what I missed |
The CustomEvent is for when the auth is handled in a webview (e.g. on native mobile apps). The But the intent is the same - to send information back to the app that initiated the auth flow, so that it receives the relay URL and the wallet service pubkey. In combination with the app key which is generated by the app itself, all the parameters necessary to initiate a NWC connection are available.
Note: the secret key is still generated locally, this is so that the secret does not have to be sent over the internet. But if that does not fit with coinOS, they can still return a secret of their own and return it in the event/message above. The app should discard the one it generated and instead use the one generated by coinOS. |
Hey @rolznz so it could be done. The guys at coinos are willing to implement whatever flow works best for everyone and gives good UX. I'm basically asking because I am bit confused as to how it works in tandem with the nip47 spec. After I looked at the alby implementation I actually had the intention to ask this question before we got to conversing about this apporoach. From the spec I have come to understand that the secret is generated by the wallet to be connected, along with other parameters. I was under the impression that the generated secret that is used to decrypt messages sent to the relay is how the relay confirms the validity of the strings. So how does messages to the relay with a locally generated secret work. is this in agreement with nip47 spec or another implelmentation? a Bit of an explanation will be greatly appreciated @rolznz |
Hi guys thanks for working on this, I'm excited to get Coinos added to bitcoin connect! I'm willing to redo things on our end a bit so that we can support accepting app secrets and have multiple connections under a single Coinos account. I'll update our nostr settings page to let people see all their connections and manage limits/budgets for each one. |
No description provided.
The text was updated successfully, but these errors were encountered: