Roadmap

ferrixd reached 1.0.0 — the first stable release — 1.1.0 extended it (IRC over WebSockets, WEBIRC, bot-mode, live link management, TLS reload), and 1.2.0 grows the plugin system into a full extension surface (Plugin ABI v2; see the changelog). This page records what the current release contains, what the stability promise covers, and what may come next.

Stability promise (1.x)

Covered by semantic versioning; these will not change incompatibly within 1.x:

Surface	Promise
Configuration schema	new keys may appear with defaults; existing keys keep their meaning
Client protocol	commands, numerics, and the advertised capability set
CLI	subcommands and flags
Plugin ABI	hook signatures and the memory contract (reference)
S2S wire protocol	frames extend only backwards-compatibly; older forms stay parseable, so mixed-version 1.x networks interoperate

Two deliberate exceptions:

• Draft IRCv3 capabilities (draft/*) track their upstream specifications and change when those do. When a draft is ratified, ferrixd adopts the ratified name (and cap-notify clients learn about it live).
• The Rust library APIs (ferrixd, ferrix-protocol) are not covered. The daemon is the product; the crates are its implementation.

What ferrixd contains

• Protocol surface: the RFC core plus 29 IRCv3 capabilities (list) — what the server advertises, it enforces — plus non-capability features (bot-mode, WEBIRC, UTF8ONLY, network-icon) and IRC over WebSockets (ws:///wss://).
• Federation: complete state synchronization across multi-hop link trees with loop prevention and TS-based netjoin resolution (protocol), plus a TS6 bridge to charybdis-family IRCds.
• Persistence: message history (with msgid continuity), channel registrations, and self-registered accounts survive restarts; the write-behind queue is drained on graceful shutdown.
• Security: zero unsafe, a fuzzed parser, TLS-first transport, Argon2id credentials, and the DoS controls in Limits.
• Density: ~100k concurrent connections per node demonstrated.
• Releases: prebuilt binaries for 7 targets with a checksum-verifying installer (installation).

Since 1.0

Work that has landed on top of 1.0 — most of it former Horizon items — while holding the 1.x stability promise:

• SASL reauthentication. A registered client that negotiated sasl may re-run AUTHENTICATE mid-session to switch (or add) an account. The new login replaces the old on success; a failed attempt leaves the existing login untouched.
• Richer plugin hooks. The WASM host now also observes and can veto nick changes (ferrix_on_nick) and topic changes (ferrix_on_topic), on the same fail-open ABI as messages and joins (reference).
• Plugin ABI v2. The moderation events (part, kick, mode, invite), DM filtering (operator-gated), lifecycle hooks (connect/quit/load), message rewriting (ferrix.set_text), custom block reasons, a bounded persistent key-value store, read-only world queries, a per-instance memory cap, and the first capability-gated action (ferrix.send_notice, deny-by-default via [plugins.grants]) — the sandbox properties are unchanged: fail-open, fuel-bounded, no ambient authority.
• Live link management. Operators can bring S2S links up and down at runtime with CONNECT <name> and SQUIT <server> [:reason], beyond the config-driven links started at boot.
• Per-command metric histograms. /metrics now exposes ferrixd_command_duration_seconds, a per-command handler-latency histogram (bounded label cardinality: known verbs plus other).
• TLS reload without restart. REHASH now reloads the certificate and key for every TLS listener (client, wss://, and S2S) without dropping the process or any live connection; a bad reload leaves the previous material armed. Outbound links also pick up the reloaded certificate on their next (re)connect — the auto-dial reconnect loop included — so certificate rotation no longer needs a manual re-link.

Horizon

Direction, not commitment:

• Draft-spec tracking. The draft/* capabilities follow their specs; ratified names are adopted as they land.
• Even richer plugin capabilities. The moderation events and the first active capability (send_notice) are covered; further capability-gated actions (kick, mode, kline as actions) are the natural next extension of the same grants model.

If you want to influence any of this, open an issue — GitHub.