This adds LndHub Lightning wallets and wallet setup UI for user accounts. Also adds lnurl-pay endpoints to support lnurl-based payments, and one of the endpoints can also be proxied to for the Lightning Address.well-known URLs.
The latter means that, as soon as the addresses are enabled, you can easily send sats to any Kosmos user address, e.g. from resolving your XMPP contacts' JIDs. However, that is not part of this PR, but only the wallets themselves, which you can set up to use with Blue Wallet, as well as the lnurl-pay endpoints for generating invoices from URLs.
I tested it with our production LndHub, but we'll have to add something for simple development testing (local lndhub against remote LND I guess).
Deployment
There's a Rake task for generating wallets for all users via Sidekiq jobs, after this code has been deployed to production.
bundle exec rails lndhub:generate_wallets
Caveat
CI for this repo is currently broken, but not due to code changes in the repo. I created an issue for that in the Chef repo. You should be able to run the suite locally without problems.
This adds [LndHub](https://github.com/BlueWallet/LndHub) Lightning wallets and wallet setup UI for user accounts. Also adds [lnurl-pay](https://github.com/fiatjaf/lnurl-rfc/blob/luds/06.md) endpoints to support lnurl-based payments, and one of the endpoints can also be proxied to for the [Lightning Address](https://lightningaddress.com/) `.well-known` URLs.
The latter means that, as soon as the addresses are enabled, you can easily send sats to any Kosmos user address, e.g. from resolving your XMPP contacts' JIDs. However, that is not part of this PR, but only the wallets themselves, which you can set up to use with [Blue Wallet](https://bluewallet.io/), as well as the lnurl-pay endpoints for generating invoices from URLs.
I tested it with our [production LndHub](https://lndhub.kosmos.org/), but we'll have to add something for simple development testing (local lndhub against remote LND I guess).
### Deployment
There's a Rake task for generating wallets for all users via Sidekiq jobs, after this code has been deployed to production.
bundle exec rails lndhub:generate_wallets
### Caveat
CI for this repo is currently broken, but not due to code changes in the repo. I created [an issue for that](https://gitea.kosmos.org/kosmos/chef/issues/352) in the Chef repo. You should be able to run the suite locally without problems.
refs #34
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
This adds LndHub Lightning wallets and wallet setup UI for user accounts. Also adds lnurl-pay endpoints to support lnurl-based payments, and one of the endpoints can also be proxied to for the Lightning Address
.well-knownURLs.The latter means that, as soon as the addresses are enabled, you can easily send sats to any Kosmos user address, e.g. from resolving your XMPP contacts' JIDs. However, that is not part of this PR, but only the wallets themselves, which you can set up to use with Blue Wallet, as well as the lnurl-pay endpoints for generating invoices from URLs.
I tested it with our production LndHub, but we'll have to add something for simple development testing (local lndhub against remote LND I guess).
Deployment
There's a Rake task for generating wallets for all users via Sidekiq jobs, after this code has been deployed to production.
Caveat
CI for this repo is currently broken, but not due to code changes in the repo. I created an issue for that in the Chef repo. You should be able to run the suite locally without problems.
refs #34
looks good to me.
utACK
@@ -0,0 +9,4 @@maxSendable: 1000000,minSendable: 1000,metadata: metadata(@user.address),commentAllowed: 255we should set this to
0because we do not allow the payer to send a comment with the payment.Nice. That looks pretty dope 👍 Looking forward to using it.
Haven't tested it locally, but code looks all good to me.
Just left one comment/question.
@@ -0,0 +49,4 @@def validate_amount(amount)if amount > 1000000 || amount < 1000render json: { status: "ERROR", reason: "Invalid amount" }Shouldn't this also give an error response code? Maybe 422?
You would think so, but no. That's how ldnhub clients are expected to implement errors. ;)
WHUT?
the lnurl spec specifically says to ignore HTTP status codes :( - no idea why... but because of that it's better to return a 200
@@ -0,0 +20,4 @@validate_amount(amount)payment_request = @user.ln_create_invoice({amount: amount,this must be
amount/1000- amount is in msats but we create invoices for sats.