Egge on Nostr: I wonder what would be a better way to solve this issue… npub.cash will hold many ...

I wonder what would be a better way to solve this issue…

npub.cash will hold many many proofs for its users. If someone wants to withdraw, the server needs to send all those proofs over in a big response.

The obvious choice is to run clean up and consolidation jobs that merge proofs together, but once P2PK is adopted this will no longer work (as the server cannot do anything with the proofs)…

I’ll keep thinking about this, but maybe one of you has a bright idea ✌️

quoting note1gty…2k99

PSA: npub.cash just had a small change in its public API!

While /claim used to return a token containing all pending proofs, it now returns a token containing max. 100 proofs! Additionally there are two new keys in the payload:

- count: how many proofs are included
- total pending: how many proofs are pending in total for the user

This change makes sure that the token does not get too long for handling it and lets API users now if there are more proofs pending.

I am not perfectly happy with this yet and I will continue looking into other ways to handle these edge cases. 🫡💜