[mbreese]

It doesn't seem to be a P2P system, since it requires a server. According to the docs, "This server does not rewrite the messages or do much of anything besides pass the messages between the participants" [1] , so it's not really P2P.

I'm fairly sure the Firebase requires a server too... (their server, or else they couldn't charge for it).

[1] https://togetherjs.com/docs/#technology-overview

[ianb]

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.

[derefr]

> 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?

[ianb]

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.)

[k__]

AFAIK WebRTC just works with the latest Firefox/Chrome and needs a STUN and/or a TURN server.