uhhh, if you really want to do server less architecture for a chat application you need to evaluate carefully what kind of functionality you want to offer.
For example, do you want one-on-one chat only, how about group chats, status notifications, what about user authentication?
there are many ways to go about this, yet personally I would always favor a server based solution for this.
Anyways, the most basic solution would be to use UDP multicast, every client is a sender and receiver. UDP is not reliable, so your senders should cache the messages and your application level protocol should be able to detect gaps, be able to request gap fill data and order incoming data into sequence. In that scenario, basically everybody would see everybody's messages (this could be filtered on the application level protocol).
The next best solution would be that every client sends multicast beacons (announcements) and if a client is interest to initiate a conversation with a certain sender, it would look at the beacon which should contain info about the sender including an IP address and port. The interested party would then establish a TCP connection to the beacon sender and those two parties can now start to chat with each other directly with guaranteed and ordered message delivery.
I could go on now with more advanced messaging architectures/protocols but I don't think that makes sense.
If I had your requirements I would get something like http://www.coversant.net/Product/SoapBoxServer.aspx (they have a free express edition, everything is built in .NET, .NET API provided, etc.) or get any other XMPP server (here's a couple: http://xmpp.org/software/servers.shtml) with a .NET API like http://code.google.com/p/jabber-net/