IPFS recently merged a simple, experimental pubsub implementation into IPFS. This implementation is just a beginning. It is far from the performance and security goals we will achieve in our long-term target. However, even this early implementation opens the doors to several useful and interesting new applications.
# Why pubsub?
Publish-Subscribe, called pubsub for short, is a pattern often used to handle events in large-scale networks. ‘Publishers’ send messages classified by topic or content and ‘subscribers’ receive only the messages they are interested in, all without direct connections between publishers and subscribers. This approach offers much greater network scalability and flexibility.
Some applications include: - collaborative document editing - dynamic website content - chat applications - multiplayer games - continuously evolving datasets - webservice workers passing around messages.
It gives us ways to make IPFS fast for large-scale networks such as datacenters, local area networks, and large p2p applications. In the near future, IPNS records will be pushed over pubsub, allowing lightning fast updates of peers’ IPNS entries. Peers could use pubsub to track the head of a merkle-linked global log.
# Getting started with pubsub for go-ipfs
Note: There is also a js-ipfs implementation of pubsub.
First, you’ll need to enable the pubsub code. Make sure you’re running go-ipfs 0.4.5 or above. Once you have that version of ipfs installed, start the daemon with:
ipfs daemon --enable-pubsub-experiment
This will tell ipfs to create and enable the pubsub service. It also implies that you will only be able to use pubsub with other peers who choose to enable it.
To subscribe to the topic foo, run:
ipfs pubsub sub foo
Now, any messages for the topic foo will print to your console.
To publish a message to the topic foo, open up another terminal and run:
ipfs pubsub pub foo "hello world"
You should see “hello world” printed out in the first terminal. You can also run the pub command on any other connected ipfs node and your node will receive the message.
Messages are routed through connected, subscribed peers. This means that if peers A, B, and C are all subscribed to foo, A is connected to B, and B is connected to C, but A is not directly connected to C, A will still receive messages that C published to foo through B.
This can be very useful for routing messages in networks with poor NAT traversal or otherwise suboptimal connectivity.
To see all peers with pubsub enabled, check the output of:
ipfs pubsub peers
To see all the topics you are currently subscribed to, run:
ipfs pubsub ls
# Pubsub in the wild
In the video and links below yo can see how you might use ipfs pubsub to build a collaborative editor - ipfs.io 
YOUTUBE -kdx8rJd8rQ This is a tutorial on how to create Distributed Web Applications with CRDT (Conflict-Free Replicated Data Types) and the JavaScript Implementation of IPFS