The fault is of LDK?
It's not. Darth just doesn't understand and he contributes things he doesn't know to being LDK problems when it's Lightning problems.
Good point, if they can control isn't non custodial wallet anymore
Read the post. It's concerning zaps only and we don't control it. This is client side software. Feel free to fork it and run it yourself: https://github.com/MutinyWallet/mutiny-node/commit/c8c8eb975f593ab3eba1fb34b516514836e46ea2
It's concerning zaps only and we don't control it.
Why don't you (instead of Zeus) change from LDK to other implementation? You see how is this?
reply
It's concerning zaps only and we don't control it.
Ok.
reply
I had no problem zapping 10-100 sats from my other nodes (CLN and LND) to Zeus users. Even if is concerning, you should not limit users ability to do whatever they want. That means control. That means is not non-custodial anymore.
reply
Because you're running an always online node. I have no problems zapping them either, but given enough time offline, there IS problems with locked payments especially from offline mobile wallets.
Even if is concerning, you should not limit users ability to do whatever they want.
Learn to read.
reply
I read. Is not limited to other normal invoices, only to zaps. is still limiting, that means still censoring...
reply
I support Mutiny's censorship because it is a sensible default behavior for a mobile node which users can change if they don't like it. It is worth noting that once you define censorship as "auto-failing some payments" (which I think is a perfectly fine definition btw) then all lightning nodes perform some censorship.
LND autofails (censors) payments to yourself by default, but users can configure it to allow them. CLN autofails opening a second channel to the same destination by default, but users can configure it to allow it. Now Mutiny node autofails payments to a known source of hodl invoices by default, but once again, users can change it if they want to.
Setting reasonable defaults for users is good and necessary. I am glad Mutiny makes it something you can change if you don't like their default. They are trying to give users a default setting that doesn't result in a lot of force closures on mobile. That is smart. Good on them.
Maybe someday mobile nodes will be able to safely make async payments. When that happens, I hope they will allow them by default. But today is not that day -- async payments are not spec conformant right now and for mobile nodes they are dangerous. I for one applaud Mutiny for finding a reasonable solution in the interim. And I for one want to work on a better solution for the long term.
reply
I think it should be from Zeus side to limit zaps over Zeus pay, not Mutiny limiting payments to Zeus LSP... In the end Zeus is responsible for holding those sats until the Zeus user is coming online. Mutiny it just sends out.
Again, I consider this a dangerous precedent from Mutiny side.
Anyways, this happen because of the crazy idea with zaps over nostr... quite stupid idea.
reply
I think it should be from Zeus side to limit zaps over Zeus pay
The recipient does not know who the sender was, so it is much harder to implement censorship on the recipient's side
not Mutiny limiting payments to Zeus LSP
Mutiny is the wallet that cannot safely pay hodl invoices. To me, the responsibility to "do something" about it is on them, and disabling payments at least until a long term solution is available <-- that is, imo, a perfectly reasonable step to take. Otherwise their users lose funds.
I consider this a dangerous precedent from Mutiny side
I think it is smart at least as a short term solution. If a way to make these payments safe on mobile is thought of then I will support them re-enabling them by default. But right now it isn't safe. Disabling something unsafe -- by default, with an option to change it for those who know the risks -- seems like a good precedent to me.
reply