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
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.
We released autoRelay in email@example.com and we will be releasing libp2p-rendezvous implementation in firstname.lastname@example.org 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
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.