Receiving an escrow message in the client must be more reliable.

[rodant]

An escrow message is the content string of a nostr event. This string get parsed assuming it is a JSON serialization of a certain type, but a client can receive a message of an unexpected type. For example it can receive a cashu token instead of an escrow registration producing errors.

Make receiving escrow message type safe somehow. Idea: introduce an enum type for the different escrow messages.

[rodant]

On subscription setup the nostr client delivers the events it has in reverse chronological order, newest event first. It means in some situations at a certain time the event received isn't the one the escrow client is willing to get, but this event must be eventually read afterwards. For these reason we need some kind of caching in the nostr client to push back events needed later on and to be able to process events already received from the nostr network.

[rodant]

On subscription setup the nostr client delivers the events it has in reverse chronological order, newest event first. It means in some situations at a certain time the event received isn't the one the escrow client is willing to get, but this event must be eventually read afterwards. For these reason we need some kind of caching in the nostr client to push back events needed later on and to be able to process events already received from the nostr network.

The assumption that the events are delivered in inverse chronological order seems to be wrong, as testing has shown. But the rest of the reasoning for this issue still holds for a more robust behavior.