The cryptographer in me says I should do this, while the engineer in me thinks this may be (too) difficult to implement.  (And I'm a much stronger engineer than cryptographer!)  I still haven't totally wrapped my head around it from an engineering perspective, I'll do that once I get the GUI for Coinmux working.  But I am a believer in keeping Coinmux simple.  Bitcoin has some warts, but its really pretty simple as far as crypto goes.  I'd like to keep that same philosophy for Coinmux.

One of the easiest things I can do to limit who sees the the IP address of published messages is to encrypt them.  Both the Director and Participants have a public key as part of their first message broadcast.  Other than the Director's first announcement message and the Director's subsequent status updates, all other messages can be encrypted so only the involved parties can decrypt the messages.  The IP address would still be leaked, but only those in the mix can make sense of what's going on.  While not a cryptographically perfect solution, this would make traffic analysis more difficult and less useful. This may make put Coinmux in the "good enough to be useful" category. This wouldn't be great, but as an engineer, I realize everything has tradeoffs.

The Coinmux protocol itself was not designed to hide IP addresses/participants, only to facilitate communication.  As i first imagined what the protocol would look like, I had always considered using Freenet for message communication and to provide anonymity at the "network layer." Coinmux was designed with a Freenet like system in mind with the following properties: untraceable message insertion, immutable messages, ability to post multiple messages to a known location/key, and all messages publicly retrievable from a known key.  TomP2P allows for all of these except the untraceable message insertion.  TomP2P was really only selected due to it being available as a Java library and ready to be embedded in an application.  Well, that and it's faster than Freenet.

I'd rather try to solve this at the network layer than the protocol layer.  This allows for the network layer to be easily changed (I have 3 implementations now - TomP2P, the filesystem, and a memory implementation used for testing).  I am still actively considering switching to using Freenet as originally planned. Bitmessage is another option, though i believe their API is inadequate.  Maybe there is a way to use Tor.  Or maybe some new Altcoin becomes a viable option in the future. Or maybe i can push harder on TomP2P: is it possible to shuffle messages around the TomP2P peer network before inserting them to provide anonymity?  The protocol doesn't care who inserted the message, only that it gets inserted.  As it is right now, none of the options outside of TomP2P meet the requirement of "easy to use" as they require an additional application running.

Anyway, there are lots of different options and all of them have tradeoffs, but I am pretty open to anything that will work.  I'll need to let what you wrote settle on my brain a little more.