-
Notifications
You must be signed in to change notification settings - Fork 61
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
Consider native app companion #106
Comments
My immediate reaction is "do we need another desktop lightning wallet?" There's already the lightning labs app and zap for lnd, spark for c-lightning, and eclair's GUI. It's already quite a crowded field. The beauty of lightning joule as it exists now is that the user flow is so smooth and intuitive, especially when the site integrates with webln. That's something that Joule offers that none of the other wallets have. Could you recreate that if Joule was a separate app? |
I agree that we don't need another desktop lightning wallet. My goal use case with Joule is:
|
I also have to agree that the biggest selling point of Joule for me is browser integration. The space needed a MetaMask for lightning/bitcoin and this extension is filling that hole. Also considering the potential future capabilities of streaming payments for websites, I think you have a winner here. |
Thanks for the feedback y'all, this is exactly what I was hoping to get. Let me address some of your notes:
Sorry if I wasn't clear, the extension is here to stay. A native application wouldn't be a replacement for the extension, it would be a companion to smooth out some of the rough edges of Joule. It'd normalize communication with the node so that other types could be supported, and it'd fix the CORS and TLS cert issues present in direct communication with LND. It could also do LND setup for you if you don't have an existing node. But all of that would just be to serve up to the extension. There's also no reason it would have to be required, you could still reasonably directly connect to your node if you want to.
Once you've gotten it setup, absolutely. But the onboarding flow is a bit of a nightmare right now, between macaroon uploading, getting around certificate and CORS issues, etc. This is what I'd be trying to remedy. |
Ahh, thanks for that clarification. I did think you were suggesting to replace the extension with a desktop app. I’m still a bit fuzzy on what you’re propossing. Can you give an example of a native/extension combo app? (Lastpass?) What does the setup process look like? Chrome Store or downlable installer? |
1Password and Blockstack are apps that do something similar. They leverage a native application for the things native apps are good at (File system handling, custom URI registration, etc.) and extend that functionality into the browser. I would probably leverage the extension Native Messaging API (https://developer.chrome.com/apps/nativeMessaging) or open a websocket with the native app, which the extension would communicate to. The native app would then handle all of the node communication. The setup process would be installing either the extension or the native app first, and those programs would prompt you to install the other. The extension, during onboarding, would communicate with the native application to establish a connection to your node. Those settings would be saved locally on your machine (rather than the current implementation in browser storage.) |
…n/@types/node-14.0.27 Update @types/node: 14.0.23 → 14.0.27 (patch)
As part of the lightning hacksprint I was working on this. |
Awesome! The architecture you have there is basically what I had in mind, love the diagram. I actually implemented native messaging for a browser extension in a past job, and had whipped up this little library over here: https://www.npmjs.com/package/@coder/wxnm. We ended up abandoning that project, but I should see if I could convince them to let me publish the library as an open source repo, as it smoothed out a lot of the communication and installation (and gives you nice TS types to boot!) |
nice. thanks for the feedback, happy to hear it is in the direction of your thoughts. Currently I am using |
Description of the Feature or Idea
This is kind of a "big picture" issue that would need to be broken out into its own repo or set of issues, but I wanted to open it for discussion, so here goes:
Joule is running into a lot of usability issues that are constraints from its extension form factor. If there were a native application, it could get around a bunch of issues:
This opens up a handful of questions though:
Open to any thoughts on the matter!
Existing Example(s) of Feature
The text was updated successfully, but these errors were encountered: