core-lightning/doc/schemas/sendcustommsg.request.json
Rusty Russell d7cc1e4a17 doc: Updated parameter descriptions for *.request.json
Added descriptions for rpc command parameters

This also performs the following fixes:
1. delforward parameters are compulsory (required).
2. disableinvoicerequest request added `added` field.
3. invoice request order fixed (label then description, not vice-versa!).
4. listpeers log levels are a proper enum
5. description parameter documented for sendonion requests.
6. deprecatred amount_msat removed from sendpay request.
7. sendpay request partid type fixed to u64 (was u16!)
8. sendpay request localinvreqid type tightened to hash (was hex)
9. sendpay request payment_metadata and description fields documented.
10. sendpsbt request reserve type fixed to u32 (was boolean)
11. utxopsbt request satoshi type fixed to msat_or_all (was msat)
12. withdraw request parameter satoshi is compulsory (required)
13. fundchannel_start request amount is sat, not msat_or_all.
14. openchannel_init request amount is sat, not msat
15. openchannel_init close_to is a string, not hex.
16: invoice labels can be strings OR numbers.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2024-03-19 14:58:59 +10:30

20 lines
1.3 KiB
JSON

{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"required": [
"node_id",
"msg"
],
"added": "v0.10.1",
"additionalProperties": false,
"properties": {
"node_id": {
"type": "pubkey",
"description": "the node specified by `node_id` must be a peer, i.e., it must have a direct connection with the node receiving the RPC call, and the connection must be established. For a method to send arbitrary messages over multiple hops, including hops that do not understand the custom message, see the `createonion` and `sendonion` RPC methods. Messages can only be injected if the connection is handled by `openingd` or `channeld`. Messages cannot be injected when the peer is handled by `onchaind` or `closingd` since these do not have a connection, or are synchronous daemons that do not handle spontaneous messages"
},
"msg": {
"type": "hex",
"description": "must be a hex encoded well-formed message, including the 2-byte type prefix, but excluding the length prefix which will be added by the RPC method. The message types may not be one of the internally handled types, since that may cause issues with the internal state tracking of Core Lightning. We do (as of *v23.11*) allow sending of even types, but note that peers (as per the spec) will disconnect on receiving unknown even types"
}
}
}