Parley Makes Federated Chat Feel Like Plain IRC

Two terminals are open. Alice connects to one server, Bob connects to another, and both type in the same familiar IRC room. Nobody installs a special chat client. Nobody signs up with a single company. Then Bob sends /msg [email protected] hi, and the two servers figure out how to deliver it.

That is Parley’s pitch: federated, decentralized chat with plain IRC at the front. IRC, or Internet Relay Chat, is the text-based chat protocol behind commands such as /join and /msg. Parley keeps that language while allowing independently operated servers to exchange messages. An instance is one separately run copy of the server, usually associated with a domain such as foo.com; federation is the process by which those instances share events.

The familiar front door

Parley’s parleyd daemon speaks IRC to local clients. An IRC client is a program that connects to a chat server, such as irssi, WeeChat, or Textual. From the client’s point of view, the experience remains pleasantly old-fashioned:

/join #lobby
/msg [email protected] hi
/whois [email protected]

The server also supports selected IRCv3 features. IRCv3 is a collection of modern extensions to the original IRC protocol, adding details such as message timestamps, structured tags, reply markers, and typing indicators. Those extras let a modern client behave well without replacing the protocol underneath.

This division is important. Parley can experiment with distributed identity and message delivery while people continue using tools they already understand. The network changes behind the chat window; the front door still looks like IRC.

How does federated IRC work?

The interesting machinery begins when the target lives on another domain. Imagine Bob connecting to bar.com and sending a message to Alice at foo.com:

IRC client -> parleyd on bar.com
 |
 signed HTTPS request
 v
 parleyd on foo.com -> Alice

First, Bob’s client sends an ordinary IRC PRIVMSG to the local Parley instance. The instance sees [email protected] and needs to find the server responsible for foo.com.

It uses the Domain Name System, or DNS, which turns names into network destinations. Parley looks for an _parley._tcp service record, known as an SRV record, that points to the remote endpoint. If that record is absent, the instance can fall back to a predictable well-known document under the domain’s HTTPS address.

The remote instance document publishes the domain’s identity and public key. Parley then creates a small JSON event, signs it with its Ed25519 instance key, and sends it to the other server’s /inbox endpoint over HTTPS. Ed25519 is a public-key signature system: the sender signs with a private key, while the receiver checks the signature with the public key it discovered independently.

If the signature checks out, foo.com accepts the event, stores it, and delivers the message to Alice’s IRC session. The instances can also exchange channel membership and known-peer information, allowing the network to grow without a central directory.

Two kinds of room

Parley gives IRC channels two different boundaries. A channel such as #dev is global: it can be replicated across linked instances when those instances have members in the room. A channel such as &notes is local and never leaves the instance where it was created.

That distinction makes the topology visible in the syntax. #dev feels like a shared public room, while &notes is a private corner of one server. Global channels do not have a single operator or topic authority, because no central server owns them. Their state is eventually consistent, meaning independent copies converge after messages arrive rather than receiving every decision from one master.

Each instance also keeps local history in an embedded database and can catch up after a peer has been offline. The result is less like a transient connection between two clients and more like a collection of cooperating mailboxes that happen to speak IRC in real time.

The hard part is knowing who “bob” means

Federation exposes a small problem that centralized chat can hide. Suppose a channel contains [email protected] and [email protected]. Both users have the same nickname, but they are different accounts.

A message crosses the federation as typed. If a server looks for the word bob and treats a trailing colon as punctuation, a line such as this can wake both users:

bob:bar.com: lunch?

The recent Parley fix treats a displayed name as an identity, not as loose text. A qualified form such as bob:bar.com means the Bob on bar.com, much like the address [email protected]. A bare bob refers to the Bob on the sender’s own instance. A remote server no longer reinterprets that bare nickname as its local Bob.

This rule sounds narrow, but it captures a larger distributed-systems lesson. Notifications are local effects, while message text is shared data. Once the same text reaches several servers, every server needs the same understanding of which account the sender intended. Parley’s cross-instance tests link two servers, place a Bob on each, and verify that each example pushes a notification only to the named account.

Running an instance

A local experiment can start with a command like this:

parleyd \
 -domain example.com \
 -endpoint https://chat.example.com

For production, the endpoint needs HTTPS, a DNS service record, and persistent storage for the instance key, accounts, peer state, and message history. The IRC listener is plaintext by default, so operators normally put a Transport Layer Security (TLS) proxy in front of it for encrypted client connections.

Accounts and IRC tokens are managed through parleyctl, the administration interface, or the web settings pages. Process-level settings come from flags and environment variables, while changing runtime behavior belongs in the instance database rather than a sprawling configuration file.

As of September 28, 2026, the current tagged release is v0.5.0, and the project still describes itself as a working proof of concept rather than a hardened production service. That honesty matters. Parley currently uses instance-level signing keys rather than per-user keys, so it does not yet provide end-to-end encryption for direct messages. Global channels also accept the compromises of a distributed system: delivery can be delayed, and no universal channel operator exists.

Parley is compelling because it does not hide those trade-offs behind a new interface. It keeps the plain IRC client, gives each domain control over its own users, and builds cooperation through signed messages and discoverable identities. Even a nickname notification bug becomes a protocol question, which is exactly what makes the project such an interesting place to watch federated chat take shape.