|
All checks were successful
CI / check (push) Successful in 3m41s
New 'echo import <anope.json> <out.log> [node]' subcommand builds a fresh event log from an Anope db_json: accounts (identity only — Anope's one-way password hashes can't become SCRAM verifiers, so migrated users auth by certfp/external authority), grouped nicks, cert fingerprints, vhosts, channels (+desc/topic/ assigned bot), access mapped to op/voice by each channel's AUTOOP/AUTOVOICE thresholds, param-less mode locks, BotServ bots (service pseudo-clients skipped), and memos. Read-only on the source; self-verifies by replaying the produced log. Verified against the live backup (11 accounts, 10 channels, 10 bots) + a unit test over a synthetic fixture. The prerequisite for a safe cutover. |
||
|---|---|---|
| .forgejo/workflows | ||
| api | ||
| modules | ||
| proto | ||
| scripts | ||
| src | ||
| testing | ||
| .gitignore | ||
| build.rs | ||
| Cargo.lock | ||
| Cargo.toml | ||
| config.example.toml | ||
| LICENSE | ||
| README.md | ||
Echo
A federated IRC services daemon, written in Rust.
Echo runs the services side of an IRC network, the accounts, channels, and operator tooling, as a set of pseudo-clients (NickServ, ChanServ, and the rest) linked to an ircd over its server-to-server protocol. State is an append-only event log folded into memory, and that log gossips between nodes, so several Echo instances on different servers share one account and channel database with no central store.
Clean-room work, informed by the ideas behind modern event-log and gossip services, not derived from any project's source.
Highlights
- Federated. Every change is an event; nodes exchange logs and converge. Account identity is global across the network, while channel state stays with the node that owns it.
- Event-sourced. State is a fold over an append-only log. Restart replays it, compaction folds it, replication ships it, all through one code path.
- Modular. The core is one crate. Each service and each ircd protocol is a separate crate depending only on the
echo-apiSDK, so a new service or a new ircd is one new crate. - Memory-safe. No manual memory management and no data races, in a domain that has historically shipped both.
Quick start
git clone https://git.devtronic.pro/fedserv/echo.git
cd echo
cp config.example.toml config.toml # set the uplink host and link password
cargo run --release -- config.toml
Echo links to an InspIRCd uplink out of the box. Point config.toml at your ircd's server port and add a matching <link> block on the ircd side. The full reference is on the Configuration page.
Services
Every service is a first-class pseudo-client, all started by default.
| Service | Role |
|---|---|
| NickServ | account registration, identification, grouped nicks, SASL |
| ChanServ | channel registration, access lists, mode-lock, auto-op |
| BotServ | per-channel bots, fantasy commands, kickers |
| HostServ | virtual hosts, self-serve and operator-approved |
| MemoServ | messages to accounts, delivered online or not |
| OperServ | akills, DEFCON, jupes, session limits, log search |
| StatServ | network and channel statistics |
| GroupServ | account groups whose members inherit channel access |
| ChanFix | reop an opless channel from accumulated op-time |
| HelpServ | a help-desk ticket queue for operators |
| InfoServ | network bulletins shown on connect and login |
| ReportServ | user abuse reports feeding the operator audit trail |
| DiceServ | dice and math for tabletop games |
Architecture
Three layers, each a clean boundary:
- Protocol turns raw server-to-server lines into a normalized event and action vocabulary. The engine never sees a raw line, so supporting another ircd is one new crate.
- Engine holds the live network view and the event-sourced store, and routes messages to services. Services reach it only through the
StoreandNetViewtraits, keeping the log, gossip, and credential material out of a module's reach. - Services are pseudo-clients, one crate each, implementing a single
Servicetrait.
The full write-up is in the wiki: Architecture and Federation.
Documentation
The wiki has the detail:
- Architecture — the engine, the store, the module boundary
- Federation — gossip, the global/local scope model, conflict resolution
- Services — every service and its commands
- Configuration — the
config.tomlreference - Directory API — the gRPC account and channel directory for websites
- Writing a Module — build your own service or ircd link
- Deployment — running Echo in production: install, durability, backups
Status
Echo links to a live InspIRCd uplink and runs the full service suite over an event-sourced, gossip-replicated store. It supports SASL (PLAIN, SCRAM-SHA-256/512, EXTERNAL), an optional mutually-authenticated TLS peer link, an email subsystem for registration confirmation and password recovery, and a gRPC directory API for websites to mirror accounts and channels. It is verified against a real ircd with the irctest compliance suite.
License
Not yet declared. This is original, clean-room work; a license will be set before any public release.