UncleSamtoshi

I think it makes sense to be redundant in our data and be as clear as possible. This would allow for flexibility in how we display the tx to the...

@tarcon What was the problem you were encountering with just reinitializing the client each time?

> @tarcon What was the problem you were encountering with just reinitializing the client each time? You can ignore this as I misread your earlier message and missed that you...

> But regardless, why couldn't the client just generally accept any validly formatted payto URI? I also don't see why a client cannot just generally accept any validly formatted payto...

For context, I am interested in this NIP, because I want to improve the zap experience by having zap invoices be automatically paid instead of having to switch to your...

> @UncleSamtoshi yeah I had been thinking about similar experiences being built on top of this NIP, namely an event type for logging when a user sends a payment to...

> Looks good to me. Only comment left is, I wonder if it'll be easy to add a bats test for this For testing we could add the unhappy path...

One concern I have with this PR is we lose explicitly visibility into whether we actually paid out the reward. Previously the presence of a completed question implied that the...

> we should make sure that we can, through tracing, plot the query where rewards are given or not. This should be visible.

General approach looks good! I think the logic is correct, and it will actually delete the token from local storage however the code may require some type changes and name...