+//! Wire messages, traits representing wire message handlers, and a few error types live here.
+//!
+//! For a normal node you probably don't need to use anything here, however, if you wish to split a
+//! node into an internet-facing route/message socket handling daemon and a separate daemon (or
+//! server entirely) which handles only channel-related messages you may wish to implement
+//! ChannelMessageHandler yourself and use it to re-serialize messages and pass them across
+//! daemons/servers.
+//!
+//! Note that if you go with such an architecture (instead of passing raw socket events to a
+//! non-internet-facing system) you trust the frontend internet-facing system to not lie about the
+//! source node_id of the mssage, however this does allow you to significantly reduce bandwidth
+//! between the systems as routing messages can represent a significant chunk of bandwidth usage
+//! (especially for non-channel-publicly-announcing nodes). As an alternate design which avoids
+//! this issue, if you have sufficient bidirectional bandwidth between your systems, you may send
+//! raw socket events into your non-internet-facing system and then send routing events back to
+//! track the network on the less-secure system.
+