As far as I understand the current IPFS pubsub implementation works only between nodes that are directly connected and as such can’t be used in production enviroments where that isn’t the case.
When do you expect for there to be a IPFS pubsub implementation that doesn’t have such constraints?
As far as I understand the current IPFS pubsub implementation works only between nodes that are directly connected and as such can’t be used in production enviroments where that isn’t the case.
The current pubsub implementation will forward messages. That is, if peers A, B, and C are all subscribed to a topic and are connected in a line A <-> B <-> C, B will forward pubsub messages on the topic between peers A and C. However, the current implementation is horribly inefficient (it’s called floodsub because it literally broadcasts the message to all connected and interested peers). We’re working on better message routing but that will take a while.
Another issue is pubsub peer discovery. When subscribing to a topic, one would ideally make some effort to find and connect to other peers subscribed to the same topic. go-ipfs does this (although it does so in a bit of a hacky way) however, js-ipfs doesn’t (as far as I know).
Note: If you were asking when arbitrary nodes will forward pubsub messages on topics to which they are not subscribed, this will likely never happen (although it may become possible to pay third parties to act as pubsub relays for your topic). Unrestricted relays are too easily abused.
If arbitrary notes don’t forward pubsub messages towards which they aren’t subscribed how will Orbit work in practice? I would have guessed that it needs the forwarding of messages to be able to have a user experience that’s similar to an existing chat app like WhatsApp.
It’ll work as long as you are connected to at least one node involved in the chat. If two nodes aren’t connected, they’ll connect to each other (and find each other via peer discovery). If they can’t connect directly (they’re all firewalled), they can connect using a relay (https://github.com/ipfs/go-ipfs/blob/master/docs/experimental-features.md#circuit-relay).
Another issue is pubsub peer discovery. When subscribing to a topic, one would ideally make some effort to find and connect to other peers subscribed to the same topic. go-ipfs does this (although it does so in a bit of a hacky way) however, js-ipfs doesn’t (as far as I know).
@stebalien Is this still true? I’ve been looking everywhere for how PubSub peer discovery (same topic) works, so I can connect users of my browser application together. I’m only asking because using libp2p-webrtc-star and libp2p-websockets-star directly doesn’t support rooms/namespaces, instead of a huge swarm, so PubSub seems to be the way to go, except this small detail.
EDIT: Actually, would bootstrapping to a known node that subscribes to the topic guarantee that pubsub should work between client instances of the application? I guess this would be analogous to hosting a rendevous/signalling server with native libp2p-*-star transports for client applications to communicate with each other…
If you can somehow connect to some node that’s subscribed to the topic, you should be fine (although the current default pubsub implementation won’t try to expand the number of peer’s you’re connected to).
But no, js-ipfs doesn’t currently rendezvous by default.
Thanks, any details on this part then? I haven’t seen this mentioned anywhere except when someone asks why they aren’t receiving topic messages lol… For example:
https://www.reddit.com/r/ipfs/comments/8aczsm/not_all_nodes_listening_on_pubsub_topic_receiving/
https://www.reddit.com/r/ipfs/comments/9287kf/how_to_enable_pubsub_peer_discovery_using_jsipfs/
But it seems largely unanswered as to how to go about discovering peers publishing to a topic. Using IPFS with WebRTC in the browser, would we need to set up a signalling server that will connect users of our application (exclusively?) but also acts as a peer for all the topics created by users of the application? Then at least they would be sure they’re connected one node (and possibly many others) interested in the topic. After this point, they could cache a list of others interested in the topic and bootstrap js-ipfs on next launch without overloading the signalling server (I guess by turning off discovery)?