Global Feed Post Login
Replying to Avatar bumi

The spec says the description hash is used to commit to an associated description that is over 639 bytes.

things might accidentally work because the length is long enough.

(For me having the length decide on either storing a human readable string in a description or a hash for machines using the lengths of the string does not really makes sense - the app should explicitly choose. but that's how it is there.)

LDK, Phoenixd both don't support setting the description hash.

From what I heard LDK might support setting the description hash for long descriptions (as the spec says).

but that's also annoying for implementations (as discussed in the LNURL case) For plain LNURL the description hash requirement was dropped because of that.

This also means no human readable description can be passed along (that would be shown to the sender) (because it's either or)

Avatar
bumi 1y ago

do you know any other nostr client that does that validation?

Reply to this note

Please Login to reply.

Discussion

Avatar
jb55 1y ago

If it’s really that big of a pita I can remove the check, it’s not a huge deal i guess since the bolt11 can be faked anyway. As long as the zap request is there …

at this rate there is very little point for the bolt11 to even be in the zap, we should move to just use an amount field instead. This would generalize it to other protocols.

Thread collapsed