The thing is, DMQ is like a communication channel, over which messages can be sent by other modules or from within config. The channel itself is established on startup from within DMQ, at code level, not by the 3rd-party module or admin. When messages are sent/broadcast over that channel I would expect that all nodes currently sat in that channel have previously been verified and when I receive a message I don't have to perform my own checks each time (in which case I would need to know in advance the list of known IPs or perform my own authentication). Now as an admin, I can still choose which transport security I use to secure messages over the wire - this is outside of DMQ scope anyway - and I can still filter/act upon messages in my own "topic" in whichever way I choose. But I don't need to also worry about which nodes on that channel are friendly and which ones have been allowed to join without being authenticated first.

So there are two layers to DMQ - the underlying channel or network of "nodes" maintained dynamically by the DMQ module itself, and the "peers" (other modules, config script) which communicate over that network within their own discreet topics. My opinion is that the nodes MUST have some way internally of confirming their identity when joining/forming the underlying network.

The peers (the function of DMQ which is exposed to the end-user/admin) are still then free to communicate in whichever way they choose and perform whatever authentication they like - although it actually wouldn't be necessary. I don't think this is limiting choice or creating a higher maintenance burden.