[EPIC] Message orientation design

Introduction

Some of the arguments to introduce message-orientation support in libp2p are well summarised in https://github.com/ipfs/go-ipfs/issues/6481.

The libp2p core team has started conceptualising and building proofs of concept to lay the groundwork for message-orientation. We're doing so addressing the ramifications at different layers of the libp2p model.

We're also keen to explore all the possibilities that open up in terms of transport agility, programmatic transport QoS definition, 0-RTT encrypted request messages, long-lived/virtual sessions, etc.

Design directions

Some of the ideas that are on the table currently:

• libp2p API for message-orientation, with programmatic QoS definition, such that the transport suite can vary based on the characteristics required by the user, e.g. μTP, Unreliable QUIC.
• Being sympathetic with the underlying transports. , e.g. leveraging 64k max. datagram size to send speculative initial request messages.
• Long-lived virtual sessions ("sessions" no longer consume kernel resources, so there's a whole world of possibilities here).
• Dealing with multiple message oriented transports.
• Non-interactive protocol agreement, where available. multiselect 2.0 (#205) as the unified protocol negotiation/selection mechanism for stream-oriented and message-oriented interactions.
• Security handshake, leveraging 0-RTT data: DTLS, Noise.
• Multiplexing / Multipacket protocol.
• Dealing with message fragmentation, when payloads are above max. PDU size.
• Shimming reliability, ordering and congestion control on user-land (or relying on transports like uTP).

Team

The team working actively so far on this epic comprises @bigs (leading it), @yusefnapora (main author of the libp2p Noise spec), and @marten-seemann (drafting multiselect 2.0).

👉 If you'd like to help shape things and hack on the proof of concept, please comment on this issue! 🙌

Design documents

• Message orientation concept and timeline for proof-of-concept by @bigs: https://docs.google.com/document/d/1xlD26_C4aHOwE1r7uGngD1c73bcjReoDG-UCMVTJSvY/edit
• Input by @raulk: https://github.com/raulk/notes/blob/master/libp2p-packet-orientation.md
• [DISCUSSION] Multiselect + Packet Orientation: https://github.com/libp2p/specs/issues/226
• Multiselect 2.0 design draft: https://github.com/libp2p/specs/pull/205
• libp2p noise handshake spec: https://github.com/libp2p/specs/tree/master/noise

Start by reading the linked message-orientation concept and timeline, packet-orientation notes, and the Multiselect + Packet Orientation discussion. Review the multiselect 2.0 draft and Noise handshake specification to understand the proposed protocol layers. The issue is an open-ended epic; done would require an agreed design direction and proof of concept, not a single specified change.