IRCv3 Roadmap¶
The companion to IRCv3 Support, which covers what Cascade negotiates today. This page tracks what's left to build, in rough order of value.
Legend: ✅ Done · ◐ Partial · ⛔ Not started
A capability can be present without appearing in requestedCaps. sts and
monitor/WHOX, for example, arrive through CAP LS values and ISUPPORT
tokens, so a missing name there isn't proof of a gap. When you finish an item,
move its details into the capability matrix in
ircv3-support.md and tick the box here.
Ratified set: complete¶
Every ratified IRCv3 capability Cascade targets is now shipped, so the baseline compliance work is done. The support matrix holds the per-capability detail and code pointers; this is just the list.
- ✅ Bot mode
+B - ✅
+typing(#78) - ✅
+reply/+channel-context - ✅
extended-monitor(#77) - ✅
account-extban(#77) - ✅
no-implicit-names(#77) - ✅
UTF8ONLY(#77)
Draft extensions (future modern-chat)¶
These fall outside ratified compliance, but they're deployed on real networks (Ergo, Soju) and fit Cascade's multi-platform direction. Listed in rough order of value.
-
draft/read-marker— Sync read position across devices. The highest-value draft for a multi-platform client; builds on thechathistory/@msgidmachinery already in place. -
draft/message-redaction— Message delete and edit (REDACT). Needs message-mutation handling in storage and the UI. The one draft currently tracked (⛔) in the support matrix. -
draft/multiline— Send and receive true multi-line messages instead of split lines. -
+draft/react— Emoji reactions (client-only tag). UX polish. -
draft/metadata-2— Avatars, status, display names. Larger effort. -
draft/channel-rename— HandleRENAMEof a channel. -
draft/pre-away— Away-on-idle support.
What's next¶
draft/read-marker is the highest-value item: cross-device read state reinforces
Cascade's multi-platform story and builds on the chathistory / @msgid
machinery already in place. After that, draft/message-redaction and
draft/multiline bring Cascade in line with what Ergo and Soju already do.
When you implement a cap¶
Follow the convention in
ircv3-support.md: add the name to
requestedCaps (client.go:31), gate behavior on enabledCaps (or the relevant
ISUPPORT token), add unit tests (and an e2e screenshot where it adds visual
signal), then move the entry from this roadmap into the support doc's capability
matrix.