We see a lot of questions about how to get started with using js-ipfs in the browser. I’m going to demonstrate a minimal chat example in js-ipfs entirely in the browser. It uses WebRTC-Star to achieve browser <-> browser connectivity where possible, and a circuit relay where not. You can check it out here, or you can download the whole directory using IPFS to have your own local copy:

ipfs get bafybeiffmpb4cvg76ozfxht6yw7yflhjlm6szdoymxt7s4sjiy5awhsxpu


The libraries used in this example are js-ipfs, bootstrap, jquery, and popper. If you want a newer version of any of those, feel free to download one and use your own 😃.

Let’s take a look at how this works.

# 🪐 Peer Discovery and Connectivity

In a browser discovering and connecting to peers can be very hard, as we can’t listen for new peers, and we don’t have access to the DHT. In order to have the best experience working in a browser, it’s important to understand how to find peers, and stay connected with them.

The chat example achieves this in 2 ways. Using WebRTC-Star we achieve direct browser <-> browser communication, and with a circuit relay, we have a relay in the middle. The chat application has a status indicator in the top-left to let you know too what kind of connection you have. Green means you’re connected to the relay, even if it’s via another peer, yellow mean you’re only seeing local peers, and red means you have no peers (at least none using the chat application).



hierarchy

BrowserA

BrowserA

BrowserB

BrowserB

BrowserA->BrowserB

NAT1

NAT1

BrowserA->NAT1

WebRTC_Star

WebRTC_Star

BrowserA->WebRTC_Star

BrowserB->BrowserA

BrowserB->NAT1

BrowserB->WebRTC_Star

BrowserC

BrowserC

NAT2

NAT2

BrowserC->NAT2

circuit_relay

circuit_relay

BrowserC->circuit_relay

BrowserC->circuit_relay

circuit_relay->BrowserA

circuit_relay->BrowserB



## WebRTC-Star

We can use WebRTC-Star nodes to help discover other peers we can connect with directly browser <-> browser. I find it easy to think of it as similar to STUN, if you’re already familiar with that concept. Effecively each connecting node will be given a WebRTC-Star multiaddress that other nodes can use to discover and connect to your browser directly. Meaning if you peer with someone using the star node, and the star node goes offline, you remain connected!

### Usage

Connecting to a star node is quite simple:



ipfs = await Ipfs.create({
repo: 'ok' + Math.random(), // random so we get a new peerid every time, useful for testing
config: {
Swarm: [
'/dns4/star.thedisco.zone/tcp/9090/wss/p2p-webrtc-star',
'/dns6/star.thedisco.zone/tcp/9090/wss/p2p-webrtc-star'
]
},
}});


### Setup

Please note that this example uses my own star nodes, however those won’t necessarily always be accessible there. Currently it’s important to find a reliable star node, or host your own. You can host your own quite simply by following the instructions here for a native setup and here for a docker container which includes Nginx (for SSL). If you opt for the native setup, we cover the Nginx reverse proxy process and SSL cert retrieval later in this post.

This is a very clean and effective method of P2P communications, however sometimes NATs get in the way. For that, we use p2p-circuit to get around that.

## p2p-circuit

p2p-circuit is really useful for peers behind tricky NATs (or a VPN, or anything really). I find the relaying of p2p-circuit to be similar to TURN, so it’s easy to think of it that way if you’re already familiar with it.

### Usage

Once all the services for p2p-circuit are put together, connecting to the node can be achieved a couple of ways. First, to connect on startup to only our node(s):



ipfs = await Ipfs.create({
config: {
Bootstrap: [
'/dns6/ipfs.thedisco.zone/tcp/4430/wss/p2p/12D3KooWChhhfGdB9GJy1GbhghAAKCUR99oCymMEVS4eUcEy67nt',
'/dns4/ipfs.thedisco.zone/tcp/4430/wss/p2p/12D3KooWChhhfGdB9GJy1GbhghAAKCUR99oCymMEVS4eUcEy67nt'
]
}});


Or we can add our own after, then manually initiate the connection:



await ipfs.swarm.connect('/dns6/ipfs.thedisco.zone/tcp/4430/wss/p2p/12D3KooWChhhfGdB9GJy1GbhghAAKCUR99oCymMEVS4eUcEy67nt');
await ipfs.swarm.connect('/dns4/ipfs.thedisco.zone/tcp/4430/wss/p2p/12D3KooWChhhfGdB9GJy1GbhghAAKCUR99oCymMEVS4eUcEy67nt');


If you’re looking to do your own client, without copying the example, ensure you’re also communicating with the announce channel, which is described under “Advertising”. The relevant code in the chat demo is this (simplified):



var ipfs; // store the IPFS node you're using in this variable

