A fundamental change which will come to waku that we are currently aware of is the change of the underlaying transport from devp2p to libp2p or something PSS-like. This raises the question of how we stay compatible while supporting multiple transports.
We can look at both libp2p and briar for inspiration of a solution. Briar has a specification for the transport properties client and libp2p advertises listenAddrs in the handshake. Both of these solutions can guide is into the right direction for some method to negotiate transport in a transport agnostic protocol.
The first step that needs to be taken in order for this to work is actually to make waku transport agnostic. Meaning, the protocol itself needs to be able to work not only on devp2p but on any other secure transport in the same way it works on devp2p. The exact changes this would require is out of scope for now (I believe these are mainly technicalities), so we will assume this has been achieved already.
The next problem we face is the actual negotiation part, there are several ways we can go about this. Below I will detail the two I have come up with, both of them are essentially broadcasting of transport capabilities.
Extended Status Message - This version is similar to the libp2p solution, in waku we use the status message as a handshake. We can extend this message to contain a list of multiaddresses indiciating all the methods which can be used to contact a node.
Transport Message - This version would is similar to the briar solution. Using the unused packet codes in waku we dedicated to a packet for broadcasting multiaddresses to their peers.
Both packets would essentially contain a list of an object containing the multiaddress, a ttl, the actual protocol (libp2p, devp2p, etc.) and potentially some preferance score to indicate which address is the main.
Once the broadcast has been established through either of the 2 listed means, peers can now chose over which transport to communicate. However we probably want to apply some rules. Such as ensuring that peers talk over the prefered one when possible. The Transport Message option is probably nicer as it would allow us to update addresses without needing to send an entire status message.
(fun fact: this could probably be done on whisper too.)