-
-
Notifications
You must be signed in to change notification settings - Fork 150
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
C-lightning connection QRcode #515
Comments
From the discussion on https://twitter.com/openoms/status/1425363809967935491 it seems that a prefix for the host would be desired. Question if we should identify the access-key / macaroon as well like in Spark wallet: The updated format with the host prefix and without the acces-key prefix is:
the edited strings: Spark for Zeus
C-lightningREST
|
Hey guys, My only feedback is that https seems pointless for Tor v3 endpoints. You can always add v3 Fully Noded uses this format for quick connect QR codes. For c-lightning you can install a plugin like this. Its simple and works well. Would be great if more wallets supported it! If interested you can check out the simple guide here. |
thanks for sharing. I am afraid the BTC standup URL format is entirely different from what LND and other CLN connect implementations use. There is no username and instead of a password there is an access token. The host is clearnet by default (routed to a .onion) and always SSL encrypted with a self-signed certificate. The Tor Auth is a great feature and would be really nice to see to be implemented in Zeus. Would worth a dedicated issue / feature request. |
@kaloudis we would like to settle on a format to offer in the RaspiBlitz. Can we coordinate in a way that we could work together using a QRcode which might be used in Zeus later? The alternative is offering some explanation to the user and make them paste the strings manually. After all it would possibly make sense to stick to the Spark wallet format:
Question is if we should use a similar format for C-lightningREST with a Like: In both the
The optional communication of the SSL cert can be left for now as planning to .onion services for now. What do you think? |
This is workable for me. No flag for implementation - maybe called |
not sure what you mean, can you clarify where would you use those to specify the implementation? There is |
that would be OK, but |
yes, that's C-lightningREST follows the LND macaroon model. BTW there is already a Since the data contained when connecting C-lightningREST is the same as with lnd might as well use the lndconnect format (with the optional certificate entry):
|
Showing the Tor address and Acces Key / Macaroon individually to be scanned and pasted into the wallets Discussed in: ZeusLN/zeus#515 and #2295
Bringing this back to life, would be great to see an easy way to connect to Lightning nodes used widely =) |
There is progress for C-lightningREST:
It seems that the |
format for CLNRest #2294 |
Related to raspiblitz/raspiblitz#2295 (comment)
and https://twitter.com/openoms/status/1425363809967935491
Will provide connection details to a testnet node here, feel free to contact me if it is offline:
The node:
Spark
Spark connection screen from Zeus v0.5.2: (no option to scan a QR):
Spark / Sparko connection details generated with:
config.scripts/cln-plugin.sparko.sh connect testnet
QRcode format for Spark:
which would be:
C-lightningREST
C-lightningREST connection screen:
Connection details generated with:
config.scripts/cln.rest.sh connect testnet
A simple example QR with all the info:
QRcode format
There are many standards: https://www.lightningnode.info/technicals/lightning.connect
Since Tor is built in both Zeus and RaspiBlitz will only use that to connect, but LAN is also available for testing.
To minimize the QRcode size I propose the following minimal format:
host.onion:port?access-key_or_HEX_macaroon?optional_ssl_cert
https://
prefix necessary when the port is specified anyway?:port
can be optional if it is the default for HTTPS (443)The text was updated successfully, but these errors were encountered: