Messaging layer

This issue is aimed at getting discussion started around designing a messaging layer for libp2p. The messaging layer is for encapsulating unreliable transports, like UDP, along with other use cases.

Specifically, I want to use IPFS in order to provide p2p networking for VPN traffic, which is usually implemented over UDP. It is possible to use other transports, although wasteful since TCP is usually also implemented within the networking stack the VPN encapsulates.

We discussed this a bit in https://github.com/ipfs/go-ipfs/issues/3994

From @magik6k:

There are some problems with supporting udp properly:

• Need to track connections if we want 2-way communication (this isn't that hard, maybe slightly harder if one wants this to be any fast)
• Libp2p** operates on streams, udp is message oriented. There are 2 ways to solve this:

• wrap udp packets into messages (basically size+data piped into stream)
  • IMO the wrong way to do this
• give libp2p the concept of messages
  • There are some plans for message oriented (+unreliable) transports/muxers
    • Can't find any specific issue
  • This would be ideal for udp
  • Also, useful in other parts of libp2p.

cc: @whyrusleeping @magik6k @lgierth

Start by reading the discussion in ipfs/go-ipfs#3994 and the transport concerns quoted here, especially connection tracking and the mismatch between streams and UDP messages. A completed effort would define a messaging-layer design for unreliable transports and explain how it supports the VPN-over-IPFS use case.