Cool to see them surface. They've been building in the LDK ecosystem since about the same time we were. Except on hard mode with no-std in an SGX environment. You think running in the browser is hard lmao.
It's basically greenlight but the user keys are in an SGX server. I don't know how you prove that they are secure or that they are operating it in that way. Also you gotta trust SGX and there's been many SGX fail research. I don't know what is FUD or not.
The nodes are cheap to manage tho since LDK is incredibly lightweight. So they can always run, unlike with greenlight (unless they're working on making that scale better). So you can have more "offline receive" potential. Think of this as a less or more (depends on your assessment) trusted voltage with a wallet interface.
reply
Oh so it’s like ACINQ’s system as a service with a wallet interface?!
reply
I think the difference here. Is that for ACINQ its how they urn their LSP. In this case its for your individual node tied to your mobile app. This is cool approach and great that they have open sourced it and documented so well.
reply
I'm not sure what you mean by acinq system as a service.
reply
reply
Oh nice didn't realize that. Yeah basically! At least as far as the keys go I think. They do a lot of other distributed systems kind of stuff to the rest of the "node" too.
reply
What's SGX? A bit of googlign turned up no obvious answer.
reply
reply
Apparently this can receive offline. It sounds like the node is remotely hosted though:
Hosting your own Lightning node can be time consuming. Forget about channel configuration, liquidity balancing, and server maintenance; we'll handle it for you so you can focus on what matters.
... so it probably uses remote signing. It is built with LDK.1

Footnotes

reply
Isnt that bolt12 in action?
reply
I have bolt12 options in my CLN node now but it doesn't seem to be integrated into Phoenix, Breez, or Mutiny yet...any mobile lightning apps out there that support it that you are aware of?
reply
What is?
reply
The ability to receive payment even when the node is offline.
In typical nodes, your node has to stay online to communicate with the sender and be able to auto generate an invoice.
Bolt12 does that even if the sender cant communicate live with the receiver node.
reply
Where did you read that?
afaik bolt12 does not solve the offline receive problem. It solves the lack of static invoice problem, but it still needs to ask the receiving node for a bolt11 invoice before it can pay the node. I could be wrong though.
reply
Some of the tech behind bolt12 will help enable offline receives but no, bolt12 as it is does not help receiving offline. It just handles the static invoice part.
reply
Oh, you are right. You will receive the payment when you go online, i believe. But you dont need to be online to provide an invoice. Thats how i understand it.
reply
If your node is offline, does bolt12 allow you to send a payment to that node? I don't think it does. iirc Your node needs to be online to provide the underlying bolt11 invoice as a response to a bolt12 request.
reply
Really looking forward to the android version! I want to test it
reply
Bolt12 cloudified. Centralized. Trusted.
Who could have seen this coming?
reply
Keeping your sats on a lighting node that is being managed by someone else is not self custody. The hosting company can rug all the nodes they manage just as easily as any custodied wallet provider. Totally pointless IMO.
reply
deleted by author
reply