Solving compatibility issues between ASB and CLI

[da-kami]

With #490 we add blockchain network information to the spot price protocol to be able to check that both ASB and CLI are connected to the same blockchain network on Bitcoin and Monero.
This is not really what this protocol is intended for.

I propose to add an additional protocol that can be used for compatibility check. Such a protocol could go further with what checks are run:

• Blockchain Network (ensure compatible blockchain networks)
• Commit hash (i.e. ensure compatible version of ASB an CLI)

Not sure if it would be better to pack that into one protocol or create multiple - @thomaseizinger your input would be great.

One additional comment: @thomaseizinger and me discussed how to generally solve ensuring the correct network for messages exchanged during a swap. One idea was to add a byte prefix to each message that would encode the network. This would ensure that both parties are on the same network - otherwise we would receive a deserialization error.

I like the current version where we send back a specific error (including the networks) that is user friendly. A separate protocol can achieve the same thing, but I am wondering if we should explore more ideas (as in network prefix).

[thomaseizinger]

* i.e. ensure compatible version of ASB an CLI

We should explore how we can use libp2p's versioning of protocols here. Most certainly, we should not tie compatibility to commit hashes but exercise proper (semantic) versioning.

Should take a look at libp2p's identify protocol: https://docs.rs/libp2p-identify/0.29.0/libp2p_identify/struct.IdentifyInfo.html

Should definitely take a look at how polkadot and Eth2 solve these issues. They both use libp2p and should run into the same problem.

Generally, these "checking once and then relying that it doesn't change"-kind of designs are not particularly nice because things can change obviously which means a design that implies the check on every message is superior. It also easier to understand because there is less implicit "state" throughout the entire communication.

I like the current version where we send back a specific error (including the networks) that is user friendly. A separate protocol can achieve the same thing, but I am wondering if we should explore more ideas (as in network prefix).

A byte-prefix can also achieve the same thing. You just need to handle it gracefully instead of "expecting" a certain value and blowing things up if it is a different one.

[binarybaron]

Additionally, please consider making the network and version of the ASB available via the JSON bid-quote protocol. This way it can be easily used by indexers / applications built on top of it.

[binarybaron]

I agree. My point was more that this information should be easily queryable by other software and not hidden in some kind of handshake that uses a binary format and is very hard to parse (think browsers)

[thomaseizinger]

In line with HTTP user agent strings (which is what the agentVersion field in identify is based on), we could do something like:

asb/0.8.0 (Mainnet)

A PR adding /identify with these details is likely going to be accepted.

[binarybaron]

Sound good to me, I didn't know there was a standard field for that.

[thomaseizinger]

To be precise, I am talking about this component: https://docs.rs/libp2p/0.38.0/libp2p/identify/index.html

[binarybaron]

It is also natively supported by most LibP2P implementations (go, js). I won't be able to tackle this problem myself as my Rust knowledge is not that far yet. Would be great if someone could find the time do it though 👍