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

admin.macaroon optional #184

Open
robclark56 opened this issue Mar 10, 2019 · 1 comment
Open

admin.macaroon optional #184

robclark56 opened this issue Mar 10, 2019 · 1 comment

Comments

@robclark56
Copy link

By the way LOVE YOUR WORK!

Description of the Feature or Idea

Seems Joule MUST have both admin.macaroon and readonly.macaroon to operate.

But I would like to see a 'read only' option where Joule CAN see the state of the LND node, but can NOT do things that require the admin.macaroon.

Existing Example(s) of Feature

Kinda like a 'watch only' Bitcoin wallet that can watch a wallet (as it has the public keys), but not spend (as it has no private keys).

Comment

Macaroons 101

With the readonly.macaroon, you can 'see but not touch' the LND node
With the admin.macaroon, you can do everything
With the invoice.macaroon, you can generate new invoices, and that is about all.

Here is what I would like to see:

  • User MUST enter readonly.macaroon, and Joule will show what it can with that. Features that will not work (eg open a new channel) are greyed out (disabled)
  • User can optionally enter the admin.macaroon, and all features now available.
  • invoice.macaroon??? Maybe the 'admin.macaroon' field is re-labeled Admin or Invoice Macaroon (Optional). If user enters admin.macaroon => All features. If user enters invoice.macaroon, only action available is create a new invoice (as well as all the readonly stuff)
@wbobeirne
Copy link
Member

Hey, thanks for the writeup and sorry for the delayed response. I definitely see the use of a read-only mode, especially after cool features like #177. However, this looks like it'd be a considerable amount of work to do with a good user experience that would hide, disable, or show messaging around the features that require an admin macaroon.

I'm still interested in the idea though, but I think we'll need the provider-agnostic groundwork from #176 to do this feasibly. But I don't see this getting done until quite a few other node use cases are taken care of.

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

2 participants