Just wanted to say that I appreciated nostr:npub1zk6u7mxlflguqteghn8q7xtu47hyerruv6379c36l8lxzzr4x90q0gl6ef, nostr:npub1yaul8k059377u9lsu67de7y637w4jtgeuwcmh5n7788l6xnlnrgs3tvjmf, nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5 & nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s working together to squash a bug that was preventing #zaps to my nostr:npub1getal6ykt05fsz5nqu4uld09nfj3y3qxmv8crys4aeut53unfvlqr80nfm Lightning address from showing up on Damus. I’m back to fully self-custodial zaps again on my own node and it feels amazing.

Reply to this note

Please Login to reply.

Discussion

Oh i thought it was just me. Is there a writeup on what it was or how it was fixed?

Damus had dubious logic that would look for the zap request inside of a bolt11 description if it was a description invoice instead of a description hash invoice. Alby hub was creating description invoices and are not committing to the zap request. Damus did not handle this properly. I still think zap implementations should commit the zap request in the description hash, people have given up on validation of any sort except the nostrPubkey == zap pubkey. So yeah thats it in a nutshell if that makes any lick of sense.

That sucks, wish zaps had more auth too

just to mention this, this is not in Alby Hub's hands.

This is a limitation of LDK, Phoenixd, also with CLN there are implementation issues and setups like LNBits have issues with that, too.

https://github.com/lnurl/luds/pull/234

This is the dream