Does WebRTC have any sort of extension mechanism whereby I can drop in my own version of NAT traversal logic?
Speaking from past experience, STUN and ICE are OK, but they got the whole process fundamentally wrong. They let the clients drive the traversal process. This is substantially inferior to letting a dedicated mediating server do that instead. I did that with one of my past projects and it helped with connecting peers in a large number of obscure scenarios.
ICE/STUN (which is used by WebRTC and thus PeerJS) support NAT traversal in all cases but a pair of symmetric NATs, which means some single digit percentage of connections will not work. For those cases, WebRTC/PeerJS support using a TURN server which proxies the data, not ideal but it allows the library to work.
Looks like a nice little library, and very relevant to my interests. My personal "dream scenario" is to have true multisource P2P video streaming in the browser with no extensions required - with WebRTC, this seems quite feasible as implementations mature.
Potentially, but their Safari browsers don't support webRTC yet. There's also nothing you could do with the files once you had them, other than images.
I'd personally like to see them implement proper SVG support before they do too.
Direct torrents no, but you can rename the pieces *.fll and download them and send them to registered app for that extension that combines them ... you will have problem with seeding though, but that is also something that can be solved with a little tweaking of the protocol. I think the hacker community has shown that they can scare you with their inventiveness when they work in (stupidly and unnecessarily in that case) constrained environment.
Any reason not to offer support for the video side of things? A lot of the issues in terms of client IDs and whatnot are the same. It would be nice to have a single library that can establish a connection and then send either video ir data or both...
Is it totally possible to do both with the same library.Problem is: You need that?
I mean, video rendering kills the performance of your browser I guess is better just to show the possibility of data transferring and then you build it by using the desired specs. Many ongoing video demos are avaliable too :)
Q1. Does this support connecting to a peer behind a NAT device?
Q2. Does this support connecting two peers each behind its own NAT?
Because a vast majority of real world cases will fall into either of these two categories.