Well, one could wrap phoenixd and add it to the nostr client. Then we can start switching to bolt12, which has better privacy properties anyway.
Discussion
bolt12 is looking to become necessary for the latest lightning tech
Overall I think Acinq is doing some great stuff - channel splicing, trampoline routine, bolt12. The one architecture piece that's missing is how to make it really easy to switch to another LSP and ideally migrate your existing channels.
Something like greenlight may be the way?
And then something like the channel factories that nostr:nprofile1qqszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagpz4mhxue69uhkummnw3ezummcw3ezuer9wchszyrhwden5te0dehhxarj9ekk7mf0qy88wumn8ghj7mn0wvhxcmmv9uynmh4h is developing to make it cheaper to get channels...
I recently got sending and receiving working over lightning
I'm now integrating hedgehog payments so that anyone in any pool using my protocol can send asynchronous payments to anyone else as long as they are *also* in a pool using my protocol (and they don't even need to be in the *same* pool)
What is "pool" in this setup? My last understanding was that there is a single person P that we send sats to over lightning and they create channels for each of N of the people that send them sats. The benefit is that we pay only 1/N of the sats for onchain transaction and you get self custodial channel. Is that what you call a pool?
I think a diagram here would help 😉 Fwiw, slides software is actually really good at making diagrams - like Google Slides, or similar.
Your understanding is correct, but there are additional benefits. Since each user can create LN invoices and pay LN invoices, one member of the pool can create an invoice which another member of the pool then pays. The result is what you'd expect: money moves from one user of the pool to another. But the way I'm implementing it, the person P (from your description) acts as the routing node for these payments, and that person (who I call "the admin") does not charge a fee for "internal" in-pool payments. I also have him allow free payments to people in *other* pools as long as he manages those pools too. So once you get into the channel factory, you get free transactions to anyone else who used the same admin, and you *also* get to send and receive lightning payments.
And thanks to my hedgehog protocol, you can also send money to someone when they are offline, and you can then *go* offline because hedgehog works in such a way that the recipient of a hedgehog transaction (which is just text, you can get it from e.g. an email or a nostr dm) can redeem it even if the creator of that transaction went offline.
The way that works is this: the recipient has the preimage to a pending htlc created by the sender, and that pending htlc would, if broadcast, pay the admin, but only if the admin learns the preimage. Since the sender gave the preimage to the recipient (it's contained in the hedgehog transaction text), the recipient just contacts the admin and asks him to pay an invoice for the same amount as the pending htlc, locked to the same preimage. Which means the admin knows that if he pays the recipient's invoice, he will get reimbursed from the sender's htlc, even if the sender is offline.
Voila! Asynchronous payments that are free for anyone in any pool managed by the same admin (I call a collection of such pools a "metapool"), and you can use lightning if you want to pay someone *outside* your metapool.
Regarding a diagram, first I have to make it work! Lol
I'm happy all the hard parts are done, and I think I am within a few hours of finishing the integration of hedgehog payments. But I plan to release a video shortly and I will probably prepare a diagram for it. I also am presenting how this works at Bitcoin++ Floripa (https://btcplusplus.dev/conf/floripa) and showing developers how *they* can make it too. So I will probably have lots of educational material ready by then.
they are definitely leading the way. switching LSPs sounds like a pain.
I think that will make it easier in some regards, but ultimately most humans aren't going to manage their own liquidity. This includes buying it from LSPs. Even though that is easier, most won't do that.
I agree we should make easier abstraction for this. However, people are used to managing outbound liquidity, and linking their venmo or whatever to their bank and debit card, those are complicated things. Managing liquidity is inherent in all of that. The only difference w lightning is literally one step: manage inbound liquidity instead of just outgoing.