Look into CLINK for that, maybe it could help in your project.

CLINK Protocol Demo

A live demonstration of CLINK (Common Lightning Interface for Nostr Keys), a Nostr-native protocol for Lightning offers and debits.

anyway, repeating "lightning is complicated" isn't moving to the 80% solution part of the task. how do you solve the problem of the complexity of lightning network, is the right question IMO, the answer is making a BFT protocol with 50% byzantine resistance, and then using that protocol to coordinate lightning node replicas, who would get paid for faithful operation of their replica. and yes, replicas. if 100 people are sharing a single lightning node, that's some fierce downtime risk. if 100 people are sharing three, that's reducing that risk by 1/8th also, increasing the capabilities of the onion routing of lightning will be critical. redundant atomic multi-path payments don't exist yet. we need fork and join operators and we need a mechanism for triggering a reversal once the first attempt succeeds, the others have to be rolled back immediately. that's just redundancy, solving the stuck payments problem. yes, it requires you to store an ample margin so you can effectively pay 3+ times as much but all but the first are returned. there is also other things that you can do with a few more onion routing primitive commands. you can split payments at the end of the path, you can create paths that push more in than they pull back out, so multiple parties get paid on the route. forks, joins, and reversals. there. lightning will eventually enable a replacement for Tor that actually scales too. i've built half of that already.

Are you imagining using something like FROST for signing lightning operations that are somehow enforced by the consensus system? So instead of having a single custodian or a federation you have a decentralized bunch that's running the lightning nodes and the end users have balances on this system instead