Skip to content
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

Open
wbobeirne opened this issue Dec 21, 2018 · 9 comments
Open

Consider native app companion #106

wbobeirne opened this issue Dec 21, 2018 · 9 comments

Comments

@wbobeirne
Copy link
Member

wbobeirne commented Dec 21, 2018

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:

  • No more invalid SSL certificates since I can accept and use TLS cert files
  • No more CORS issues and the extension permissions required to circumvent them
  • Use of the GRPC API instead of the REST API
  • Provide a node for the user if they don't already have one (neutrino, or offer full sync ala Pierre's node launcher)
  • Scan common paths for automatic node configuration and macaroon lookup
  • Alternative nodes that don't have REST APIs
  • Communicate over Tor

This opens up a handful of questions though:

  • Will the stand-alone extension still be supported? This might be a huge pain, but ideally people who want Joule with their existing node and who know what they're doing shouldn't need to download a whole app for it.
  • Is there any security concern with having a native application?

Open to any thoughts on the matter!

Existing Example(s) of Feature

@jnewbery
Copy link

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?

@bitcoinuser
Copy link

I agree that we don't need another desktop lightning wallet.

My goal use case with Joule is:

  • Pair the extension with an Android Wallet that support bluetooth.
  • Use the great webln feature to pay with lightning.

@jamaljsr
Copy link
Collaborator

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.

@wbobeirne
Copy link
Member Author

Thanks for the feedback y'all, this is exactly what I was hoping to get. Let me address some of your notes:

Could you recreate that if Joule was a separate app?

[...]the biggest selling point of Joule for me is browser integration

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.

The beauty of lightning joule as it exists now is that the user flow is so smooth and intuitive[...]

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.

@jamaljsr
Copy link
Collaborator

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?

@wbobeirne
Copy link
Member Author

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.)

@bumi
Copy link
Contributor

bumi commented Dec 29, 2020

As part of the lightning hacksprint I was working on this.
It does not fit into the current Joule architecture.
So I started experimenting with a new browser extension that connects with the Native Messaging API to a native companion app. The native app talks to LND using gRPC and does most of the UI. In my case it is a electron app.
My idea was to have a small default browser extension that can talk to various native companion apps through a (yet to be defined) standard interface. This makes it possible for more wallets to easily provide deep browser integration.

@wbobeirne
Copy link
Member Author

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!)

@bumi
Copy link
Contributor

bumi commented Dec 30, 2020

nice. thanks for the feedback, happy to hear it is in the direction of your thoughts.

Currently I am using sendNativeMessage just because it was easier to implement and I wasn't sure how/when to best start/stop the native companion app.
Your library looks super helpful there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants