Building a Decentralized Chat Peer: From Client-Server to P2P Networks

Introduction: Why Decentralized Chat?

In 2026, decentralized systems are everywhere — from blockchain-based social media to peer-to-peer file sharing. Imagine a chat app where no single server controls the conversation: that's the power of a decentralized network. This tutorial walks you through building a decentralized chat peer, inspired by the COMP90015 Distributed Systems Project 2. You'll move beyond the client-server model and create a peer that acts as both client and server. Let's dive into the core concepts, protocols, and extended features.

Understanding the Peer Architecture

In a decentralized chat system, every participant runs a peer — a process that can create rooms, host conversations, and connect to other peers. Unlike a traditional client-server setup, there is no central authority. Each peer maintains its own rooms and a list of neighboring peers. The identity of a user is their IP:port combination as seen by the peer hosting the room. This design ensures resilience: if one peer goes offline, the network continues.

Key Differences from Project 1

• No main hall: Users must first obtain a list of rooms from a connected peer and then join one.
• Local room management: Create and delete room commands are executed locally on the peer, no message passing needed.
• Neighbor lists: Each peer shares its list of connected peers, enabling iterative search across the network.

Base Protocol: The Essentials

The base protocol includes commands like list, join, who, kick, quit, and message. These behave similarly to Project 1 but with a twist: kick is a local command because only the room owner (the peer that created the room) can kick users. The message command broadcasts to all peers in the room.

Iterative Room Search

To find rooms, a peer connects to a known peer, requests its room list, and then asks for neighbor lists. This process repeats until all rooms are discovered. Think of it like exploring a social network: you ask a friend for their friends, and then ask those friends for more. This is similar to how decentralized apps (dApps) discover peers in blockchain networks.

Extended Feature I: Room Migration

Room migration allows a room to be moved from one peer to another. This is crucial when a peer wants to quit without losing the room. The migration process involves:

1. The quitting peer selects a target peer (ensuring all current room members can connect to the new host).
2. The room data (members list, message history) is transferred to the target peer.
3. All members are notified to reconnect to the new owner.

To prevent rooms from being lost, the migration must be atomic: if the target peer crashes during transfer, the room should remain on the original peer. This is similar to how a game server might migrate a match to a new server when the original host leaves — a concept seen in modern online gaming.

Extended Feature II: Shout Command

The shout command sends a message to all rooms across the entire network. This requires FIFO ordering: messages from the same user must be delivered in order at every room. To achieve this, you can use a sequence number per user and ensure that peers forward shouts along all paths. This is reminiscent of how viral tweets spread across platforms — but with guaranteed order.

Extended Feature III: File Attachment

File attachment allows users to send files with messages. The sender can either allow direct downloads (if they have a public IP) or upload the file to the room host. Downloads should be non-blocking — use multithreading or asynchronous I/O. Be careful with file system access to avoid vulnerabilities. This feature is similar to how modern messaging apps like WhatsApp handle attachments, but in a decentralized context.

Implementation Tips

• Use threading: Each peer should handle multiple connections concurrently. Python's threading or Java's ExecutorService work well.
• Protocol design: Use a simple text-based protocol with commands and responses. For example: JOIN room_name returns OK or ERROR.
• Error handling: Peers may disconnect unexpectedly. Implement timeout and retry mechanisms.

Trend Connection: Decentralized AI and Web3

In 2026, decentralized systems power AI model training (like federated learning) and Web3 applications. Your chat peer is a microcosm of these larger systems. Understanding peer-to-peer protocols prepares you for building distributed apps in finance (DeFi), gaming (metaverse), and social media (Mastodon-like networks).

Conclusion

Building a decentralized chat peer teaches you fundamental distributed systems concepts: peer discovery, state migration, FIFO ordering, and fault tolerance. By implementing room migration, shout, or file attachment, you'll gain practical experience in designing robust P2P protocols. Start with the base protocol, then extend it with your chosen feature. Happy coding!