NOTE: This implementation saves secrets to disk! It is not
secure.
The storage API allows the caller to atomically record the state
of the protocol. The user can retrieve this recorded state and
re-commence the protocol from that point. The state is recorded
using a hard coded key, causing it to overwrite the previously
recorded state. This limitation means that this recovery
mechanism should not be used in a program that simultaneously
manages the execution of multiple swaps.
An e2e test was added to show how to save, recover and resume
protocol execution. This logic could also be integrated into the
run_until functions to automate saving but was not included at
this stage as protocol execution is currently under development.
Serialisation and deserialisation was implemented on the states
to allow the to be stored using the database. Currently the
secret's are also being stored to disk but should be recovered
from a seed or wallets.
We model the getting of amounts as a network behaviour even though conceptually
it is a protocol. Refine/refactor the code a bit to make this more obvious.
- Use `Amounts` instead of `Messenger`
We only ever connect to a single peer, update peer tracker to reflect this. This
is a single patch because the handling of the two network behaviours is a
intertwined.
- Only track one peer connection
- Track the peer id and the multiaddr of the counterparty
- Emit an event for connection established on Alice's side as well as Bob's side
- Make it the same for Alice and Bob.
- Make it contain a wallet client instead of the `Monero` struct.
Also:
Remove `Container` from inside `Monero` struct. The caller of `new`
can simply ensure that `Container` is not dropped to keep the
container alive.
This makes the `Monero` struct easier to work with, as it just holds
the data necessary to create the different clients created during
`init`, and does not have any lifetime restrictions.