// processes a circuit-relay announce over pubsub
// get our peerid
me = await ipfs.id();
me = me.id;

// not really an announcement if it's from us
return;
}

// if we got a keep-alive, nothing to do
return;
}

console.log("Peer: " + peer);
console.log("Me: " + me);
if (peer == me) { // return if the peer being announced is us
return;
}

// get a list of peers
peers = await ipfs.swarm.peers();
for (i in peers) {
// if we're already connected to the peer, don't bother doing a
// circuit connection
if (peers[i].peer == peer) {
return;
}
}
// log the address to console as we're about to attempt a connection

// connection almost always fails the first time, but almost always
// succeeds the second time, so we do this:
try {
} catch(err) {
console.log(err);
}
}

// process announcements over the relay network, and publish our own
// keep-alives to keep the channel alive
await ipfs.pubsub.subscribe("announce-circuit", processAnnounce);
setInterval(function(){ipfs.pubsub.publish("announce-circuit", "peer-alive");}, 25000);


### Setup

Like the star nodes, it’ll be important to host your own things as mine could go offline at any moment.

For the purposes of this example, you’ll need to do a few things on a server hosting your own go-ipfs node. You’ll also need a working Nginx install setup, which will be used for SSL which is a requirement for browsers.

First configure the Go node, enabling WebSocket support, and designated it as a relay so we can communicate with it from a browser by editing ~/.ipfs/config:

{
"Swarm" : [
"/ip4/0.0.0.0/tcp/4011/ws",
"/ip6/::/tcp/4011/ws"
]
},
"Swarm": {
"DisableRelay": false,
"EnableRelayHop": true
}
}


Restart your go-ipfs node however you normally do (possibly systemctl --user restart ipfs), and we’re mostly setup! We’ve enabled regular WebSockets with relaying support, however we need secure WebSockets otherwise browsers won’t connect to us.

### Nginx Setup

This setup is similar for WebRTC-Star, you just need to set it up as a different site, on a different port.

First obtain and install Certbot. Then edit the following file with your domain name, and port, then copy it to /etc/nginx/sites-available/ipfs.

map $http_upgrade$connection_upgrade {
'' close;
}

upstream websocket {
server 127.0.0.1:4011;
}

server {
server_name ipfs.YOURDOMAIN.COM;
listen 4430 ssl;
ssl_certificate /etc/letsencrypt/live/ipfs.YOURDOMAIN.COM/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/ipfs.YOURDOMAIN.COM/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://websocket; proxy_http_version 1.1; proxy_set_header Upgrade$http_upgrade;
proxy_set_header Connection $connection_upgrade; proxy_set_header Host$host;
}
}


So in this example you can see we’re accepting ssl on port 4430, this is our “wss port” (WebSocket Secure), and then passing it to the unsecured port locally on 4011, this is our “ws port”. So if we want to connect to this node from a browser, we’d use port 4430.

After, run the following:

sudo systemctl stop nginx
sudo certbot -d ipfs.YOURDOMAIN.COM --standalone # Edit ipfs.YOURDOMAIN.COM to the domain you want a cert for
sudo ln -s /etc/nginx/sites-available/ipfs /etc/nginx/sites-enabled/ipfs
sudo systemctl start nginx


🎉 Nginx is now operating as a reverse-proxy, giving you secured WebSockets!

Using p2p-circuit can be a bit tricky. Once we connect to the relay from a browser, we’re not advertising that we’re able to be reached through it! For this purpose, I’ve created a Python script that runs alongside go-ipfs which advertises the browser js-ipfs peers it encounters over PubSub with a p2p-circuit multiaddress.

You can find the Python script here. It can be run with a simple python ipfs_peeradvertiser.py. However, ensure you first edit CIRCUIT with your own node’s information, or you won’t announce the peers correctly, and they won’t know how to use your relay to connect to other peers.

You can retrieve your own circuit info quite easily. Simply run ipfs id on your go-ipfs node, to get your PeerID, then form the circuit URL like so:

/dns6/ipfs.YOURDOMAIN.COM/tcp/4430/p2p/YOUR_PEERID/p2p-circuit/p2p/


You should see here where you simply fill out your domain name you got the SSL cert for, as well as your node’s PeerID. For the script, the leading and trailing slash are required, too.

Ensure you specify dns6 or dns4, depending on if you’re forming an IPv6 or IPv4 address. It’s important to ensure you use dns, otherwise browser nodes likely won’t be able to connect. Also note the port 4430, if you used a different one, you’ll need to specify that.

# 🌐 Communication

Whew so you made it this far, you might be wondering “what is communication like?”, well luckily the answer is it’s very easy in comparison to finding the peers, with only minor pitfalls. We’re going to simply cover how we’re using PubSub in the chat example, and exactly what pitfalls that were found while it was developed.

