I have just recently developed
a concept, that relies on IPFS PubSub for communication.
But it seems to fail at that point.
If I try to publish a message on one machine,
it is not received on another machine subscribed on the topic even minutes later.
Is this a failure of IPFS PubSub?
Came here for the exact same thing! 
I know it was working a couple months back - I had an app up and running, then all of a sudden everything stopped. I upgraded to the latest version, and still no good.
I just finished writing a super basic test app to verify, and I’m getting zero communication between browser instances. Any thoughts?
Tried pubsub between my laptop and desktop just now and it worked fine.
That’s interesting, here’s my test code:
<script src="https://unpkg.com/ipfs@0.52.3/dist/index.min.js"></script>
<script>
let ipfs;
let rand = Math.random().toString();
document.addEventListener('DOMContentLoaded', async () => {
ipfs = await Ipfs.create({ repo: 'ipfs-' + Math.random() })
ipfs.pubsub.subscribe("channel-32", (msg) => {
console.log(`Received - ${msg.data.toString()}`);
//debugger;
});
setInterval(function() {
ipfs.pubsub.publish('channel-32', `message-${rand}`);
}, 3000);
})
</script>
Running it in two browsers on the same machine, and not seeing anything between them.
@ _7n - Thanks for confirming it’s working, at least glad to know the network is functioning 
Was just about ready to release a p2p social network then got hit with this 
de-ja-vu 
I’ve had the very same problem and had quite some difficulties figuring out why it’s not working.
You need to have peers connected in order to get what you want.
The annoying thing is that there is in essence no way to do that in the browser. There are projects that allow you to do pubsub communication between browsers (so an ipfs node still won’t see your message).
I assume you want to send a message on any node and expect it to show up on any other node that is subscribed to is. Regardless of desktop or browser, it just needs to show up if you’re subscribed, right? The same with publish.
I only know of one way to get around this.
What i did was:
Run a node on a server.
On that same server, create a sort of API proxy accessible through socket.io. I used node.js on the server. Remember, on the server you have access to the web API of IPFS. You should not open that in it’s entirety to the outside world! In node.js i create a socket.io in which i made a format to do publish and subscribe to ipfs. So if that socket receives a publish from, say, a website then the socket will nicely re-transmit it to the actual IPFS API. The socket itself is also subscribed to a channel of my choosing. If anything arrives on that channel (the node.js instance listens on IPFS pubsub for messages that arrive there) then it re-transmits it to people connected to the socket.
That way i made publish and subscribe accessible on a website.
I have quite a lot of code for it already but i stopped by securing it. Right now, in my code, anyone can publish and subscribe. That on it’s own is fine’ish… but i want some authentication there.
A big downside of this approach is that you now have a 1-on-1 connection between the server and your site that uses the socket connection. Thus you have a single point of failure. But then again, you have the awesome power of IPFS pubsub at your disposal!
Would you be up to help finish this code i have with authentication in it?
That’s quite unexpected. This has been working for me for the past year or so with no problem. I even ran a test with a ‘focus group’ to get some real world loads and feedback. I never had to run a node myself, was just using the public p2p-webrtc-star nodes out there.
I’m up for helping out, but given that this was working, I’d be more interested in figuring out how to get it running the way it was again. Having signaling servers help out your clients find each other so they can do p2p seems like a decent compromise of hosting ‘centralized’ servers, which could probably be hosted by clients with some clever implementations.
I figured there’s some new config after the 0.40 update that was breaking my nodes. Something changed for sure, old code that was old-faithful for me is not doa 
that’s exactly what i meant with:
The IPFS folks want to get rid of webrtc-star, just be aware of that.
I don’t know what an alternative is (besides going the proxy route like i did) that is up-to-date and in active development.
The IPFS folks want to get rid of webrtc-star, just be aware of that.
@markg85 - do you have any further information on that? I thought I’d seen that somewhere as well, but I can’t find any details. I’m really wondering what I should be using instead.
Hey! This will not happen anytime soon and we will provide docs with migration paths by then.
You can read more about these plans in https://github.com/libp2p/js-libp2p/issues/385#issuecomment-514300699
We released autoRelay in libp2p@0.30 and we will be releasing libp2p-rendezvous implementation in libp2p@0.31 as some initial steps towards that. We will also need to work on several connection manager improvements and finally distributed signalling. As soon as we release libp2p-rendezvous, it will allow other type of setups without the star server for connections using websockets. Webrtc will follow next with the distribute signalling work
That does sound very promising!
Is rendezvous also going to support interacting with pubsub to nodes? So will it support (both bi-directional):
So in other terms, can i send a message on pubsub that my site will receive and vice versa with rendezvous?
@fcbrandon Can i please ask you to not make a post with only a quote. It’s not useful at all (specially as the think you quoted was the last thing in the previous post) and only adds clutter.
Not exactly like that. What should happen with rendezvous (and also the DHT) is that when a pubsub topic is subscribed, the peer can announce to the network such subscription. In the rendezvous context, you would do something like pubsub.subscribe(topic) followed by rendezvous.register(topic).
More than this, your node would do rendezvous.discover(topic) and it would find other peers who are interested in the topic. This means you would be able to have connections with these nodes and pubsub messages would be delivered when published.
This is something that currently is not an out of the box solution (we want to make this part of the libp2p core). For now, until we have the Rendezvous the best solution would be to use the content routing in the application layer. This means that more than the pubsub publish/subscribe, you will need to handle how to find and connect to peers yourself by using the delegate nodes as a way to use the DHT and do provide(topic) and findProviders(topic) so that your app can find peers interested in the topic and connect to them.