[nGoline]

Stacked on #16 and #15. Merge those first. The diff then shrinks to the 4 commits from 1a7848c onward, and I'll rebase onto main.

Why

cln-grpc can't restrict a client. In v26.06.9 the plugin configures TLS with client_ca_root(ca) and no auth interceptor, so any certificate signed by the node's CA gets every RPC method, including pay and withdraw. Its source says so (plugins/grpc-plugin/src/tls.rs): "the server will accept any client that is signed by the CA. In the future, we might add runes". Minting a separate client cert doesn't help. clnrest checks a rune on every call, against the method and its parameters.

What

• LIGHTNING__BACKEND=clnrest → new ClnRestService: POST /v1/{invoice,listinvoices,getinfo} with the Rune header. Env: CLNREST__URL, CLNREST__RUNE, CLNREST__CACERT (the node's ca.pem; it can be omitted only behind a publicly trusted proxy). Behaves the same as the gRPC backend: description hash, comment in label, verify limited to lnaddress- invoices.
• LIGHTNING__BACKEND=cln (gRPC) still works unchanged, and is documented as legacy.
• PEM reading, CA validation and invoice labels are moved into Helpers/ and shared by both transports.

The recommended rune

lightning-cli createrune restrictions='[["method=getinfo","method=invoice","method=listinvoices"],["method/invoice","pnamelabel^lnaddress-"],["method/listinvoices","pnamepayment_hash/"]]'

Call	Result on v26.06.9
getinfo; invoice with an lnaddress- label; listinvoices by payment_hash	✅ allowed
invoice with any other label	❌ 401
listinvoices with no filter or by label (can't dump other invoices)	❌ 401
pay, withdraw, listfunds, createrune, …	❌ 401

Docs

• The CLN section now leads with clnrest: enabling it, the rune and what it allows, revoking it with showrunes/blacklistrune, and env vars.
• The "don't expose it publicly" warning is kept and now covers both transports. The rune can't spend, but it can still create invoices, and the clnrest port accepts any other rune you've issued. Keep it on a private network and proxy only the two LNURL paths.
• cln-grpc moves to a Legacy subsection with a stronger caution, plus migration steps. CLNREST__CACERT takes the same ca.pem as before, and labels are unchanged, so verify keeps working for old invoices.

Tests

• Unit (56, +15): request shape (URL, Rune header, amount_msat/label/description/deschashonly), comment in label, paid/unpaid/expired, foreign and unknown invoices → null, sync warnings, rune rejection → error, config validation.
• Integration (23, on CLN v26.06.9): the regtest node now runs clnrest too, and the fixture creates the README's rune. The same 8 backend tests run over both gRPC and clnrest (shared base class). Another 6 confirm the rune rejects listfunds, withdraw, pay, createrune, unfiltered listinvoices and invoices with other labels. One test checks that the README documents exactly the rune the tests use.
• End to end: the Docker image with LIGHTNING__BACKEND=clnrest on a private network with the regtest node. Healthy; description_hash == sha256(metadata) per lightning-cli decode; comment in label; real payment settles and verify returns the preimage; foreign invoice → Not found; no /health log noise.
• ci: add GitHub Actions for CI, releases and Dependabot #14 is updated so the CI CLN job runs both ClnGrpcIntegrationTest and ClnRestIntegrationTest.

Deployment note

Nothing changes unless you switch. To move the ms02 deployment: add clnrest-port=3010 and clnrest-host=<container IP or 0.0.0.0 on the private network> to lightningd, create the rune, then replace LIGHTNING__BACKEND=cln + CLN__* with LIGHTNING__BACKEND=clnrest, CLNREST__URL=https://lightningd:3010, CLNREST__RUNE and CLNREST__CACERT (the same ca.pem). Then drop client.pem/client-key.pem from LnAddress's env.

🤖 Generated with Claude Code