Use byte encoded Lightning messages rather than json encoding

[remyers]

This specification could be improved by using byte encoding for Lightning messages instead of JSON encoded payloads. This would make the specification more precise, faster to parse and require less space to transmit and store messages. Current Lightning messages use byte encodings for this reason and all Lightning implementations implement codecs for handling byte encodings. Using an encoding format familiar to reviewers of current Lightning messages should also help increase feedback and facilitate eventual adoption.

This is a big change, but should help with the evolution and adoption of PeerSwap.

For example, the swap_in_request message as currently described looks like:

1. type: 42069
2. payload json encoded:

{
  protocol_version: uint64,
  swap_id: string,
  asset: string,
  network: string,
  scid: string,
  amount: uint64,
  pubkey: string
}

An example of this message described with byte encoding based on the fundamental Lightning types might look something like the following:

1. type: 42069 (swap_in_request)

2. data:

   • [u16:protocol_version]
   • [u32:swap_id]
   • [chain_hash:network]
   • [short_channel_id:short_channel_id]
   • [u64:amount]
   • [point:pubkey]
   • [request_tlvs:tlvs]

3. tlv_stream: request_tlvs

4. types:

   1. type: 1 (asset_id)
   2. data:
      • [...*byte:data]

Note: network field indicates the chain_hash of the network used to create on-chain transactions, such as Bitcoin mainnet or signet, but could also indicate a network such as Liquid.

The optional asset_id contains any network specific data needed for on-chain transactions.

[nepet]

Yes to this! There is already a draft for this change buried somewhere in an old local repo/branch. We already discussed a similar use of tlvs for better asset abstraction.

This allows to separate the "base" swap protocol from an asset specific protocol as they might diverge depending on the asset.

This is something I want to tackle as soon as we have a somewhat stable implementation.