The clean answer I would give that dev is: Lightning cannot currently make "many independent nodes act as one node" in the way an alt-L1 validator set might act as one logical validator.
Why: on Lightning, a node is identified by one node pubkey, and channels are two-party contracts tied to channel state, HTLC updates, commitment transactions, penalties, gossip, and liquidity at that node. If several machines all present as the same LN node, they must share the node key and perfectly synchronized channel state. That is possible as an HA/cluster engineering problem, but it is not decentralized: it becomes one logical operator with shared secrets or a threshold signer.
These are closer to "many users share some on-chain/channel infrastructure".
They can reduce channel count and improve UX, but they are not the same as multiple independent LN nodes merging into one BOLT node today.
Nostr Wallet Connect / LNbits / app wallets
Good prototype route: give every app user a wallet/account, but keep the actual Lightning complexity in an LND/CLN backend or an LSP.
This does not extend LN at the protocol layer; it extends access to LN.
My recommendation to the dev:
If you mean "I want many machines to make one reliable Lightning node," build an HA Lightning node with remote/threshold signing and very conservative state replication.
If you mean "I want a decentralized client where many participants can pay/receive over Lightning without each running channels," look at Fedimint or Cashu plus multiple Lightning gateways.
If you mean "I want to add capacity/routing to Lightning," run multiple normal LN nodes and coordinate liquidity at the service layer. Do not try to hide them as one node unless you accept that it is one logical custodian/operator.
The key sentence: Lightning is already decentralized at the graph level; trying to make a sub-graph masquerade as one node usually removes the part that makes it decentralized. A federation or mint can be a good UX layer, but it is a trust-model tradeoff, not free protocol-level node merging.
The clean answer I would give that dev is: Lightning cannot currently make "many independent nodes act as one node" in the way an alt-L1 validator set might act as one logical validator.
Why: on Lightning, a node is identified by one node pubkey, and channels are two-party contracts tied to channel state, HTLC updates, commitment transactions, penalties, gossip, and liquidity at that node. If several machines all present as the same LN node, they must share the node key and perfectly synchronized channel state. That is possible as an HA/cluster engineering problem, but it is not decentralized: it becomes one logical operator with shared secrets or a threshold signer.
So I would split the design space this way:
My recommendation to the dev:
If you mean "I want many machines to make one reliable Lightning node," build an HA Lightning node with remote/threshold signing and very conservative state replication.
If you mean "I want a decentralized client where many participants can pay/receive over Lightning without each running channels," look at Fedimint or Cashu plus multiple Lightning gateways.
If you mean "I want to add capacity/routing to Lightning," run multiple normal LN nodes and coordinate liquidity at the service layer. Do not try to hide them as one node unless you accept that it is one logical custodian/operator.
The key sentence: Lightning is already decentralized at the graph level; trying to make a sub-graph masquerade as one node usually removes the part that makes it decentralized. A federation or mint can be a good UX layer, but it is a trust-model tradeoff, not free protocol-level node merging.