A new federated chat network shipped this week with working tests, full documentation, and an unusual detail in its commit history: it was built largely with an AI coding assistant. In Parley, developer prologic describes a chat system where every person or team runs a small server for their own domain, and those servers federate the way email does. Developers reviewing the project say it reinvents about half of XMPP, a protocol built for the same problem years earlier, without XMPP’s years of hardening against abuse.
Table of Contents
- What Parley is
- The commit trail: built with an AI coding assistant
- The pushback: reinventing XMPP, worse
- The counterpoint: prior art isn’t automatically worth reusing
- The gap nobody answered in the thread
- What I’d check before shipping AI-scaffolded infrastructure
- FAQ
- Sources
What Parley is
According to prologic’s project page, Parley is “a chat network with no centre.” Identities look like email addresses (alice@foo.com), instances discover each other through DNS and signed well-known documents, and messages travel over HTTPS with detached ed25519 signatures that receivers verify against keys they discovered themselves. The whole network connects to ordinary IRC clients, irssi, WeeChat, Textual, without needing plugins.
Two more details from the project page matter here. First, channels come in two kinds: a #dev-style channel is global and replicated across every linked instance, and nobody owns it, so nobody can be kicked from it; moderation instead works as a per-account or per-instance block list. Second, prologic labels the project’s own status plainly: “working proof of concept… not hardened yet.”
The commit trail: built with an AI coding assistant
One commit visible in the project’s history, a fix for a bug where a shared nickname across instances triggered notifications for the wrong person, carries the line “Generated with Claude Code” and lists contributor David Collantes as a co-author. Collantes is also the person who submitted Parley to Hacker News, where he described the project in his own words in the comments.
Two commenters picked up on the same thread. someonebaggy asked simply, “Vibecoded?” bigfishrunning replied, “clearly.” The shorthand isn’t wrong: the project moved from idea to working federation, tests, and documentation fast, exactly the kind of speed AI coding assistants are good at. That speed doesn’t automatically include a literature review of what’s already been tried.
The pushback: reinventing XMPP, worse
Commenter Conlectus made the sharpest version of that argument: “This is basically a poorly specified implementation of half of XMPP.” Conlectus tied it to a pattern he sees more broadly in AI-assisted development, people building deep into a domain without ever touching the existing work already done in it, and added that he half expected an AI assistant to have flagged the overlap with XMPP itself, but the repository doesn’t mention it anywhere.
That’s a specific, checkable claim. XMPP already solved decentralized identity (JIDs that look like email addresses, same as Parley’s), federated message delivery between independently run servers, and presence and history sync across a network with no central authority. Parley’s design description covers the same ground, apparently without engaging with the twenty-plus years XMPP has spent finding out what breaks in a federated messaging network at scale.
The counterpoint: prior art isn’t automatically worth reusing
The discussion didn’t land cleanly on “just use XMPP,” though. Commenter dale_glass pushed back directly: “XMPP is an absolutely terrible protocol. IRC’s not much good either, but at least it has the excuse of being ancient and limited in what it wanted to achieve.” His point is fair: sending text messages between people shouldn’t require a protocol this painful to implement. XMPP’s extensibility model (XEPs layered on top of a base spec) is notoriously difficult to implement fully, and plenty of teams have chosen to build something narrower rather than take on that whole surface.
Reuse isn’t automatically the right call just because prior art exists. But “the existing standard is painful” is a more defensible reason to build something new than “we didn’t know it existed.”
The gap nobody answered in the thread
The most concrete gap raised in the discussion had nothing to do with XMPP. Commenter xena asked: “How do you plan to handle bad actors creating biblical amounts of servers dynamically and then spamming at line rate from all of those servers?” Nobody in the thread answered with a specific mitigation, and the project’s own description, as published, doesn’t cover it either.
That’s not a knock on automatic peering, Parley’s design where messaging someone on a new domain links the two instances on their own, without configuration. It’s a reminder that federated systems take years to work out abuse handling once real traffic shows up (email spam filtering and Matrix’s ongoing federation-abuse work are two long, still-unfinished examples). A project this new hasn’t had time to hit that problem yet, let alone solve it.
What I’d check before shipping AI-scaffolded infrastructure
None of this is an argument against using AI assistants to build real systems fast. Parley works, has tests, and has documentation, which is more than a lot of side projects ship with. My advice is narrower: anything that touches identity, federation, or security is exactly the category where “it works and passes tests” isn’t the same bar as “it’s been thought through.”
Before you ship something an AI assistant scaffolded in that category, spend an hour first asking what already tried to solve this problem, and why it succeeded or failed. If you review AI-written code, add a second pass beyond correctness: is this solving a problem someone already solved, with failure modes that are already documented? That question costs an hour. Reinventing a federated protocol’s abuse-handling problem from scratch, in production, costs a lot more.
FAQ
What is Parley?
Parley is a federated chat network built by developer prologic, where independent servers exchange signed messages over HTTPS and present the network to ordinary IRC clients. It’s a working proof of concept, not yet hardened for production use, according to its own project page.
Is it wrong to use AI to help build a new protocol?
Not by itself. The issue developers raised about Parley wasn’t that an AI assistant helped write it, but that the result appears to reinvent parts of an existing standard, XMPP, without the years of hardening against abuse that standard has behind it. The fix isn’t avoiding AI assistance; it’s spending time on prior art before writing the design.
Should you always reuse an existing protocol instead of building a new one?
Not automatically. XMPP itself is widely regarded as painful to implement fully, which is a legitimate reason to build something narrower. The distinction that matters is whether you knew the existing option and chose not to use it, versus not knowing it existed at all.
Sources
- Article: Parley: Federated, decentralised chat that speaks plain IRC, by prologic.
- Discussion: Hacker News thread, for the counterpoints on reinventing XMPP, XMPP’s own implementation difficulty, and the unanswered spam-handling question.