AI coding speed won’t help a new protocol until you check what already tried to solve the problem. Parley, a federated chat network by developer prologic, shipped with working tests and full docs. It was built largely with an AI coding assistant.
Developers reviewing it say it reinvents about half of XMPP. XMPP was built for the same problem years earlier, and Parley has none of its hardening against abuse.
Table of Contents
- What Parley built, and how fast
- Why passing tests won’t catch a reinvented protocol
- Check prior art before you write the design
- What to check before shipping AI-scaffolded infrastructure
- FAQ
- Sources
What Parley built, and how fast
According to prologic’s project page, Parley is “a chat network with no centre.” Every person or team runs a small server for their own domain, and those servers federate the way email does. Identities look like email addresses (alice@foo.com). Instances discover each other through DNS and signed well-known documents. Messages travel over HTTPS with detached ed25519 signatures, which receivers verify against keys they discovered themselves. The network connects to ordinary IRC clients like irssi, WeeChat and Textual, with no plugins.
Channels come in two kinds. A #dev-style channel is global and replicated across every linked instance. Nobody owns it, so nobody can be kicked from it. Moderation works as a per-account or per-instance block list instead. prologic labels the project’s status plainly: “working proof of concept… not hardened yet.”
The commit history shows how it was built. One commit fixes a bug where a shared nickname across instances notified the wrong person. It carries the line “Generated with Claude Code” and lists contributor David Collantes as a co-author. Collantes also submitted Parley to Hacker News and described the project in his own words in the comments.
“Vibecoded?” one commenter asked. Another replied, “clearly.” The shorthand fits: the project went from idea to working federation, tests and documentation fast. That’s exactly the speed AI coding assistants are good at.
Why passing tests won’t catch a reinvented protocol
Speed doesn’t come with a literature review of what’s already been tried. Tests check that the code does what it says. They can’t tell you someone solved the same problem twenty years ago.
The sharpest version of the argument came from one developer: “This is basically a poorly specified implementation of half of XMPP.” They tied it to a broader pattern in AI-assisted development. People build deep into a domain without touching the existing work already done in it. They half expected an AI assistant to flag the overlap with XMPP itself. The repository doesn’t mention XMPP anywhere.
That’s a specific, checkable claim. XMPP already solved decentralized identity, with JIDs that look like email addresses, same as Parley’s. It solved federated delivery between independently run servers. It handles presence and history sync across a network with no central authority. Parley’s design covers the same ground. It apparently skips the twenty-plus years XMPP has spent finding out what breaks in federated messaging at scale.
The most concrete gap had nothing to do with XMPP. One developer 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. The project’s published description doesn’t cover it either.
Automatic peering is Parley’s design choice: messaging someone on a new domain links the two instances with no configuration. That’s a fair design. Federated systems still 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.
Check prior art before you write the design
The precondition is knowing what already exists. That doesn’t mean you must reuse it, and the discussion didn’t land cleanly on “just use XMPP.”
“XMPP is an absolutely terrible protocol,” one developer replied. “IRC’s not much good either, but at least it has the excuse of being ancient and limited in what it wanted to achieve.” That’s a fair point. Sending text between people shouldn’t need a protocol this painful to implement. XMPP layers XEPs on top of a base spec, and that extensibility model is notoriously hard to implement fully. Plenty of teams have built something narrower rather than take on that whole surface.
Prior art existing doesn’t make reuse the right call. “The existing standard is painful” is a defensible reason to build something new. “We didn’t know it existed” is a much weaker one.
What to check before shipping AI-scaffolded infrastructure
This isn’t 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. For identity, federation or security, “it works and passes tests” is a lower bar than “it’s been thought through.”
- Before you ship something an AI assistant scaffolded in that category, spend an hour on prior art.
- Ask what already tried to solve this problem, and why it succeeded or failed.
- When you review AI-written code, add a second pass beyond correctness. Is this solving a problem someone already solved, with failure modes already documented?
That check costs an hour. Reinventing a federated protocol’s abuse handling from scratch, in production, costs a lot more.
Speed versus scrutiny isn’t a small-project problem either. When I covered Anthropic’s move off git, engineers there described the same tension at a much larger scale. A model will happily chase a plausible fix for hours, and someone still has to know enough to say no.
Review this kind of output for a living? The checklist I use is Reviewing AI-generated pull requests.
FAQ
What is Parley?
Parley is a federated chat network built by developer prologic. Independent servers exchange signed messages over HTTPS and present the network to ordinary IRC clients. Its own project page calls it a working proof of concept, not yet hardened for production use.
Is it wrong to use AI to help build a new protocol?
Not by itself. Developers didn’t object to an AI assistant helping write Parley. They objected that the result appears to reinvent parts of XMPP without that standard’s years of hardening against abuse. The fix is 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. What matters is whether you knew the existing option and chose not to use it.
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.