⚗️Review BAM/COMIT protocols post RFC1-3

[LLFourn]

Now that we have specified two RFCs which use BAM it would be good to investigate how well it solved the problems it was designed to and if are we using it in the right way.

A specific topic that must be addressed the design of and our use of status codes, particularly with regards to the "reason" headers. We had a discussion of this and there were multiple ideas that are simply here as a reminder.

1. We should use different status codes to represent every type of error including those that are related to the swap protocol parameters. e.g. timeouts-too-tight. We could partition them according to the "layer" they occurred to create some separation.
2. We should introduce a new type of status code e.g. NF** "negotiation failed" to indicate the proposed action was understood but was rejected.
3. The scope of RFC01 might be too big. Maybe some stuff should move into a more domain specific RFC.

Note this ticket isn't meant to imply that there is something wrong with the way things are now.

DoD:

• organise discussions around the topic
• organise decision

Blocked by #7

[D4nte]

To be moved to comit-network/RFCs once repo is open sourced

[thomaseizinger]

I'll put this one on hold, so here are my current thoughts:

The main design flaw seems to be that there is inheritance in place:

1. BAM defines FRAMES of type REQUEST
2. Further RFCs define types of REQUESTS and make use of concepts that are defined in BAM, like statuscodes. However, for their own purpose they need to extend this definition.

I am very confident that if we can figure out, how we can do composition instead of inheritance on a design level, this problem described in the beginning of this issue will be resolved.

Another way to put this is that the concepts defined in one RFC (like BAM) spawn multiple design documents. They define abstract concepts that are later specialized in other RFCs. If we were to define the protocol in a way that leaves the concepts within one document, the design would be cleaner which would probably solve the above mentioned problem.

I'll organize a discussion meeting to further dive into this.

[thomaseizinger]

@LLFourn and I had some very productive discussions about this yesterday. For historical purposes, I am posting the image here.

I'll submit a PR to the relevant RFCs as a follow-up of this that implements those changes.