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.
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! 🙌
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:
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