Adds an optional `extra` (JSON) field to a withdraw link. When the link
is claimed, that `extra` is merged onto the payout payment's `extra`, so
a caller can tag the resulting payment with metadata an external listener
keys on — the link is the only place to attach it (the customer-facing
LNURL-withdraw payout otherwise carries just `{tag, withdrawal_link_id}`).
Motivating use: bitSpire cash-in settlements. The operator's spirekeeper
listener fires a `cash_in` settlement (fee split to the platform) only on
an outbound payment stamped `source=bitspire`; before this there was no
way to stamp an LNURL-withdraw payout, so cash-ins never settled. bitSpire
now creates the cash-in link for the NET amount with
`extra={source, type:cash_in, principal_sats, fee_sats, ...}` and the
settlement fires on claim.
- models: `extra: dict | None` on CreateWithdrawData + WithdrawLink.
LNbits' db layer (de)serializes dict columns to/from JSON natively
(same as Payment.extra) — no per-field validator needed.
- migrations_fork.py: `withdraw_link.extra TEXT` under `withdraw_fork`,
keeping the upstream-tracked migrations.py byte-identical for clean
rebases (aiolabs/lnbits#8 pattern).
- views_lnurl: `extra={**(link.extra or {}), "tag": ..., "withdrawal_link_id": ...}`
— the withdraw extension's own keys are written last so a caller cannot
clobber them.
Verified end-to-end on the dev stack: a stamped link's payout carries the
merged extra and drives a spirekeeper cash_in settlement + super-fee payout.
This reverts commit 66026ab.
Closes#2 as resolved by switching the dev LNbits to TLS
(self-signed cert) instead of carving out plain HTTP for
RFC1918 hosts. With HTTPS the producer-side python-lnurl
validation accepts any host, AND the lnbits-core consumer-side
`lnurlscan` accepts it too — the symmetric problem the carve-out
couldn't solve on its own.
`create_lnurl_from_baseurl` (#1, `e9d911e`) is kept — it's
orthogonal to the transport scheme and still wanted for the
nostr-transport `lnurl=null` fix.
This reverts commit 40dce41.
Going with TLS termination on the dev LNbits instead, so the
RFC1918 carve-out becomes unnecessary. The lnbits-core
`/api/v1/lnurlscan` consumer-side validator applies the same
HTTPS-required rule python-lnurl enforces; carving the producer
side out only got greg's LNURL generated, not redeemed.
#2 added the loopback/RFC1918 carve-out to the nostr-transport helper
(`create_lnurl_from_baseurl`) but `views.py` / `views_api.py` still call
`create_lnurl`, which went straight through `lnurl_encode` and got the
same `InvalidUrl` rejection. Visible as a 500 "Error creating LNURL …
check your webserver proxy configuration." on the admin UI when LNbits
itself is on `http://192.168.x.x:port`.
Extract the encode + carve-out logic into `_encode_lnurl(url, hint)` and
route both `create_lnurl` and `create_lnurl_from_baseurl` through it.
Both now return the same `_EncodedLnurl` dataclass (a minimal duck for
`.bech32`/`.url`) — `Lnurl` itself can't be returned in the LAN-local
case because its `__new__` re-runs python-lnurl's host validation on
bech32-decode.
Call sites in views.py / views_api.py unchanged: they already access
`.bech32` and `.url`, which the dataclass exposes. `_populate_lnurl`
back to attribute access too.
`python-lnurl`'s `lnurl_encode` rejects HTTP URLs whose host isn't
`localhost`/`127.0.0.1`/`.onion`, so a regtest LNbits on a LAN IP
(e.g. `http://192.168.0.32:5001`) made `_populate_lnurl` swallow
`InvalidUrl` and leave `link.lnurl=None` — breaking the LAN-local
cross-device smoke flow.
Extend the existing localhost carve-out to the full RFC1918 set:
loopback, `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`. These are
intrinsically unreachable from the public internet, so producing an
HTTP LNURL pointing at one is unambiguously a dev/internal scenario.
For matching URLs, skip `lnurl_encode`'s host validation by calling
the public `lnurl.helpers.url_encode` directly (which bech32-encodes
without URL validation). Everything else still goes through the
validated path — production with HTTP + public IP/hostname stays
rejected.
`create_lnurl_from_baseurl` now returns `(bech32, url)` directly
rather than a `Lnurl` instance, since the private-network branch
can't construct a real `Lnurl` (its `__new__` re-runs the same host
validation on bech32-decode). The caller `_populate_lnurl` was the
only consumer.
Test coverage on `_is_private_network_http` covers the carve-out
boundary (loopback, RFC1918, the just-outside-RFC1918 ranges, public
hosts, and the `https://` case). The full encode path is exercised
via regtest smoke.
Closes#2.
The HTTP views populate `link.lnurl` and `link.lnurl_url` from
`request.url_for(...)`; the nostr-transport RPC handlers had no
`Request` and so left both fields as `None`. Consumers (ATMs over
nostr) were forced to provision a separate `LNBITS_HTTP_URL` env var
and compose the LNURL callback themselves.
Add `helpers.create_lnurl_from_baseurl(link)` that mirrors
`create_lnurl` but composes the callback URL from
`settings.lnbits_baseurl` instead, and thread it through the
create/get/update/list RPC handlers via a `_populate_lnurl` shim
so the response shape matches the HTTP path. Encoding errors are
swallowed (fields stay `None`) so a misconfigured baseurl falls
back to current behavior rather than failing the RPC.
Closes#1.
Two additions surface withdraw-extension capabilities the ATM use
case in aiolabs/lamassu-next (issues #24, #25) needs but couldn't
reach over the nostr transport before:
## lnurlw_list_links (AUTH_ACCOUNT)
Enumerate withdraw links across all wallets owned by the calling
account, with `limit`/`offset` pagination matching the existing
HTTP `/api/v1/links`. Lets an ATM (or any client) re-discover its
links after a reconnect without having to keep its own index.
If `request.wallet_id` is supplied and matches one of the account's
wallets, narrows the listing to just that wallet — mirrors lnurlp's
list semantics.
Returns `{data: [...links], total: <int>}`.
## lnurlw_unique_hashes (AUTH_WALLET)
For an `is_unique=True` link, return the per-use `id_unique_hash`
values derived from each unredeemed slot in `link.usescsv`. Mirrors
the formula in `helpers.py:create_lnurl:13`:
id_unique_hash = shortuuid.uuid(name=link.id + link.unique_hash + index)
Without this RPC an ATM that wants to generate distinct QR codes
per use (lamassu-next #25) had to reimplement the derivation
client-side — fragile if the extension's hash format ever changes
upstream. With this RPC the ATM asks the server for the canonical
list of unredeemed hashes; each one becomes the trailing path
component of `/withdraw/api/v1/lnurl/<unique_hash>/<id_unique_hash>`.
`is_unique=False` links return an empty `unredeemed_hashes` list;
the base `unique_hash` alone identifies the callback path.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Hooks the existing withdraw CRUD into the LNbits nostr transport layer
so an HTTP-allergic client (e.g. lamassu-next ATM) can manage LNURL-
withdraw links over kind-21000 encrypted events instead of HTTP.
New `withdraw_start()` lifecycle hook (auto-invoked by the LNbits
extension manager) imports the transport's `register_rpc` and registers
four RPCs mirroring the Lightning.Pub `withdraw.*` contract exactly so
lamassu-next's adapter can be a pure name-translation layer:
lnurlw_create_link AUTH_WALLET
lnurlw_get_link AUTH_WALLET
lnurlw_update_link AUTH_WALLET
lnurlw_delete_link AUTH_WALLET
All handlers are thin shims around the existing crud.py functions —
no business logic duplication. *_get / *_update / *_delete verify
that the link's stored wallet matches the caller's wallet id.
Also registers a link-owner resolver with the core subscriptions
module (under tag "withdraw", extras-key "withdrawal_link_id" — the
exact field name views_lnurl.py:144 stamps on payment.extra when a
withdraw settles). That lets clients call
`subscribe_payments({tag:"withdraw", link_id:...})` and stream real-
time claim events without polling, with ownership enforced server-side.
The transport import is guarded by try/except ImportError so this
extension still loads cleanly against an LNbits build that doesn't
have nostr_transport.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
