# When will IPFS pubsub be scaleable **URL:** \ **Category:** Uncategorized\ **Created:** [January 25, 2018, 9:23am UTC](https://discuss.ipfs.tech/t/when-will-ipfs-pubsub-be-scaleable/1923 "2018-01-25T09:23:37Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![ChristianKl](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/christiankl/32/572_2.png) [@ChristianKl](https://discuss.ipfs.tech/u/ChristianKl)\ **Post date:** [January 25, 2018, 9:23am UTC](https://discuss.ipfs.tech/t/when-will-ipfs-pubsub-be-scaleable/1923/1 "2018-01-25T09:23:37Z")
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? ---
**Author:** ![stebalien](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/stebalien/32/156_2.png) [@stebalien](https://discuss.ipfs.tech/u/stebalien)\ **Post date:** [January 26, 2018, 10:14am UTC](https://discuss.ipfs.tech/t/when-will-ipfs-pubsub-be-scaleable/1923/2 "2018-01-26T10:14:43Z")
> 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. ---
**Author:** ![ChristianKl](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/christiankl/32/572_2.png) [@ChristianKl](https://discuss.ipfs.tech/u/ChristianKl)\ **Post date:** [January 30, 2018, 1:41pm UTC](https://discuss.ipfs.tech/t/when-will-ipfs-pubsub-be-scaleable/1923/3 "2018-01-30T13:41:13Z")
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. ---
**Author:** ![stebalien](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/stebalien/32/156_2.png) [@stebalien](https://discuss.ipfs.tech/u/stebalien)\ **Post date:** [February 4, 2018, 4:10pm UTC](https://discuss.ipfs.tech/t/when-will-ipfs-pubsub-be-scaleable/1923/4 "2018-02-04T16:10:54Z")
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](https://github.com/ipfs/go-ipfs/blob/master/docs/experimental-features.md#circuit-relay)). ---
**Author:** ![SahidMiller](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/sahidmiller/32/2413_2.png) [@SahidMiller](https://discuss.ipfs.tech/u/SahidMiller)\ **Post date:** [September 3, 2018, 4:55pm UTC](https://discuss.ipfs.tech/t/when-will-ipfs-pubsub-be-scaleable/1923/5 "2018-09-03T16:55:09Z")
> 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… ---
**Author:** ![stebalien](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/stebalien/32/156_2.png) [@stebalien](https://discuss.ipfs.tech/u/stebalien)\ **Post date:** [September 3, 2018, 10:35pm UTC](https://discuss.ipfs.tech/t/when-will-ipfs-pubsub-be-scaleable/1923/6 "2018-09-03T22:35:06Z")
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. ---
**Author:** ![SahidMiller](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/sahidmiller/32/2413_2.png) [@SahidMiller](https://discuss.ipfs.tech/u/SahidMiller)\ **Post date:** [September 4, 2018, 11:55am UTC](https://discuss.ipfs.tech/t/when-will-ipfs-pubsub-be-scaleable/1923/7 "2018-09-04T11:55:46Z")
> [@stebalien](#): > > If you can somehow connect to some node that’s subscribed to the topic 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: > > > Hi @diasdavid David, > > I integrated IPFS successfully into my App at https://du…kaanbabu.com > But I Didn’t publish the ipfs update into the Store yet. > > Bcoz of a couple of reasons > > I know I have to wait for DHT implementation in JS-IPFS. > But I am wondering about the scalability on websockets-star topology as of now. > > As of now, I am using websockets-star for PubSub > > But I didn’t understand how websockets-star works for pubsub. > > \- Is the signalling data of peers getting shared. > \*\*(Or)\*\* > The whole data is transmitted via the signalling server. > > \- Are the peers subscribing /asking in a flooding technique after peer discovery/ Swarming? > \*\*(Or)\*\* > Are they subscribing via the signalling server (Rendezvous) ? > > > > My current config is > > \`\`\` > Addresses: { > Swarm: \[ > // Will update the hosted rendezvous in production > '/dns4/ws-star.discovery.libp2p.io/tcp/443/wss/p2p-websocket-star/', > //'/dns4/star-signal.cloud.ipfs.team/tcp/443/wss/p2p-webrtc-star', > \] > }, > Discovery: { > MDNS: { > Enabled: true, > Interval: 10 > } > // }, > // webRTCStar: { > // Enabled: true > // } > }, > Bootstrap: \[ > "/dns4/ams-1.bootstrap.libp2p.io/tcp/443/wss/ipfs/QmSoLer265NRgSp2LA3dPaeykiS1J6DifTC88f5uVQKNAd", > "/dns4/lon-1.bootstrap.libp2p.io/tcp/443/wss/ipfs/QmSoLMeWqB7YGVLJN3pNLQpmmEk35v6wYtsMGLzSr5QBU3", > "/dns4/sfo-3.bootstrap.libp2p.io/tcp/443/wss/ipfs/QmSoLPppuBtQSGwKDZT2M73ULpjvfd3aZ6ha4oFGL1KrGM", > "/dns4/sgp-1.bootstrap.libp2p.io/tcp/443/wss/ipfs/QmSoLSafTMBsPKadTEgaXctDQVcqN88CNLHXMkTNwMKPnu", > "/dns4/wss0.bootstrap.libp2p.io/tcp/443/wss/ipfs/QmZMxNdpMkewiVZLMRxaNxUeZpDUb34pWjZ1kZvsd16Zic", > "/dns4/wss1.bootstrap.libp2p.io/tcp/443/wss/ipfs/Qmbut9Ywz9YEDrz8ySBSgWyJk41Uvm2QJPhwDJzJyGFsD6" > \] > } > \`\`\` > > > Here is a \*\*SNEAK PEEK\*\* of Github for Shopping > !\[pricegraph\](https://user-images.githubusercontent.com/35241544/39113431-40d049a6-46a1-11e8-82db-6d234e36f834.png) [https://www.reddit.com/r/ipfs/comments/8aczsm/not\_all\_nodes\_listening\_on\_pubsub\_topic\_receiving/](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/](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)?