Embrace libp2p and replace the frame concept with protocols

[thomaseizinger]

Currently, RFC001 defines the FRAME concept, with REQUEST and RESPONSE being possible frame types.

This originates from a time before we were using libp2p as our underlying messaging framework. The reason we originally introduced this concept was to allow for multiplexing and extensibility.

By having FRAMEs with different types, we would always be able to add more types and thus extend the protocol with more messages as new use cases come up.

However, while doing #92 I came to the conclusion that there is actually a simpler way of doing this, now that we use libp2p. Libp2p allows your application to define a set of protocols and connect to another node with the intention communicating via one of these protocols. Hence, instead of defining a general-purpose /comit/1.0.0 protocol I propose to define protcols like: /comit/swap/1.0.0.

This would have the following, positive implications:

• We can get rid of FRAME types, since we can always just define new protocols for new use cases. These protocols would define the necessary message types.
• We can get rid of the probably over-engineered header concept. Within the /comit/swap/1.0.0 protocol, we can define that the only valid message is what we now call a SWAP REQUEST but without all the "wrapping" aspects of FRAMEs and REQUESTs. All these semantics are defined as part of implementing the /comit/swap/1.0.0/ protocol.
• This also allows us to drop the "MUST-understand/MAY-ignore" concept. Want to make breaking changes to the messaging format? Increment the version to /comit/swap/2.0.0/`.
• Are not bound to using JSON for all messages. New protocols can use whatever encoding they like and see fit.

This sounds all great but there is also a downside: If we get rid of the over-arching concepts like FRAMEs and the fact that all messages use JSON, we can no longer that easily do stuff like CLOSE-frames #116. However, maybe we don't even need that? All the error cases described in there are either gone (frames no longer exist, so there is no more unknown frame type for example) or could possibly be redundant for other protocols (a protocol using protobuf cannot have "bad frame" in the sense of malformed JSON).

How to move forward:

• The scope of RFC001 would be limited to

  • describing the network stack (that we use libp2p)
  • the "architecture" of using different protocols for different usecases
  • that all protocols are scoped under /comit/*

• RFC002 would change to describing the /comit/swap/1.0.0 protocol

  • Describe the encoding (single-line JSON that is newline-delimited)
  • Describe communication pattern (request/response)
  • Describe the object shape If we drop the headers/body thing (which is probably overkill for a single protocol), we probably have to slightly rethink, how the protocol-specific data is represented (since it changes based on other data) but that is not a blocking issue for the whole proposal.

We might even go as far as having a /comit/swap/rfc003 protocol but that will need further discussion. RFC002 could describe the "family" of swap protocols as /comit/swap/* where we define common things like the alpha_ledger etc terminology. The name of the protocol could make more sense if we follow this idea and come up with a proper name for "rfc003:/comit/swap/foobar/1.0.0` assuming "foobar" is a good name :upside_down_face:

Summary:

The whole approach feels much more "natural" to libp2p and frees us from defining and caring about many aspects of the communication layer. Most of the work is in the form of "future-proofing" anyway, which we don't have to do if we define a new "protocol" for each use-case.

[da-kami]

Love it.

[tcharding]

And me.

[thomaseizinger]

Just had another insight: The proposal above is also nice because it favors composition over inheritance (a problem that has already been identified here).

Instead of creating abstractions that all further protocols have to adhere to, we only set boundaries (must be a libp2p protocol).

[thomaseizinger]

Another idea regarding what the individual RFCs would define:

001: Tech stack: libp2p, tcp, secio, etc 002: Define only a language for atomic swaps (alpha/beta, ledger, asset, swap protocols): 003: Define an HTLC-based atomic swap, define the libp2p-protocol string, define the messages that need be exchanged, including the format (JSON f.e.)

[thomaseizinger]

We did agree that we want to go for this, but no immediate action can be taken as part of this issue. Hence, I will close as it can still be referred to for future implementations.