Pimp My IDE / garage dispatch
Back to garage
September 28, 2026 | protocols / chat / compatibility

Keep the old controls. Replace the machine.

Parley puts plain IRC in front of a new federated chat system. That is a useful pattern for developer tools, but compatibility has four separate contracts and each one can fail alone.

A familiar client reduces migration work. It does not prove identity discovery, signed delivery, offline recovery, or safe operation.

The client can stay while the system changes.

Parley accepts ordinary IRC clients, then connects independent instances through DNS discovery, well-known identity documents, signed HTTPS events, and automatic peering. A user can address another person as user@domain without installing a client plugin.[1]

The project is concrete. It has tagged releases, a published container image, protocol documentation, and a scripted two-instance demo. We pulled the official image at commit 52118a9 and confirmed that its binary reports version v0.5.0-18-g52118a9. The project's own README still calls it a working proof of concept that is not hardened.

Compatibility is a route, not a badge.

One protocol name hides several contracts.

The IRC front door handles client commands and capabilities. IRCv3's draft CHATHISTORY extension defines retrieval operations such as BEFORE, AFTER, and LATEST. It also depends on other capabilities, including batches, server timestamps, and message tags.[2]

Parley adds its own contracts behind that front door. DNS and well-known documents locate an instance and publish its key. Signed HTTP events move messages between instances. SQLite history, read markers, queues, and catch-up logic keep state across clients and outages.[1]

A green IRC login tests only the first contract. It says nothing about a remote identity, signature rejection, missed-message recovery, or read-marker convergence.

Old controls create a sharp test target.

A stable client protocol can reduce interface churn. It also gives an operator a clean differential test. Run the same client action against local and remote users, disconnect one peer, reconnect it, and compare the visible transcript with the signed event and stored record.

Parley's v0.5.0 notes document why this matters. A remote-user separator looked harmless, but strict clients interpreted the prefix as a server name. Messages still appeared while roster events disappeared. The release changed the separator and now advertises it through PARLEYSEP instead of asking clients to hard-code it.[3]

Review four routes before adoption.

  1. Client route: prove the commands and negotiated capabilities that your chosen client uses.
  2. Identity route: prove domain discovery, user lookup, key rotation, and failure behavior.
  3. Transport route: prove signature rejection, retry rules, duplicate handling, and peer-version mismatch.
  4. Continuity route: prove history order, offline catch-up, read markers, and state after restart.

Keep the proof-of-concept label until those routes pass in the environment that will carry real conversations.

Interactive makeover / four-route transfer case

Protocol transfer case

Traditional purpose replaced: one "compatible" badge. Better version: select the routes your test plan covers, see gaps in order, and copy a review card. The controls define a test plan. They do not run a chat service.

Select covered routes

Each square switch is independent. The rail fills only through the first uninterrupted sequence.

01ClientIRC and capabilities
02IdentityDNS, documents, keys
03TransportSigned HTTP events
04ContinuityHistory and recovery
Protocol review routes
1 of 4 routes selectedThe client route is selected. Identity, transport, and continuity still need test cases.
Copyable adoption card

Keep each proof separate

Replace every required field with results from your own environment.

What this component proves. It keeps client compatibility, identity, transport, and continuity in one ordered review. It does not start Parley, validate a signature, federate an instance, or recover a message.

Sources and limits

Open the source log
  1. Parley repository and README, read September 28, 2026. The project documents its IRC front end, DNS and well-known discovery, signed HTTP federation, SQLite history, quick start, test coverage, and proof-of-concept status.
  2. IRCv3 draft chathistory extension, read September 28, 2026. The draft defines history retrieval operations and its dependencies on related IRCv3 capabilities.
  3. Parley v0.5.0 release notes, read September 28, 2026. The release documents a breaking remote-user separator fix, read markers, reactions, offline queues, and the deploy gate.
  4. Hacker News discussion for Parley, item 49875913, read September 28, 2026. This was the discovery trail and a source of criticism about prior art and operational readiness. It does not verify the implementation claims above.

Artifact check. The official prologic/parley:latest image resolved to digest sha256:8fe9274d90a1bd77c1c4ec9b98da22b6f7356bb7000e8203c190694378813b1d. Its binary reported v0.5.0-18-g52118a9. We did not run a two-instance federation test, so this page makes no delivery or interoperability claim.