## PubSub

Using PubSub we’re able to subscribe to topics, and retrieve any messages posted to those topics. In js-ipfs, we can set a callback function, which gets called whenever a message is received:



function echo(msg) {
msg = new TextDecoder().decode(msg.data);
console.log(msg);
}

await ipfs.pubsub.subscribe("example_topic", echo);


Publishing is just as easy too:

await ipfs.pubsub.publish("example_topic", "Hello world!");


This is effectively what the chat demo is doing. It’s subscribing to a global topic (named “discochat-global”), and simply relaying the messages people type around over PubSub.

## Possible Browser Pitfalls

So let’s say you’ve done everything correctly. You’re able to find peers using WebRTC-Star and p2p-circuit, awesome! However you might find your connections expire, and you’re unable to restore them! I’m not completely sure what causes this behaviour (probably some browser policy), however we can do our best to mitigate these issues!

### Staying Connected to Peers

We stay connected to peers in a couple ways. The first way is more direct, and that’s by subscribing to and sending a “keepalive” announcement over discochat-keepalive every 4 seconds:


setInterval(function(){sendmsg("1", prefix+"keepalive");}, 4000);
setInterval(checkalive, 1000);


This should help ensure we give peers looking to chat a high priority. Additionally, we report over announce-circuit every 25 seconds to make sure we keep a connection to the circuit relay so we can connect to peers stuck behind a NAT. That’s accomplished like so:



// process announcements over the relay network, and publish our own keep-alives to keep the channel alive
await ipfs.pubsub.subscribe("announce-circuit", processAnnounce);
setInterval(function(){ipfs.pubsub.publish("announce-circuit", "peer-alive");}, 25000);


🌟 A simplified version of processAnnounce is found under p2p-circuit#Usage.

The Python script on the circuit relay will report a keepalive every 4 seconds. You may have noticed we’re reporting “peer-alive” instead of “keep-alive”, this is to separate peer requests from relay requests, to make it easier to tell when we no longer see a relay.

### Staying Connected to the Circuit Relay

Outside of the simplified version of processAnnounce, in the real version there are a couple variables used for tracking keep-alive and peer-alive. These are lastAlive and lastPeer, respectively. We even track the last time we bootstrapped via lastBootstrap. Using all this, we can display the yellow status when we’re only connected to peers (tracked via lastPeer), and if we don’t see a keep-alive for 35 seconds (and we haven’t attempted a bootstrap in 60 seconds), we can attempt to re-connect to the bootstrap relay (and display a red status). This is accomplished like so:



const bootstraps = [
'/dns6/ipfs.thedisco.zone/tcp/4430/wss/p2p/12D3KooWChhhfGdB9GJy1GbhghAAKCUR99oCymMEVS4eUcEy67nt',
'/dns4/ipfs.thedisco.zone/tcp/4430/wss/p2p/12D3KooWChhhfGdB9GJy1GbhghAAKCUR99oCymMEVS4eUcEy67nt'
];
var lastAlive = 0;	// last keep-alive we saw from a relay
var lastPeer = 0; 	// last keep-alive we saw from another peer
var lastBootstrap = 0; // used for tracking when we last attempted to bootstrap (likely to reconnect to a relay)

// if reconnect is true, it'll first attempt to disconnect from the bootstrap nodes
async function dobootstrap(reconnect) {
now = new Date().getTime();
if (now-lastBootstrap < 60000) { // don't try to bootstrap again if we just tried within the last 60 seconds
return;
}
lastBootstrap = now;
for (i in bootstraps) {
if (reconnect) {
try {
await ipfs.swarm.disconnect(bootstraps[i]);
} catch (e) {
console.log(e);
}
} else {
}
await ipfs.swarm.connect(bootstraps[i]);
}
}

// check if we're still connected to the circuit relay
function checkalive() {
now = new Date().getTime();
if (now-lastAlive >= 35000) {
dobootstrap(true); // let's try to reconnect
if (now-lastPeer >= 35000) {
document.getElementById("status-ball").style.color = "red";
} else {
document.getElementById("status-ball").style.color = "yellow";
}
} else {
document.getElementById("status-ball").style.color = "lime";
}
}

setInterval(checkalive, 1000);


🌟 The above should be used with the full version of processAnnounce as it relies on lastAlive and lastPeer, which aren’t updated in the simplified version.

# 🎉 Conclusion

I hope this was informative enough to get rolling. If you were successful in following this entire guide, you now have the ability to deploy powerful IPFS apps that run entirely in the browser, and leverage decentralised p2p whenever you can! I’ve selected some helpful resources and shared them below for further reading: