Update docs

DEV.md

@@ -1,4 +1,4 @@
-- Build with `--configure --enable-debugbuild` and `uv run make`.  Much faster with `uv run make RUST=0`.
+- Build with `./configure --enable-debugbuild` and `uv run make`.  Much faster with `uv run make RUST=0`.
 - Env vars for tests: `RUST=0` (if RUST plugins were not built), `VALGRIND=0` (much faster), `TIMEOUT=10` to speed failures (or 100 if VALGRIND=1).
 - *gen.[ch] files are generated by the Makefile.
 - ccan/ is imported from ccan repo: PRs should go there, then `make update-ccan`.
@@ -7,9 +7,9 @@
 - assert-based unit tests can "#include ../file.c", OR add objects to Makefile targets: `make update-mocks` will regenerate mocks for functions from link errors.
 - Commits should be reviewable, bisectable, and include tests.  Pattern: one commit adds a python test with @pytest.mark.xfail(strict=True), next commit fixes the problem and removes that line.
 - Commits which fix crashes or bug MUST quote the bug for later searches: do not rely on being able to find the bug report in future!
-- Commits which create signficant user (not developer!) visible changes should have Changelog-(Added|Deprecated|Changed|Fixed|EXPERIMENTAL) for assembling CHANGELOG.md at release time.
+- Commits which create significant user (not developer!) visible changes should have Changelog-(Added|Deprecated|Changed|Fixed|EXPERIMENTAL) for assembling CHANGELOG.md at release time.
 - Deprecations must use the deprecation infrastructure, and append to the table in doc/developers-guide/deprecated-features.md
-- Adding a new JSON-RPC command requires the most careful design: start with doc/schemas/NAME.json and add doc/NAME.json to MARKDOWNPAGES in doc/Makefile.  `make doc-all` will regen the rest.
+- Adding a new JSON-RPC command requires the most careful design: start with doc/schemas/NAME.json and add doc/NAME.7 to MARKDOWNPAGES in doc/Makefile.  `make doc-all` will regen the rest.
 - In pytest integration tests, name nodes l1, l2, etc in creation order.  This matches the log prefixes they use (`lightningd-1` etc) and on test failure the logs and other ephemera will in /tmp/ltests-*/TESTNAME*/lightning-1/.
 - In pytest, never assert that a command raises an exception without specifying *exactly what* it raises!  Use `with pytest.raises(RpcError, match='xxx'):`
 - tal_bytelen / tal_count of NULL are defined to be zero, and you may assume this.

README.md

@@ -11,7 +11,7 @@ Core Lightning (previously c-lightning) is a lightweight, highly customizable an
 	* [Sending and Receiving Payments](#sending-and-receiving-payments)
 	* [Configuration File](#configuration-file)
 * [Further Information](#further-information)
-    * [FAQ](doc/FAQ.md)
+    * [FAQ](doc/node-operators-guide/faq.md)
     * [Pruning](#pruning)
     * [HD wallet encryption](#hd-wallet-encryption)
 	* [Developers](#developers)
@@ -37,7 +37,7 @@ Don't hesitate to reach out to us on the implementation-specific [mailing list][
 
 ## Getting Started
 
-Core Lightning only works on Linux and macOS, and requires a locally (or remotely) running `bitcoind` (version 25.0 or above) that is fully caught up with the network you're running on, and relays transactions (ie with `blocksonly=0`).
+Core Lightning only works on Linux and macOS, and requires a locally (or remotely) running `bitcoind` (version 23.0 or above) that is fully caught up with the network you're running on, and relays transactions (ie with `blocksonly=0`).
 Pruning (`prune=n` option in `bitcoin.conf`) is partially supported, see [here](#pruning) for more details.
 
 ### Installation
@@ -228,6 +228,5 @@ Developers wishing to contribute should start with the developer guide [here](do
 [releases]: https://github.com/ElementsProject/lightning/releases
 [dockerhub]: https://hub.docker.com/r/elementsproject/lightningd/
 [jsonrpcspec]: https://www.jsonrpc.org/specification
-[helpme-github]: https://github.com/lightningd/plugins/tree/master/helpme
 [actions-badge]: https://github.com/ElementsProject/lightning/workflows/Continuous%20Integration/badge.svg
 [actions]: https://github.com/ElementsProject/lightning/actions

doc/beginners-guide/backup-and-recovery/recovery.md

@@ -16,7 +16,7 @@ privacy:
   - Copy the valid binary formatted `hsm_secret` into `$LIGHTNINGDIR` directory
   - Copy the latest `emergency.recover` backup file into the `$LIGHTNINGDIR` before starting up the node
   - Start `lightningd`
-  - Run `lightning-cli emergencyrecover` (RPC command)[https://docs.corelightning.org/reference/lightning-emergencyrecover] to recover all the channels on the node
+  - Run `lightning-cli emergencyrecover` (RPC command)[https://docs.corelightning.org/reference/emergencyrecover] to recover all the channels on the node
   - Wait until your peer force closes the channel and the node would automatically sweep the funds. This could take some time
 
 
@@ -29,11 +29,11 @@ privacy:
   - Run `lightning-cli emergencyrecover` (RPC command)[https://docs.corelightning.org/reference/lightning-emergencyrecover] to recover all the channels on the node
 
 
-> 🚧 
+> 🚧
 >
 > **Only** recover from database if you are sure that it is **latest**.
 >
-> Snapshot-style backups of the lightningd database is **discouraged**, as _any_ loss of state may result in permanent loss of funds. 
+> Snapshot-style backups of the lightningd database is **discouraged**, as _any_ loss of state may result in permanent loss of funds.
 >
 > See the  [penalty mechanism](https://github.com/lightning/bolts/blob/master/05-onchain.md#revoked-transaction-close-handling) for more details.
 

doc/beginners-guide/beginners-guide.md

@@ -57,4 +57,4 @@ Once you've started for the first time, there's a script called `contrib/bootstr
 
 There are also numerous plugins available for Core Lightning which add capabilities: see the [Plugins](doc:plugins) guide, and check out the plugin collection at: https://github.com/lightningd/plugins.
 
-For a less reckless experience, you can encrypt the HD wallet seed: see [HD wallet encryption](doc:backup-and-recovery#hsm-secret-backup).
+For a less reckless experience, you can encrypt the HD wallet seed: see [HD wallet encryption](doc:backup#hsm-secret-backup).

doc/contribute-to-core-lightning/coding-style-guidelines.md

@@ -30,9 +30,9 @@ We have to stop somewhere.  The two tools here are extracting deeply-indented co
 }
 ```
 
-## Tabs and indentaion
+## Tabs and indentation
 
-The C code uses TAB charaters with a visual indentation of 8 whitespaces.  
+The C code uses TAB characters with a visual indentation of 8 whitespaces.  
 If you submit code for a review, make sure your editor knows this.
 
 When breaking a line with more than 80 characters, align parameters and arguments like so:

doc/contribute-to-core-lightning/coding-style-guidelines/writing-json-schemas.md

@@ -17,7 +17,7 @@ Similarly, if you deprecate a field, add "deprecated": "VERSION" (where VERSION
 ## How to Write a Schema
 
 Name the schema doc/schemas/`command`.json: the testsuite should pick it up and check all invocations of that command against it.
-The core lightning RPC commands use custom schema specification defined in [rpc-schema-draft](https://github.com/ElementsProject/lightning/doc/rpc-schema-draft.json).
+The core lightning RPC commands use custom schema specification defined in [rpc-schema-draft](https://github.com/ElementsProject/lightning/blob/master/doc/rpc-schema-draft.json).
 
 I recommend copying an existing one to start. If something goes wrong, try tools/fromscheme.py doc/schemas/`command`.json to see how far it got before it died.
 

doc/contribute-to-core-lightning/release-checklist.md

@@ -20,7 +20,7 @@ Here's a checklist for the release process.
 
 1. Make sure any `CHANGELOG.md` changes from point releases have been imported.
 2. Use `devtools/changelog.py` to collect the changelog entries from pull request commit messages and merge them into the manually maintained `CHANGELOG.md`. This does API queries to GitHub, which are severely ratelimited unless you use an API token: set the `GH_TOKEN` environment variable to a Personal Access Token from https://github.com/settings/tokens
-3. Check that `CHANGELOG.md` is well formatted, ordered in areas, covers all signficant changes, and sub-ordered approximately by user impact & coolness.
+3. Check that `CHANGELOG.md` is well formatted, ordered in areas, covers all significant changes, and sub-ordered approximately by user impact & coolness.
 4. Manually remove any entries which were mentioned for in the previous point releases (they will be duplicates!)
 5. Create a new CHANGELOG.md heading to `v<VERSION>rc1`, and create a link at the bottom. Note that you should exactly copy the date and name format from a previous release, as the `build-release.sh` script relies on this.
 6. Update the package versions: `uv run make update-versions NEW_VERSION=v<VERSION>rc1`
@@ -71,7 +71,7 @@ Here's a checklist for the release process.
 7. Run `tools/build-release.sh bin-Fedora bin-Ubuntu sign` (with `--sudo` if you need root to run Docker) to:
    - Create reproducible zipfile
    - Build reproducible Fedora image
-   - Build reproducible Ubuntu-v20.04, Ubuntu-v22.04 and Ubuntu-v24.04 images. Follow [link](https://docs.corelightning.org/docs/repro#building-using-the-builder-image) for manually Building Ubuntu Images.
+   - Build reproducible Ubuntu-v22.04, Ubuntu-v24.04 and Ubuntu-v26.04 images. Follow [link](https://docs.corelightning.org/docs/repro#building-using-the-builder-image) for manually Building Ubuntu Images.
    - Build Docker images for amd64 and arm64v8. Follow [link](https://docs.corelightning.org/docs/docker-images) for more details on Docker publishing.
    - Create and sign checksums. Follow [link](https://docs.corelightning.org/docs/repro#co-signing-the-release-manifest) for manually signing the release.
 8. If you used `--sudo`, the tarballs may be owned by root, so revert ownership if necessary: `sudo chown ${USER}:${USER} *${VERSION}*`
@@ -101,7 +101,7 @@ Here's a checklist for the release process.
 
 1. Create a PR to update:
   * `Makefile`: variables CLN_NEXT_VERSION and CLN_PREV_VERSION (this may break tests as deprecated things are disabled!)
-  * `tools/lightningd-downgrade.c`: to downgrade to the just-released version.
+  * `tools/lightning-downgrade.c`: to downgrade to the just-released version.
   * `.github/workflows/ci.yaml`: change old-cln to download the just-released version.
   * `.github/PULL_REQUEST_TEMPLATE.md` for important dates for the next release.
 2. Look through PRs which were delayed for release and merge them.

doc/developers-guide/app-development/grpc.md

@@ -102,7 +102,7 @@ Notice that we override the expected SSL name with `cln`. This is required becau
 
 We then use the channel to instantiate the `NodeStub` representing the service and its methods, so we can finally call the `Getinfo` method with default arguments.
 
-### Generating custom certificates (optional)
+### Generating custom certificates
 
 The automatically generated mTLS certificate will not know about potential domains that it'll be served under, and will chose a number of other parameters by default. If you'd like to generate a server certificate with a custom domain, you can use the following:
 

doc/developers-guide/app-development/json-rpc.md

@@ -4,8 +4,8 @@ slug: json-rpc
 privacy:
   view: public
 ---
-> 📘 
-> 
+> 📘
+>
 > Used for applications running on the same system as CLN.
 
 ## Using `lightning-cli`
@@ -38,9 +38,9 @@ This will add links to the library into your environment so changing the checked
 
 Check out the following recipes to learn how to use pyln-client in your applications.
 
-🦉 **[Write a program in Python to interact with lightningd](https://docs.corelightning.org/v1.0/recipes/write-a-program-in-python-to-interact-with-lightningd)**
+🦉 **[Write a program in Python to interact with lightningd](https://docs.corelightning.org/recipes/write-a-program-in-python-to-interact-with-lightningd)**
 
-🦉 **[Write a hello-world plugin in Python](https://docs.corelightning.org/v1.0/recipes/write-a-hello-world-plugin-in-python)**
+🦉 **[Write a hello-world plugin in Python](https://docs.corelightning.org/recipes/write-a-hello-world-plugin-in-python)**
 
 ## Using Rust
 

doc/developers-guide/app-development/rest.md

@@ -7,17 +7,17 @@ privacy:
 
 # CLNRest
 
-CLNRest is a lightweight Rust-based built-in Core Lightning plugin (from v23.08) that transforms RPC calls into a REST service. 
-It also broadcasts Core Lightning notifications to listeners connected to its websocket server. By generating REST API endpoints, 
+CLNRest is a lightweight Rust-based built-in Core Lightning plugin (from v23.08) that transforms RPC calls into a REST service.
+It also broadcasts Core Lightning notifications to listeners connected to its websocket server. By generating REST API endpoints,
 it enables the execution of Core Lightning's RPC methods behind the scenes and provides responses in JSON format.
 
 An online demo for the REST interface is available at [REST API REFERENCE](ref:get_list_methods_resource).
 
 > 📘 Pro-tip
-> 
+>
 > [REST API REFERENCE](ref:get_list_methods_resource) can also be tested with your own server.
 >
-> By default, the base URL is set to connect with the Blockstream-hosted regtest node. 
+> By default, the base URL is set to connect with the Blockstream-hosted regtest node.
 >
 > However, it can be configured to connect to your own cln node as described below:
 >
@@ -45,13 +45,13 @@ If `clnrest-port` is not specified, the plugin will disable itself.
 - --clnrest-certs: Defines the path for HTTPS cert & key. Default path is same as RPC file path to utilize gRPC's client certificate.
 If it is missing at the configured location, new identity will be generated.
 
-- --clnrest-csp: Creates a whitelist of trusted content sources that can run on a webpage and helps mitigate the risk of attacks. 
+- --clnrest-csp: Creates a whitelist of trusted content sources that can run on a webpage and helps mitigate the risk of attacks.
 Default CSP:
 `default-src 'self'; font-src 'self'; img-src 'self' data:; frame-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline';`
 Example CSP:
 `clnrest-csp=default-src 'self'; font-src 'self'; img-src 'self'; frame-src 'self'; style-src 'self'; script-src 'self';`.
 
-- --clnrest-cors-origins: Define multiple origins which are allowed to share resources on web pages to a domain different from the 
+- --clnrest-cors-origins: Define multiple origins which are allowed to share resources on web pages to a domain different from the
 one that served the web page. Default is `*` which allows all origins. Example to define multiple origins:
 
 ```
@@ -65,14 +65,14 @@ clnrest-cors-origins=https?://127.0.0.1:([0-9]{1,4}|[1-5][0-9]{4}|6[0-4][0-9]{3}
 
 ## Server
 
-With the default configurations, the Swagger user interface will be available at https://127.0.0.1:3010/. 
+With the default configurations, the Swagger user interface will be available at https://127.0.0.1:3010/.
 The POST method requires `rune` header for authorization.
 
-- A new `rune` can be created via [createrune](https://docs.corelightning.org/reference/lightning-createrune) or the list of 
-existing runes can be retrieved with [showrunes](https://docs.corelightning.org/reference/lightning-showrunes) command.
+- A new `rune` can be created via [createrune](https://docs.corelightning.org/reference/createrune) or the list of
+existing runes can be retrieved with [showrunes](https://docs.corelightning.org/reference/showrunes) command.
 
-Note: in version v23.08, a parameter `Nodeid` was required to be the id of the node we're talking to (see `id (pubkey)` received 
-from [getinfo](https://docs.corelightning.org/reference/lightning-getinfo)). You can still send this for backwards compatibility, 
+Note: in version v23.08, a parameter `Nodeid` was required to be the id of the node we're talking to (see `id (pubkey)` received
+from [getinfo](https://docs.corelightning.org/reference/getinfo)). You can still send this for backwards compatibility,
 but it is completely ignored.
 
 ### cURL
@@ -83,7 +83,7 @@ With `-k` or `--insecure` option curl proceeds with the connection even if the S
 This option should be used only when testing with self signed certificate.
 
 ## Websocket Server
-Websocket server is available at `https://127.0.0.1:3010`. clnrest broadcasts notifications to all listeners. 
+Websocket server is available at `https://127.0.0.1:3010`. clnrest broadcasts notifications to all listeners.
 
 This websocket server requires a `rune` with at least `readonly` access for authorization. The default method used
 for current validation is `listclnrest-notifications`. User can either provided a rune with minimum `readonly`

doc/developers-guide/deprecated-features.md

@@ -46,7 +46,7 @@ Types of deprecation:
 For each deprecation:
 1. The deprecation is listed here, and in the CHANGELOG.md file.
 2. We try to give at least 2 versions before removal.
-3. Then one version where we issue a warning message if we detect a deprecated feature being used (not possible for deprecatred `Field` types).
+3. Then one version where we issue a warning message if we detect a deprecated feature being used (not possible for deprecated `Field` types).
 4. At least one version where the deprecated feature can be explicit re-enabled using `i-promise-to-fix-broken-api-user=FEATURENAME`.
 
 

doc/developers-guide/plugin-development.md

@@ -10,7 +10,7 @@ privacy:
 ---
 Plugins are a simple yet powerful way to extend the functionality provided by Core Lightning. They are subprocesses that are started by the main `lightningd` daemon and can interact with `lightningd` in a variety of ways:
 
-- **[Command line option passthrough](doc:a-day-in-the-life-of-a-plugin)** allows plugins to register their own command line options that are exposed through `lightningd` so that only the main process needs to be configured. Option values are not remembered when a plugin is stopped or killed, but can be passed as parameters to [`plugin start`][lightning-plugin].
+- **[Command line option passthrough](doc:a-day-in-the-life-of-a-plugin)** allows plugins to register their own command line options that are exposed through `lightningd` so that only the main process needs to be configured. Option values are not remembered when a plugin is stopped or killed, but can be passed as parameters to rpc command [`plugin start`](ref:plugin).
 - **[JSON-RPC command passthrough](doc:json-rpc-passthrough)** adds a way for plugins to add their own commands to the JSON-RPC interface.
 - **[Event stream subscriptions](doc:event-notifications)** provide plugins with a push-based notification mechanism about events from the `lightningd`.
 - **[Hooks](doc:hooks)** are a primitive that allows plugins to be notified about internal events in `lightningd` and alter its behavior or inject custom behaviors.