Status: core feature set implemented; release validation in progress
The server is one standalone chat system with two protocol edges: traditional IRC/IRC-over-WebSocket for broad client compatibility, and a structured native gateway for richer clients, automation, and external-content integrations. Both edges use the same identities, channel authority, event log, retention rules, and cursor state.
| Concern | One authoritative model |
|---|---|
| Identity | Optional anonymous sessions; human accounts with one reusable password; bot and agent accounts with revocable app keys |
| Delivery state | One account-wide read marker and one delivery checkpoint per account/installation/conversation |
| Conversations | Durable channel or account-pair identity, independent of nicknames and connections |
| Channel authority | Versioned account-backed owner/operator/voice/member roles, bans, limits, shared keys, and retention policy |
| Event ordering | One SQLite writer allocates a stable event ID and monotonic conversation offset before fanout |
| Privacy | No public or durable client address identity; opaque DM denial; bounded metadata; explicit plaintext-server boundary |
| Content lifecycle | Per-channel retention, one server-wide DM lifetime, attribution-free cursor tombstones, and one content epoch/reset operation |
| Automation | Conspicuous service accounts, channel-scoped grants, bounded input, causal writes, budgets, loop controls, and moderator pause |
| External content | Channel-owned catalogues and short-lived capabilities while package bytes remain at separate providers reached by HTTPS or DCC |
No adapter owns a second version of these decisions. IRC modes and numerics, native JSON messages, the onboarding API, operator CLI, reference clients, and the MCP adapter all project the same core state. Downstream automation runners choose their own scheduling and model context without creating another Telex authority layer.
Authority is deliberately split so one useful privilege does not imply every other one:
- Infrastructure authority belongs to the stopped-service CLI and trusted in-process handles. It selects the database, provisions accounts, performs recovery and reset, and manages bootstrap state.
- Global account capabilities permit narrow live operations such as issuing invitations, provisioning automation, or reading aggregate diagnostics.
- Channel roles control human moderation and durable private membership.
- Automation grants control exactly what one bot or agent may receive and publish in one channel.
- Content-provider policy controls one provider catalogue and keeps human, named-automation, and bulk consumption separate.
- Native tickets attenuate one authenticated device session to selected operations and channels; they do not replace durable authority.
Every durable channel mutation uses the channel policy revision as a compare-and-set boundary. Stale administrative writers learn the winning revision instead of overwriting it.
The durable sequence is:
- authenticate and authorize against current account and channel state;
- commit the event and allocate its conversation offset;
- publish the committed event to IRC and native subscribers;
- advance an installation checkpoint only after the receiving client durably stores the event;
- advance the account read marker only after the user-visible read condition;
- resume after either cursor without inferring that delivery means reading.
Retention may remove event content, author presentation, and sender attribution, but preserves the minimal event ID/offset tombstone needed by surviving cursors. Content reset is the explicit stronger operation: it advances the server epoch, removes every server-owned conversation and invitation, preserves identities and global preferences, and creates one new default channel.
The native gateway is an API over the same chat core, not a second chat protocol with separate semantics. It exists where IRC cannot express enough structure:
- durable resume and acknowledgement;
- complete channel and automation policy snapshots;
- attenuated one-use session tickets;
- idempotent publication and causal replies;
- bounded invocations with server-selected context;
- structured content search, request, publication, and private capability delivery; and
- live provider transfer control for traditional DCC without server byte relay.
The gateway does not host models, prompts, tool credentials, package bytes, or arbitrary database queries. Adapters receive only the events and operations their account, channel grant, and ticket jointly authorize.
The implemented order remains useful when changing the system because later features rely on the earlier invariants:
- durable identity, conversations, event ordering, and cursor semantics;
- bounded IRC parsing, registration, TLS, WebSocket, and client compatibility;
- account credentials, private channels, moderation, invitation onboarding, and operator audit;
- DM privacy, retention, database maintenance, content epochs, and reset;
- native sessions, tickets, structured resume, and command idempotency;
- automated participants, disclosure, grants, context selection, provenance, quotas, loop detection, cooldown, and pause;
- external provider catalogues, audience policy, requester pseudonyms, one-use capabilities, quotas, XDCC-compatible presentation, and direct DCC transfer control.
Changes should continue to flow through these shared layers. For example, a new client command should reuse an existing domain operation; a new bot preset should expand to explicit grants; and a new content presentation must not gain a second capability issuer.
- remove the retired multi-server subsystem from code, configuration, dependencies, tests, lab topology, and current documentation;
- collapse the unused pre-release migration history into schema version 1;
- stamp the SQLite application lineage and reject unrelated or retired database files before mutation;
- retain one hardened single-server Docker acceptance bench; and
- run the complete Rust, client, documentation, and container validation set.
- finish the real-client matrix across Irssi, WeeChat, HexChat, terminal, web, and representative mobile clients;
- cover TLS, SASL, reconnect, history, read state, topics,
+i,+k,+l, bans, invites, kicks, and opaque DM rejection; and - fix server interoperability defects without weakening the account-centric model or advertising unsupported capabilities.
- review the target host, systemd identity, state and backup paths, proxy topology, listener exposure, and certificate ownership;
- rehearse install, invite bootstrap, online backup, candidate preparation, rollback, restart, host reboot, certificate renewal failure, and content reset;
- run a bounded burn-in with aggregate diagnostics and real clients; and
- promote a deployment only after the generic runbook matches observed behavior.
- address compatibility and usability findings from real users;
- improve the terminal and web clients over the stable native/IRC boundaries;
- add convenience presets only when they compile down to existing explicit authority; and
- make schema changes only for concrete retained-product needs.
The current server does not include multi-server operation, end-to-end encryption, hosted uploads, server-side previews, model execution, prompt or vector-memory storage, arbitrary webhooks, a global social graph, or hidden automated readers. Those require separate product and threat-model decisions; none should be smuggled into compatibility or deployment work.
Client-only experiments may build on ordinary encrypted payloads or novel presentation after v1, but they do not change the server's security claims or block the standalone release.