I think very highly of WebRTC as a platform for a range of cool new innovations, but it is wrong to give it the status of supporting P2P network models.

WebRTC is inherently dependant on centralised servers.

Unlike in traditional P2P, where there is simply the problem of bootstrapping the node (getting some initial connections into the network), in WebRTC this style of doing things is barely supported.

Instead you need to exchange RTCSessionDescription's (SDP blobs) through a createAnswer/Reply API, which is doesn't facilitate your typical 'connect to a node by their IP'. These session descriptions need be tweaked according to who is connecting and what parameters, so it also doesn't allow for a node to forward another nodes details (to form an overlay).

I've been researching the process of building a true P2P application on top of web technologies, but sadly and frustratingly this is stumping my progress. The only solution would be to expose a more 'raw' connection API by creating an RTCSessionDescription based on IP addresses. It's possible to hack together a solution whereby you tweak the data in the SDP blob (see http://en.wikipedia.org/wiki/Session_Description_Protocol), but this is too cumbersome.

That's not totally true.

It's true that WebRTC currently needs a handshake server and that SDPs are a sh*t, but on ShareIt! (http://shareit.es), my own WebRTC P2P filesharing application, I have solved it using anonimous XMPP servers thanks to my framework WebP2P.io. Currently is not working just because I only was able to find one public XMPP server (Jappix.net) and they recently closed the access and with exams I'm not able to fix it (it's working using a PubNub backend channel, but only for Chromium <= v25 since recent ones generate incredible big and useless SDP strings), but it's functional.

Also, regarding to using another nodes as intermediary, with the old filetransfer-only protocol (I'm changing it to be more generic and create an agnostic-protocol network, but currently I'm really busy to finish it) I was able to connect two peers between them using just the WebRTC P2P network, so YES, IT'S POSSIBLE!!! :-D

Yes, I have been working very hard the last year trying to create a production-grade P2P application (I need to work to make it more robust, by the way...), and also thanks to it I've won the last week the "Most Innovative Project" on the national spanish VII Universitary Free Software Championship :-D

http://www.concursosoftwarelibre.org/1213/premiados-vii-cusl

What you did is very novel (I had a similar solution in my head that involved using qirc hosts for IRC bootstrapping like in Bitcoin) but I was targeting a different point.

What I was referring to was the lack of any API for signalling over already obtained network information (such as IP) rather than using a server for the initial signalling when you could use direct communications immediately after NAT has been traversed.

Thank you :-)

Yes, it's a same there's no way to do connections based on IP at this moment... It was discussed some time ago on the W3C WebRTC mail list but don't know where it went :-/

Do you still have the link? I really think this needs to be in the standard API.

I agree, but only partially. Since the sdp mechanism only defines the message it self but not how it can be transfered. a node can bootstrap first via a server to connect to the first nodes, and then continue connecting to more nodes via those nodes that it already is connected. That is if there's a path of links between nodeA to nodeB they can connect via that path and not using a server.

Anant Narayanan has been using a mechanism like this as an example in WebRTC spec discussions - basically a distributed-hash signaling layer (if you will, a self-healing incomplete mesh used to connect nodes for signaling a webrtc call) - and the distributed hash mesh could be a mesh of WebRTC connections with datachannels (no media).

The effect might be an encrypted, hard-to-block (barring deep packet inspection at all the edges or shutting off all access) communication tool. Identity verification would be important for some uses, but not for others.

OOB negotiation via any other channel can be used to join a network (see the article on serverless WebRTC)

Would this work?

http://blog.printf.net/articles/2013/05/17/webrtc-without-a-...

No, as it still doesn't solve the issue of the lack of any API for signalling over already obtained network information (such as IP), when you could use direct communications immediately after NAT has been traversed.

Still, props to the guy for creating the article. I didn't know that you could serialise/manipulate the SDP session descriptions before I read it.

Added an issue about that https://github.com/Peer5/ShareFest/issues/28

One can also signal via distributed anonymous xmpp servers

This is what I was using for :-) Do you know some of them? I know there are several ones, but only was able to use Jappix.net, and they have closed it some weeks ago... :-(

Since this has access to all the capabilities of a browser, it is a short step from this sort of generic file-based swarming to something with previewing of those files using the browser as a media player for those videos and music (and PDFs using pdf.js, and P2P distribution of normal HTML-based sites). Perhaps even following of magnet URIs to allow browsing of the serverless (P2P) web, or bridging of torrents and HTTP content distribution networks.

Instant YouTube.

Great suggestion. Added on https://github.com/Peer5/ShareFest/issues/29 I think the main advantage of WebP2P projects over traditional client based projects is that they can use the power of the web to enhance the experience. Whether it's by adding great user interface, social features, search, easy embedding and sharing which are so inherent in the web today.

Looking forward for this to happen!

Btw, there's a great community of p2p hackers that promote the idea of web p2p: http://webp2p.org/

Could you use something like this to lower bandwidth costs for displaying a media-rich website? There would be implications in hijacking user's upload bandwidth without them accepting.

IIRC Opera had a BitTorrent client built in. Perhaps in the future we'll be able to do:

    <video>
        <source src="webp2p://example.com/video.webm">
        <source src="magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C">
        <source src="http://example.com/video.webm">
    </video>

Good idea. I think hijacking of user's upload bandwidth can be done by "conventional" methods and server-client api's today, Web-RTC doesn't bring any additional risk here. Just the idea that it is actually useful to leverage user's uplink. https://groups.google.com/forum/?fromgroups=#!searchin/discu...

It's a horrible idea for those who are forced to use ISPs with capped upload amounts or speeds, though.

I think the ubiquity of HTTP and other centralized methodologies have encouraged this discrimination ("residential internet" vs "commercial internet"). There's no time like the present to roll back the presumption of consuming non-producers (who only need 56kbps upstream) as second class netizens.

yea, you're right, I wonder how common this is (on a land cable) if you're on 3g it can be detected and prevented or request opt in from the user.

There's an existing swarm of nice wallpapers my colleague has put up there: http://www.sharefest.me/stan17

Tried this out on Firefox 23 (Aurora)... it printed a long string of silly error messages ("Making more coffee..." "wow you chose a BIG file!") without actually doing anything, then froze the browser. After restarting, on the second try Firefox crashed. Anyone else having trouble?

Sharefest works with WebRTC - dataChannels, currently there isn't interoperability of this api between Chrome and Firefox. This swarm was created with a chrome browser so firefox leechers can't join the swarm (yet).

That's too bad. Might be worth adding a note about that for now?

WOW! Now this is amazing!

I really hope this get standardized and adapted to mobile browsers (like safari and android's browser)...at least the receiving end.

same here, although this works already in chrome for android except a minor bug that prevents you eventually getting the file on the device (which should be fixed soon).

It's implemented using the new WebRTC DataChannels API. Probably the most promising and interesting API in HTML5

And one of the biggest attack surfaces to come along in browsers in quite a while. (Immature DTLS implementations! SCTP stack in userland! Woooooooo!)

And no real binary protocol and browser interoperability as well. But good folks at Google and Mozilla are working on it...

here's are some words good people from webrtc had to say: http://pastebin.com/vGrmH1LG

Very cool showcase of WebRTC! Thanks for open-sourcing! Got this same app working on Stackato at http://sharefest.stacka.to ! Awesome!

Will this work for Chrome on Android?

Would love to see what this could be when you add a rasberry pi connected to a 3TB external hard drive... Your own personal Amazon Glacier?

It actually already works for Chrome on Android (you have to turn the webrtc flag on) BUT there's a bug in chrome for android when downloading a download tag with href that links to a blob url. hopefully they'll fix it soon enough

So far people have shared 30GB of files in sharefest.me today. and not a single byte of that has touched the server :)

What is the next feature you'd like to see on sharefest.me?

I'd prefer to see this as an browser extension, a background page, so I don't have to keep a tab open (and in case I accidentally close it).

Doesn't work on WebKit nightly. It's sad.

Yea, They didn't announce (to the best of my knowledge) their support in WebRTC

Annnnnddd .... it's down.

Still working for me

That is very cool. I agree though, the description could be a little misleading, as there is the requirement for the centralised sever.