Right now we don't really have a spec for the transport interface. The archived original spec linked to the interface-transport repo, but that repo is quite javascript-focused, with Go marked as WIP.
I'd like to write up a minimal definition of a transport in a platform-agnostic way, which is something I'm not quite sure how to do yet. The go and js interfaces diverge a bit (for example, go has a CanDial method that js lacks), and it's likely that no single API will feel idiomatic in all languages libp2p is implemented in.
However, it seems like it should be possible to spec out the required capabilities of a transport, either as pseudo-code or by just enumerating them and describing in prose.
This doc could also be a place to precisely define the "connection" and "stream" abstractions, and a future work section could mention message-orientation and discussions around supporting unreliable transports.
Right now we don't really have a spec for the transport interface. The archived original spec linked to the interface-transport repo, but that repo is quite javascript-focused, with Go marked as WIP.
I'd like to write up a minimal definition of a transport in a platform-agnostic way, which is something I'm not quite sure how to do yet. The go and js interfaces diverge a bit (for example, go has a
CanDialmethod that js lacks), and it's likely that no single API will feel idiomatic in all languages libp2p is implemented in.However, it seems like it should be possible to spec out the required capabilities of a transport, either as pseudo-code or by just enumerating them and describing in prose.
This doc could also be a place to precisely define the "connection" and "stream" abstractions, and a future work section could mention message-orientation and discussions around supporting unreliable transports.