What if the relay has an outdated record? In a multiple-relay scenario the client might have the latest state synchronized from multiple relays, but the relay that has outdated info will not allow "force push".
Otherwise can you explain how a nip60 wallet get rekt exactly from a race condition? Token events are not replaceable.
I found these scenarios to be problematic:
- relays deleting token events
- app not being able to publish new token events (signing and publishing are async), especially nutzaps
- nutzaps getting lost on relays
- spent tokens disrupting user-experience (unexpected change in balance)
So state management is an issue with Nostr wallets, and precisely that is why SatShoot went the NUT13 (and perhaps later NUT14) way - with the seed based wallets you get double protection:
1. Nostr stores your state on relays so even if you lose the seed you can swap to a different one. Mitigates losing local state as well
2. The NUT13 seed protects from relays deleting, censoring or losing your nsec - an additional hedge on nostr state. Like a recovery code to an account. nostr:nprofile1qqs8rheprycaymhyzysa99dag09u0cuz2p0rxw6uz02qzm8dj4pdn4cpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszgrhwden5te0dehhxarj9ejkjmn4dej85ampdeaxjeewwdcxzcm99uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59u2ftwvn extended the nip60 spec so the NUT13 counter can also be synchronized to nostr.
NUT14 is important because it makes in-flight payment state atomic. If the nutzap is not redeemed the money is not lost.
Sadly, I haven't found well-maintained apps with nip60-61. A few apps use it with outdated specs and none of them work with the latest spec, using both nip60 and 61, other than #SatShoot
