hodlbod

> Maybe we can make the invoice optional and the URL the message's identifier? I would be fine with this. To justify the generalization though, it would allow relays to...

I can't tell if you're being sarcastic, but yes haha that sounds fine. Although I would again not call it interrupt_user, since it's not necessary to make it an interruption....

Interesting point. Why do we need to add this to the spec then? A relay could send a NIP 24 DM from the relay's pubkey specifying payment details (or we...

How is this different from NIP 26? I would like users to be able to log in as a separate pubkey, but without revealing their identity, which this doesn't support....

@frbitten it would also be easier to automate. I'm working on a feature that shows publish failures, and it gets clogged up because fiatjaf's relay rejects kind 7s.

If there were an e-cash specific nostr event kind, you could just use NIP 89. You could even make up a fake kind and use that to signal ecash mint...

I see, maybe this is different enough from NIP 89 to warrant a new nip. You could add a new `mint_url` tag or something though.

> What is the reasoning for that, if it's just a fixed value then it doesn't really have any meaning. May as well assign meaning to it. Just in response...

I'm fine with this change, but I still think switching to better primitives for editing lists would be preferable. If we're keeping all updates anyway, the argument against add/remove events...

Read optimizations can be supported by DVMs, race conditions having to do with writes can't be fixed without changing the event format.