Earlier quoted context omitted.
On principle we keep the server simple, echoing messages back and forth between clients. In practice it's quite hard for two browsers to connect directly to each other, and while we want to support that kind of architecture in order to get it working we still need to simulate P2P using a server.
> In practice it's quite hard for two browsers to connect directly to each other Isn't this the problem WebRTC abstracts away? Your server should just be a TURN server ( http://en.wikipedia.org/wiki/Traversal_Using_Relays_around_N... ), shouldn't it?
WebRTC makes it possible, but not easy, nor abstracted. You still have very long connection strings to establish the connection, and those strings change as you move around, so it's not something we'd want to ask users to send to each other in order to establish a connection. The approach usually used is a server where the two people rendezvous to exchange the connection strings. That server is kind of like what we have – but then once it's in place, changing over to WebRTC just doesn't seem as exciting. (And even then the connections are slower to establish and less reliable than WebSockets.)