Instead of having a half dozen message codes, just use a single BOLT-level code. Inside the payload of the message, the first two bytes are the big-endian peerswap-level code.
i.e. instead of swap_in_request= 42069, swap_in_agreement = 42073, etc. just use a single peerswap_message = 42069. Then define swap_in_request = 0, swap_in_agreement = 1 etc. but in the peerswap-level message code that is in the first 2 bytes of the BOLT-level message payload.
This is mostly just to "be nice" to the rest of the ecosystem, and should probably be encouraged as a rule for all extensions of BOLT spec, not just peerswap. This makes it more likely that two different extensions will not inadvertently overlap, and if two extensions do overlap, it would be trivial for one or both of them to switch just one message code. In the future, this also makes it easy to add new message types as the protocol evolves (we would have a 16-bit codespace to ourselves, instead of sharing a common 16-bit codespace with the formal BOLTs and with other extensions); there is no need to coordinate with developers of other extensions over the BOLT spec to allocate more new message codes.
On the other hand this is a pretty big break in the protocol tho, fine if you want to close this issue instead.
Instead of having a half dozen message codes, just use a single BOLT-level code. Inside the payload of the message, the first two bytes are the big-endian peerswap-level code.
i.e. instead of
swap_in_request= 42069,swap_in_agreement= 42073, etc. just use a singlepeerswap_message= 42069. Then defineswap_in_request= 0,swap_in_agreement= 1 etc. but in the peerswap-level message code that is in the first 2 bytes of the BOLT-level message payload.This is mostly just to "be nice" to the rest of the ecosystem, and should probably be encouraged as a rule for all extensions of BOLT spec, not just peerswap. This makes it more likely that two different extensions will not inadvertently overlap, and if two extensions do overlap, it would be trivial for one or both of them to switch just one message code. In the future, this also makes it easy to add new message types as the protocol evolves (we would have a 16-bit codespace to ourselves, instead of sharing a common 16-bit codespace with the formal BOLTs and with other extensions); there is no need to coordinate with developers of other extensions over the BOLT spec to allocate more new message codes.
On the other hand this is a pretty big break in the protocol tho, fine if you want to close this issue instead.