diff --git a/content/concepts/pubsub/_index.md b/content/concepts/pubsub/_index.md
index 8622e4a8..d6a5b26a 100644
--- a/content/concepts/pubsub/_index.md
+++ b/content/concepts/pubsub/_index.md
@@ -1,5 +1,5 @@
---
title : "Publish/Subscribe"
-description: "We want libp2p applications to run everywhere, not just in data centers or on machines with stable public IP addresses. Learn about the main approaches to NAT traversal available in libp2p."
+description: "Publish/Subscribe is a system where peers congregate around topics they are interested in. Peers interested in a topic are said to be subscribed to that topic. Learn about how peers can message data in libp2p."
weight: 7
---
diff --git a/content/concepts/pubsub/gossipsub.md b/content/concepts/pubsub/gossipsub.md
new file mode 100644
index 00000000..fa22ece2
--- /dev/null
+++ b/content/concepts/pubsub/gossipsub.md
@@ -0,0 +1,321 @@
+---
+title: "GossipSub"
+description: "GossipSub is a gossip-based Publish/Subscribe protocol that allows for efficient message dissemination and topic-based subscription."
+weight: 232
+---
+
+## Overview
+
+GossipSub is a gossip-based Publish/Subscribe protocol in libp2p. It allows for efficient
+message dissemination and topic-based subscription. The protocol is designed to be
+scalable, resilient to network partitions, and resistant to malicious actors.
+
+**GossipSub v1.1** is the latest version of the protocol, and it introduces several new features
+and improvements over v1.0. These include:
+
+- **Explicit peering agreements**: a mechanism for node operators to establish and maintain
+ connections with a predefined set of peers, regardless of the peer scoring system and other
+ defensive measures.
+- **PRUNE backoff and peer exchange**: a mechanism for bootstrapping the network and mitigating
+ oversubscription by providing a set of alternative peers for a pruned peer to connect to.
+- **Improved peer scoring**: a more sophisticated scoring function that considers
+ various metrics such as time in mesh, message delivery rate, and invalid messages.
+- **Extended validators**: a mechanism for application-specific message validation, allowing for
+ more fine-grained control over message delivery and forwarding.
+
+## Types of peering
+
+In gossipsub, peers connect via either **full-message** peerings
+or **metadata-only** peerings. The overall network structure is made up of these
+two networks:
+
+
+
+### Full-message
+
+Full-message peerings are used to transmit the full contents of messages
+throughout the network. This network is sparsely connected, with each peer only
+being connected to a few others. (In the
+[gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
+this sparsely-connected network is called a *mesh*, and peers within it are
+called *mesh members*.)
+
+Limiting the number of full-message peerings is helpful because it keeps the
+amount of network traffic under control; each peer only forwards messages to a
+few others rather than all. Each peer has a target number of peers
+it wants to be connected to. In this example, each peer would ideally like to be
+connected to 3 other peers but would settle
+for 2–4
+connections:
+
+
+
+{{< alert icon="💡" context="note">}}
+Throughout this guide, numbers highlighted in purple can be configured
+by the developer.
+{{< /alert >}}
+
+The peering degree (also called the *network degree* or *D*) controls the
+trade-off between speed, reliability, resilience, and efficiency of the network.
+A higher peering degree helps messages get delivered faster, with a better
+chance of reaching all subscribers and less chance of any peer disrupting
+the network by leaving. However, a high peering degree also causes additional
+redundant copies of each message to be sent throughout the network, increasing
+the bandwidth required to participate.
+
+### Metadata-only
+
+In addition to the sparsely-connected network of full-message peerings, there is
+also a densely-connected network of metadata-only peerings. This network is made
+up of all the network connections between peers that aren't full-message
+peerings.
+
+The metadata-only network shares gossip about which messages are available and
+performs functions to help maintain the network of full-message peerings.
+
+
+
+## Grafting and pruning
+
+Peerings are **bidirectional**, meaning that for any two connected peers, both
+peers consider their connection to be full-message, or both peers consider their
+connection to be metadata-only.
+
+Either peer can change the connection type by notifying the other. **Grafting** is
+converting a metadata-only connection to a full message. **Pruning**
+is the opposite process, converting a full-message peering to metadata-only:
+
+
+
+When a peer has too few full-message peerings, it will randomly graft some of its
+metadata-only peerings to become full-message peerings:
+
+
+
+Conversely, when a peer has too many full-message peerings, it will randomly
+prune some of them back to metadata-only:
+
+
+
+In libp2p's implementation, each peer performs a series of checks every
+1 second. These checks are called the
+*heartbeat*. Grafting and pruning happen during this time.
+
+### Peering Agreements
+
+GossipSub v1.1 introduces explicit peering agreements, a mechanism for node operators to establish
+and maintain connections with a predefined set of peers, regardless of the peer scoring system and
+other defensive measures.
+
+The router must establish and maintain a connection
+with every explicit peer. The connections are initially set when the router boots and are
+periodically checked for connectivity and reconnected if the connectivity is lost. With explicit
+peering, the application can specify a list of peers to remain connected and
+forward messages to each other unconditionally.
+
+Explicit peers exist outside the mesh: every new valid incoming message is forwarded to the direct
+peers, and incoming RPCs are always accepted. It is an error to GRAFT on an explicit peer, and such
+an attempt should be logged and rejected with a PRUNE.
+
+### PRUNE Backoff and Peer Exchange
+
+Gossipsub v1.1 introduces PRUNE backoff and peer exchange, a mechanism for bootstrapping the network
+and mitigating oversubscription. When a peer is pruned from the mesh because of oversubscription,
+instead of simply telling the pruned peer to go away, the pruning peer may provide a set of other
+peers whom the pruned peer can connect to reform its mesh. This allows for more efficient bootstrapping
+of the network, as the pruned peer can quickly find new peers to form its mesh without relying on an
+external peer discovery service.
+
+When a peer tries to regraft too early, the pruning peer may apply a behavioral penalty for the action
+and penalize the peer. In addition, both the pruned and the pruning peer add a backoff period from each
+other, within which they will not try to regraft. This helps prevent constant regrafting attempts and
+allows for a more stable network.
+
+When unsubscribing from a topic, the backoff period should be finished before subscribing to the topic
+again. Otherwise, a healthy mesh will be difficult to reach. A shorter backoff period can be used in case
+of an unsubscribe event, allowing faster resubscribing.
+
+## Peer Scoring
+
+GossipSub uses a peer scoring system to decide which peers to keep in the mesh and which to prune.
+The scoring system considers parameters such as time in mesh, message delivery rate,
+and invalid messages. The scoring function is configurable by the application and can be tuned to
+the specific needs of the application.
+
+### The Score Function
+
+A scoring function evaluates the quality of a peer's participation in the
+mesh for each topic. The score function determines which peers to prune,
+retain, and accept when new peers want to join the mesh. The score is a weighted combination of several
+parameters, some of which are specific to a topic and others that apply globally.
+
+### Topic Parameter Calculation and Decay
+
+Topic parameters are used by the score function and are maintained by the router. These parameters are
+updated whenever an event of interest occurs, such as when a message is forwarded, or a peer is pruned.
+To prevent these parameters from continuously increasing, they are subject to decay. The application
+can configure the decay interval with shorter intervals resulting in a faster decay of the parameters.
+
+### Guidelines for Tuning the Scoring Function
+
+The scoring function has several configurable parameters that can be adjusted to suit the needs of an
+application. However, determining the optimal configuration for these parameters can be challenging.
+The GossipSub v1.1 specification provides guidelines for tuning the scoring
+function based on simulation results to aid in this process. These guidelines will help developers
+understand how to adjust their specific use case parameters.
+
+## Gossip Protocol
+
+GossipSub uses "gossiping" for message dissemination and topic-based subscription.
+Each peer maintains a set of connections to other peers in the network, called the *mesh*.
+Peers exchange and control messages to keep their mesh state up to date.
+
+Peers gossip about messages they have recently seen. Every
+1 second, each peer randomly selects
+6 metadata-only peers and sends them a list of messages
+recently seen.
+
+
+
+Gossiping lets peers notice if they missed a message on the
+full-message network. If a peer notices it is repeatedly missing messages, it can set up new
+full-message peerings with peers that do have the messages.
+
+Here is an example of how a specific message can be requested across a
+metadata-only peering:
+
+
+
+In the [gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md#control-messages),
+gossip announcing recently seen messages are called `IHAVE` messages and
+requests for specific messages are called `IWANT` messages.
+
+### Topic-based Subscription
+
+A peer can subscribe to one or more topics by sending a `SUBSCRIBE` control message
+to its mesh peers. The message includes a list of topics the peer is interested in.
+When a peer receives a `SUBSCRIBE` message, it adds the peer to its mesh for the
+specified topics.
+
+Peers keep track of which topics their directly-connected peers are subscribed
+to. Using this information, each peer can build up a picture of the topics
+around them and which peers are subscribed to each topic:
+
+
+
+Keeping track of subscriptions happens by sending SUBSCRIBE and
+UNSUBSCRIBE messages. When a new connection is established between two peers,
+they start by sending each other the list of topics they are subscribed to:
+
+
+
+Then over time, whenever a peer subscribes or unsubscribes from a topic, it will
+send each of its peers a subscribe or unsubscribe message. These messages are
+sent to all connected peers regardless of whether the receiving peer is
+subscribed to the topic in question:
+
+
+
+Subscribe and unsubscribe messages go hand-in-hand with graft and prune
+messages. When a peer subscribes to a topic, it will pick some peers that will
+become its full-message peers for that topic and send them graft messages at the
+same time as their subscribe messages:
+
+
+
+When a peer unsubscribes from a topic, it will notify its full-message peers that
+their connection has been pruned at the same time as sending their unsubscribe
+messages:
+
+
+
+## Sending messages
+
+When a peer wants to publish a message, it sends a copy to all full-message peers
+it is connected to the following:
+
+
+
+Similarly, when a peer receives a new message from another peer, it stores the
+message and forwards a copy to all other full-message peers it is connected to:
+
+
+
+In the [gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md#controlling-the-flood),
+peers are also known as *routers* because of the function they have in routing
+messages through the network.
+
+Peers remember a list of recently seen messages. This lets peers act upon a
+message only the first time they see it and ignore retransmissions of already
+seen messages.
+
+Peers might also choose to validate the contents of each message received. What
+counts as valid and invalid depends on the application. For example, a chat
+application might enforce that all messages must be shorter than 100 characters.
+If the application tells libp2p that a message is invalid, then that message will
+be dropped and not replicated further through the network.
+
+### Message Forwarding
+
+When a peer receives a message for a topic it is subscribed to, it forwards the message to
+all its mesh peers. The protocol uses a flooding algorithm to ensure that all messages are
+disseminated throughout the network promptly. However, to prevent overloading the
+network, a peer may choose only to forward a subset of messages to its mesh peers using a
+configurable parameter called the `GossipFactor`.
+
+## Fan-out
+
+Peers are allowed to publish messages to topics they are not subscribed to.
+There are some special rules about how to do this to help ensure these messages
+are delivered reliably.
+
+The first time a peer wants to publish a message on a topic, it is not subscribed
+to, it randomly picks 6 peers
+(3 shown below) that are
+subscribed to that topic and remembers them as **fan-out** peers for that topic:
+
+
+
+Unlike the other types of peering, fan-out peerings are unidirectional; they
+always point from the peer outside the topic to a peer subscribed to the topic.
+Peers subscribed to the topic are not told they have been selected
+and still treat the connection as any other metadata-only peering.
+
+Each time the sender wants to send a message, it sends the message to its
+fan-out peers, who then distribute the message within the topic:
+
+
+
+If the sender goes to send a message but notices some of their fan-out peers
+went away since last time, they will randomly select additional fan-out peers
+to top them back up to 6.
+
+When a peer subscribes to a topic, if it already has some fan-out peers, it will
+prefer them to become full-message peers:
+
+
+
+After 2 minutes of not sending any messages to
+a topic, all the fan-out peers for that topic are forgotten:
+
+
+
+### Extended Validators
+
+Gossipsub v1.1 introduces the concept of extended validators, which allows the application
+to specify a more fine-grained message validation process. Extended validators provide more
+control over how messages are handled, allowing the application to ignore particular messages
+without triggering the penalty for invalid messages.
+
+## Network packets
+
+The packets that peers send each other over the network combine all the
+different message types in this guide (application messages, have/want,
+subscribe/unsubscribe, graft/prune). This structure allows several requests to
+be batched and sent in a single network packet.
+
+Here is a graphical representation of the overall network packet structure:
+
+
+
+{{< alert icon="💡" context="note" text="See the GossipSub v1.1 technical specification for more details." />}}
diff --git a/content/concepts/pubsub/overview.md b/content/concepts/pubsub/overview.md
index fc1446d9..f74112ae 100644
--- a/content/concepts/pubsub/overview.md
+++ b/content/concepts/pubsub/overview.md
@@ -9,620 +9,65 @@ aliases:
## Overview
-Publish/Subscribe is a system where peers congregate around topics they are
-interested in. Peers interested in a topic are said to be subscribed to that
-topic:
-
-
-
-
-
-Peers can send messages to topics. Each message gets delivered to all peers
-subscribed to the topic:
-
-
-
-
-
-Example uses of pub/sub:
-
-* **Chat rooms.** Each room is a pub/sub topic and clients post chat messages to
- which are received by all other clients in the room.
-* **File sharing.** Each pub/sub topic represents a file that can be downloaded.
- Uploaders and downloaders advertise which pieces of the file they have in
- the pub/sub topic and coordinate downloads that will happen outside the
- pub/sub system.
-
-## Design goals
-
-In a peer-to-peer pub/sub system all peers participate in delivering messages
-throughout the network. There are several different designs for peer-to-peer
-pub/sub systems which offer different trade-offs. Desirable properties include:
-
-* **Reliability:** All messages get delivered to all peers subscribed to the topic.
-* **Speed:** Messages are delivered quickly.
-* **Efficiency:** The network is not flooded with excess copies of messages.
-* **Resilience:** Peers can join and leave the network without disrupting it.
+Publish/Subscribe (PubSub) is a messaging pattern where senders of messages, known as
+publishers, do not send them directly to specific receivers; instead, they send them to
+a topic or a channel that contains subscribers. Subscribers can express interest
+in one or more topics and only receive messages that are of interest to them.
+This allows for a decoupling of senders and receivers and multiple subscribers to receive
+the same message.
+
+PubSub systems that are centralized rely on a centralized broker, known as a message
+broker, which is responsible for filtering and forwarding messages. In P2P PubSub systems,
+however, there is no centralized broker. Instead, each node in the network is both a
+publisher and a subscriber and is responsible for forwarding messages to other nodes.
+All peers participate in delivering messages throughout the network.
+
+There are different types of PubSub models, like event-based, data-centric, content-based,
+and topic-based, each with its use cases and advantages. The event-based model is useful
+for systems that react to specific events in real time, while the data-centric model is best
+suited for systems that share and synchronize data among multiple nodes. Content-based and
+topic-based models provide more fine-grained control over message filtering and routing.
+In general, desirable model properties include:
+
+- **Reliability**: All messages get delivered to all peers subscribed to the topic.
+- **Speed**: Messages are delivered quickly.
+- **Efficiency**: The network is not flooded with excess copies of messages.
+- **Resilience**: Peers can join and leave the network without disrupting it.
There is no central point of failure.
-* **Scale:** Topics can have enormous numbers of subscribers and handle a large
- throughput of messages.
-* **Simplicity:** The system is simple to understand and implement. Each peer
- only needs to remember a small amount of state.
-
-libp2p currently uses a design called **gossipsub**. It is named after the fact
-that peers gossip to each other about which messages they have seen and use this
-information to maintain a message delivery network.
-
-## Discovery
-
-Before a peer can subscribe to a topic it must find other peers and establish
-network connections with them. The pub/sub system doesn’t have any way to
-discover peers by itself. Instead, it relies upon the application to find new
-peers on its behalf, a process called **ambient peer discovery**.
-
-Potential methods for discovering peers include:
-
-* Distributed hash tables
-* Local network broadcasts
-* Exchanging peer lists with existing peers
-* Centralized trackers or rendezvous points
-* Lists of bootstrap peers
-
-For example, in a BitTorrent application, most of the above methods would
-already be used in the process of downloading files. By reusing peers found
-while the BitTorrent application goes about its regular business, the
-application could build up a robust pub/sub network too.
-
-Discovered peers are asked if they support the pub/sub protocol, and if so, are
-added to the pub/sub network.
-
-## Types of peering
-
-In gossipsub, peers connect to each other via either **full-message** peerings
-or **metadata-only** peerings. The overall network structure is made up of these
-two networks:
-
-
-
-
-
-### Full-message
-
-Full-message peerings are used to transmit the full contents of messages
-throughout the network. This network is sparsely-connected with each peer only
-being connected to a few other peers. (In the
-[gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
-this sparsely-connected network is called a *mesh* and peers within it are
-called *mesh members*.)
-
-Limiting the number of full-message peerings is useful because it keeps the
-amount of network traffic under control; each peer only forwards messages to a
-few other peers, rather than all of them. Each peer has a target number of peers
-it wants to be connected to. In this example each peer would ideally like to be
-connected to 3 other peers, but would settle
-for 2–4
-connections:
-
-
-
-
-
-{{< alert icon="💡" context="note">}}
-Throughout this guide, numbers highlighted in purple can be configured
-by the developer.
-{{< /alert >}}
-
-The peering degree (also called the *network degree* or *D*) controls the
-trade-off between speed, reliability, resilience and efficiency of the network.
-A higher peering degree helps messages get delivered faster, with a better
-chance of reaching all subscribers and with less chance of any peer disrupting
-the network by leaving. However, a high peering degree also causes additional
-redundant copies of each message to be sent throughout the network, increasing
-the bandwidth required to participate in the network.
-
-In libp2p’s default implementation the ideal network peering degree is
-6 with anywhere from
-4–12
-being acceptable.
-
-### Metadata-only
-
-In addition to the sparsely-connected network of full-message peerings, there is
-also a densely-connected network of metadata-only peerings. This network is made
-up of all the network connections between peers that aren’t full-message
-peerings.
-
-The metadata-only network shares gossip about which messages are available and
-performs functions to help maintain the network of full-message peerings.
-
-
-
-
-
-## Grafting and pruning
-
-Peerings are **bidirectional**, meaning that for any two connected peers, both
-peers consider their connection to be full-message or both peers consider their
-connection to be metadata-only.
-
-Either peer can change the connection type by notifying the other. **Grafting** is
-the process of converting a metadata-only connection to full-message. **Pruning**
-is the opposite process; converting a full-message peering to metadata-only:
-
-
-
-
-
-When a peer has too few full-message peerings it will randomly graft some of its
-metadata-only peerings to become full-message peerings:
-
-
-
-
-
-Conversely, when a peer has too many full-message peerings it will randomly
-prune some of them back to metadata-only:
-
-
-
-
-
-In libp2p’s implementation, each peer performs a series of checks every
-1 second. These checks are called the
-*heartbeat*. Grafting and pruning happens during this time.
-
-## Subscribing and unsubscribing
-
-Peers keep track of which topics their directly-connected peers are subscribed
-to. Using this information each peer is able to build up a picture of the topics
-around them and which peers are subscribed to each topic:
-
-
-
-
-
-Keeping track of subscriptions happens by sending **subscribe** and
-**unsubscribe** messages. When a new connection is established between two peers
-they start by sending each other the list of topics they are subscribed to:
-
-
-
-
-
-Then over time, whenever a peer subscribes or unsubscribes from a topic, it will
-send each of its peers a subscribe or unsubscribe message. These messages are
-sent to all connected peers regardless of whether the receiving peer is
-subscribed to the topic in question:
-
-
-
-
-
-Subscribe and unsubscribe messages go hand-in-hand with graft and prune
-messages. When a peer subscribes to a topic it will pick some peers that will
-become its full-message peers for that topic and send them graft messages at the
-same time as their subscribe messages:
-
-
-
-
-
-When a peer unsubscribes from a topic it will notify its full-message peers that
-their connection has been pruned at the same time as sending their unsubscribe
-messages:
-
-
-
-
-
-## Sending messages
-
-When a peer wants to publish a message it sends a copy to all full-message peers
-it is connected to:
-
-
-
-
-
-Similarly, when a peer receives a new message from another peer, it stores the
-message and forwards a copy to all other full-message peers it is connected to:
-
-
-
-
-
-In the [gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md#controlling-the-flood),
-peers are also known as *routers* because of this function they have in routing
-messages through the network.
-
-Peers remember a list of recently seen messages. This lets peers act upon a
-message only the first time they see it and ignore retransmissions of already
-seen messages.
-
-Peers might also choose to validate the contents of each message received. What
-counts as valid and invalid depends on the application. For example, a chat
-application might enforce that all messages must be shorter than 100 characters.
-If the application tells libp2p that a message is invalid then that message will
-be dropped and not replicated further through the network.
-
-## Gossip
-
-Peers gossip about messages they have recently seen. Every
-1 second each peer randomly selects
-6 metadata-only peers and sends them a list of
-recently seen messages.
-
-
-
-
-
-Gossiping gives peers a chance to notice in case they missed a message on the
-full-message network. If a peer notices it is repeatedly missing messages then
-it can set up new full-message peerings with peers that do have the messages.
-
-Here is an example of how a specific message can be requested across a
-metadata-only peering:
-
-
-
-
-
-In the [gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md#control-messages),
-gossip announcing recently seen messages are called *IHAVE* messages and
-requests for specific messages are called *IWANT* messages.
-
-## Fan-out
-
-Peers are allowed to publish messages to topics they are not subscribed to.
-There are some special rules about how to do this to help ensure these messages
-are delivered reliably.
-
-The first time a peer wants to publish a message to a topic it is not subscribed
-to, it randomly picks 6 peers
-(3 shown below) that are
-subscribed to that topic and remembers them as **fan-out** peers for that topic:
-
-
-
-
-
-Unlike the other types of peering, fan-out peerings are unidirectional; they
-always point from the peer outside the topic to a peer subscribed to the topic.
-Peers subscribed to the topic are not told that they have been selected
-and still treat the connection as any other metadata-only peering.
-
-Each time the sender wants to send a message, it sends the message to its
-fan-out peers, who then distribute the message within the topic:
-
-
-
-
-
-If the sender goes to send a message but notices some of their fan-out peers
-went away since last time, they will randomly select additional fan-out peers
-to top them back up to 6.
-
-When a peer subscribes to a topic, if it already has some fan-out peers it will
-prefer them to become the full-message peers:
-
-
-
-
-
-After 2 minutes of not sending any messages to
-a topic, all the fan-out peers for that topic are forgotten:
-
-
-
-
-
-## Network packets
-
-The packets that peers actually send each other over the network are a
-combination of all the different message types seen in this guide (application
-messages, have/want, subscribe/unsubscribe, graft/prune). This structure allows
-several different requests to be batched up and sent in a single network packet.
-
-Here is a graphical representation of the overall network packet structure:
-
-
-
-
-
-See the [specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md#protobuf) for the exact [Protocol Buffers](https://developers.google.com/protocol-buffers)
-schema used to encode network packets.
-
-## State
-
-Here is a summary of the state each peer must remember to participate in the
-pub/sub network:
-
-* **Subscriptions:** List of topics subscribed to.
-* **Fan-out topics:** These are the topics messaged recently but not subscribed
- to. For each topic the time of the last sent message to that topic is
- remembered.
-* **List of peers currently connected to:** For each peer connected to, the
- state includes all the topics they are subscribed to and whether the peering
- for each topic is full-content, metadata-only or fan-out.
-* **Recently seen messages**: This is a cache of recently seen messages. It is
- used to detect and ignore retransmitted messages. For each message the state
- includes who sent it and the sequence number, which is enough to uniquely
- identify any message. For very recent messages, the full message contents
- is kept so that it can be sent to any peers that request the message.
-
-
-
-
-
-## More information
-
-For more detail and a discussion of other pub/sub designs that influenced the
-design of gossipsub, see the [gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md).
-
-For implementation details, see the [gossipsub.go](https://github.com/libp2p/go-libp2p-pubsub/blob/master/gossipsub.go)
-file in the source code of [go-libp2p-pubsub](https://github.com/libp2p/go-libp2p-pubsub),
-which is the canonical implementation of gossipsub in libp2p.
+- **Scale**: Topics can have enormous subscribers and handle a large throughput of messages.
+- **Simplicity**: The system is simple to understand and implement. Each peer only needs to
+ remember a small amount of state.
+
+### PubSub for the distributed web
+
+There are many P2P applications that can stem from using a P2P-based PubSub system, including:
+
+- **Decentralized Social Networking**: Each user is a peer and can create and join different
+ groups or topics, where they can post and receive updates, messages, and comments in real time.
+- **Decentralized File Sharing**: Peers can advertise files on a specific topic, and others can subscribe
+ to that topic to later on download the file. The peers can also share information about the availability
+ of different parts of the file, allowing for faster and more efficient downloads.
+- **Distributed Gaming**: Each game room is a topic, and players can publish and receive updates,
+ messages, and events in real time as they play.
+- **IoT and Smart Home**: IoT devices can publish sensor data on specific topics, and other devices or
+ applications can subscribe to these topics to receive the data and take appropriate actions.
+- **Decentralized Marketplaces**: Peers can publish and discover goods and services on specific topics
+ and communicate and transact with each other through the PubSub system.
+- **Decentralized Chat and Video Conferencing**: Peers can create and join specific chat rooms or video
+ conference rooms and publish and receive real-time messages and advertise audio/video streams.
+
+## Publish/Subscribe in libp2p
+
+The PubSub system in libp2p allows peers to congregate around topics of interest and communicate in
+real-time. Peers can express interest in one or more topics and send and receive messages on these topics.
+
+While the PubSub system in libp2p is scalable and fault-tolerant, P2P-based PubSub systems pose new
+challenges. One of the main challenges is ensuring that messages are delivered to all interested parties
+promptly and efficiently. This is particularly challenging in large and dynamic networks, where the topology
+and the set of subscribers can change frequently.
+
+To address this challenge and many others (described here), libp2p uses a PubSub protocol called
+[GossipSub](gossipsub.md), a gossip-based protocol named after the fact that peers gossip to each other about
+which messages they have seen, and uses this information to maintain a message delivery network.
+
+Learn more about GossipSub [here](gossipsub.md).