├── .gitignore
├── LICENSE
├── README.md
├── browser-answer.html
├── browser-offer.html
├── browser.js
├── cli_offer.go
└── local_web_server.go
/.gitignore:
--------------------------------------------------------------------------------
1 | /*.exe
2 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | MIT License
2 |
3 | Copyright (c) 2019 Chad Retz
4 |
5 | Permission is hereby granted, free of charge, to any person obtaining a copy
6 | of this software and associated documentation files (the "Software"), to deal
7 | in the Software without restriction, including without limitation the rights
8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 |
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 |
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # WebRTC IPFS Signaling
2 |
3 | This project is a proof of concept to see whether we can use IPFS to do WebRTC signaling obviating the need for a
4 | separate server.
5 |
6 | ### Goal 1 - Browser to Browser Signaling
7 |
8 | Status: **Accomplished**
9 |
10 | I currently have debugging turned on so the console logs do show some details. Steps:
11 |
12 | Navigate to https://cretz.github.io/webrtc-ipfs-signaling/browser-offer.html. It will update the URL w/ a randm hash.
13 | (Of course, you could navigate to a hand-entered URL hash on a fresh tab). Take the URL given on that page and, in
14 | theory, open it up with the latest Chrome or FF anywhere in the world (that doesn't require TURN). After a few seconds,
15 | the offer/answer will communicate and WebRTC will be connected.
16 |
17 | Quick notes:
18 |
19 | * It may seem like you need some kind of server to share that URL hash, but that's just an example to make it easier. It
20 | could be any preshared value, though you'll want it unique and may want to do other forms of authentication once
21 | connected. E.g. one person could just go to
22 | https://cretz.github.io/webrtc-ipfs-signaling/browser-offer.html#someknownkey and the other person could just go to
23 | https://cretz.github.io/webrtc-ipfs-signaling/browser-answer.html#someknownkey
24 | * This works with `file:///` on Chrome and FF too, even across each other or mixed with traditional http pages.
25 | * I have tested on mobile FF on Android and it works gloriously. I haven't tested any other browsers beyond Chrome
26 | desktop, FF desktop, and FF mobile.
27 | * For this tech demo, I just use Google's public STUN server and no TURN server so if you require TURN this won't work
28 | for you.
29 | * This uses js-ipfs's pubsub support which is in an experimental state. I even hardcode a swarm to
30 | https://ws-star.discovery.libp2p.io/. So it probably won't work if this repo goes stale (which it likely will). I'm
31 | also unsure how it'd hold up to any load.
32 | * js-ipfs is pretty big at > 600k right now.
33 | * You might ask, "Why use WebRTC at all if you have a PubSub connection?" The features of WebRTC are many, in fact with
34 | the latest Chrome release, I am making a screen sharing tool requiring no local code.
35 | * This is just a tech demo so I took a lot of shortcuts like not supporting restarts, poor error handling, etc. It would
36 | be quite trivial to have multiple subscribers to a topic and group chat with multiple offer/answer handshakes.
37 | * Security...not much. Essentially you need to do some other form of security (WebRTC peerIdentity? app level ID verify
38 | once connected? etc). In practice, this is like an open signaling server.
39 |
40 | **How it Works**
41 |
42 | It's quite simple. Both sides subscribe to a pubsub topic named after the preshared identifier. Then I just send JSON'd
43 | [RTCSessionDescription](https://developer.mozilla.org/en-US/docs/Web/API/RTCSessionDescription)s back and forth.
44 | Specifically, the offer side sends the offer every two seconds until it gets an answer whereas the answer side waits for
45 | an offer then sends an answer.
46 |
47 | ### Goal 2 - Browser to Native App Signaling
48 |
49 | Status: **Failing**
50 |
51 | I was pretty sure I could easily hook up [ipfs/go-ipfs](https://github.com/ipfs/go-ipfs) with
52 | [pions/webrtc](https://github.com/pions/webrtc) and be all good. Although `pions/webrtc` is beautifully built, go-ipfs
53 | is not and very much not developer friendly for reading code or embedding. I was forced to use
54 | [ipsn/go-ipfs](https://github.com/ipsn/go-ipfs) which re-best-practicizes the deps. I have the code at
55 | [cli_offer.go](cli_offer.go) and while it looks right, the JS side cannot see the pubsub messages. I have a lot of
56 | annoying debugging to do in that unfriendly codebase.
--------------------------------------------------------------------------------
/browser-answer.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |