Parley: Federated, decentralised chat that speaks plain IRC

Original Article ↗ Hacker News Discussion ↗

A new project called Parley proposes a federated, decentralized chat system that uses HTTP+JSON under the hood while presenting itself as plain IRC to clients. Commenters compare it to earlier standards like XMPP, Matrix, and ActivityPub, arguing over whether it meaningfully improves on existing protocols or simply reinvents them, and raising concerns about spam, moderation without channel operators, and handling identity and netsplits in an untrusted federation. The thread also surfaces broader unease about LLM-assisted development and why something as seemingly simple as “sending text over the internet” has repeatedly resulted in complex, hard-to-implement messaging systems.

Project overview & goals

  • Parley is a federated, decentralized chat system where each person/team runs their own instance.
  • Instances discover each other via DNS and well-known documents, exchange signed messages over HTTPS, and expose a plain IRC interface so existing IRC clients work without plugins.
  • Local channels (&room) are server-only; global channels (#room) are federated.

Usability & onboarding

  • Non-technical users can join by using someone else’s instance; if adoption grows, public instances are expected, similar to Mastodon.
  • Some see this as roughly comparable in difficulty to signing up for other federated services; others note that needing an invite/admin still makes it less accessible than centralized apps.

Relation to existing protocols (IRC, XMPP, Matrix, ActivityPub)

  • Many compare it to XMPP or Matrix: federated messaging, but over HTTP+JSON with IRC as a front-end.
  • Some argue this is “reinventing half of XMPP” or “basically Matrix,” while others say XMPP/Matrix are bloated or poorly managed, and a simpler or more nostalgic IRC-based design is desirable.
  • Others note similarities to ActivityPub, atproto, or suggest building on existing federated networks instead of creating another.

Spam, abuse, and moderation model

  • Spam and bot swarms are seen as a major risk.
  • Current answer: per-user and per-instance blocking; whole instances can be blocked.
  • There are no global channel operators; global channels are “owned by nobody.” Some argue this is unworkable at scale, forcing every admin to moderate the entire ecosystem or rely on contentious shared blocklists.
  • Ideas like reputation-based or shared spam lists are raised, but people warn of abuse, cartels, and social dynamics similar to Mastodon’s instance-block dramas.

Federation, netsplits, and technical concerns

  • Questions arise about how netsplits, nickname collisions, and re-joins are handled when servers may be untrusted or malicious.
  • Some argue CAP constraints make consistent global state impossible; others note this is a longstanding problem in IRC-style systems.

LLM-generated code & meta discussion

  • Several commenters suspect heavy LLM involvement (e.g., repo hints, marketing-y phrasing), and debate whether this leads to redundant projects that ignore prior art.
  • Others defend the project as a valid “build something” effort and push back against dismissing work just because it may be AI-assisted.