Skip to content

roadmap.md

Latest commit

 

History

History
170 lines (137 loc) · 7.05 KB

roadmap.md

File metadata and controls

170 lines (137 loc) · 7.05 KB
Raw

Public roadmap

Status: pre-alpha, public source release 0.2.0

Telex is already usable by a small single-node community, but 0.x releases may still change configuration, storage, native APIs, and client behavior. Roadmap items are ordered by product risk, not by novelty.

Implemented baseline

Server and identity

  • One Rust daemon and one SQLite database.
  • IRC over TCP/TLS and standard IRCv3 WebSocket transports.
  • Optional anonymous sessions plus human, bot, and agent accounts.
  • One reusable password per human account and independent cursor-only installation credentials.
  • Separate opt-in, revocable remembered-device credentials for web login.
  • Independently revocable app keys for automated accounts.
  • Invite-gated account onboarding and narrow global capabilities.
  • Configured-operator account directory and audited capability changes.

Conversation state

  • Stable channel and account-pair conversations independent of nicknames and connections.
  • Commit-before-fanout durable events with message IDs and server time.
  • Account-wide read markers and per-installation delivery checkpoints.
  • IRCv3 history paging and bounded overlap for older clients.
  • Durable topics, reactions, replies, multiline messages, and notices.
  • Public, keyed, invite-only, and private channels with account-backed owner/operator/voice/member authority.
  • Recipient-owned direct-message policy with opaque rejection.
  • Per-channel retention, direct-message retention, pruning tombstones, and an explicit content epoch/reset operation.

Reference clients

  • Shared dependency-free IRC and native JavaScript state modules.
  • Terminal and structured native reference clients.
  • Responsive installable web client with local durable history, account management, automation management, operator controls, roster, direct messages, adaptive reactions, replies, avatars, nickname colors, IRC text formatting, mention completion, and connected-page attention tones.
  • Same-origin onboarding, account, automation, and operator surfaces.

Automation and content

  • Visibly non-human bot and agent accounts with purpose, processing, and data-handling disclosure.
  • Explicit per-channel input, history, reply, publish, roster, and content permissions.
  • Bounded invocation context, budgets, loop detection, cooldown, and moderator pause.
  • Attenuated native tickets, durable resume, acknowledgement, idempotent publication, and causal replies.
  • Optional channel-scoped automation command catalogs and capable-client leading-! autocomplete.
  • Reference stdio MCP adapter.
  • Invocation command, discoverable command, scheduled publisher, roster, durable worker, model-backed participant, and external artifact-provider examples.
  • Channel-owned external catalogues and short-lived HTTPS/DCC capability exchange without moving file bytes through the daemon.
  • One transient Stage per channel with externally encoded text-cell video, optional AAC audio, bounded relay recovery, a web viewer, archive tooling, playlist station, and containerized publisher build.

Near-term stabilization

Release and operations

  • Publish reproducible release artifacts and checksums for supported architectures.
  • Define a supported upgrade and rollback window for every tagged storage migration.
  • Add a public continuous-integration matrix for the minimum Rust and Node versions.
  • Complete a repeatable certificate-renewal and restore rehearsal in the generic operations guide.
  • Document a concise release and deprecation policy before 1.0.0.
  • Review transitive dependencies and public deployment defaults as a dedicated hardening pass.

Compatibility

  • Maintain a published real-client matrix across representative desktop, terminal, Android, and iOS clients.
  • Extend interoperability tests only for capabilities Telex actually advertises.
  • Revisit account-notify only with a reviewed post-registration account transition model.
  • Revisit multi-prefix if channel roles need simultaneous non-hierarchical presentation.

Web-client quality

  • Make notification availability and opt-in state consistently legible across browser and installed contexts.
  • Continue real-device validation of slow and intermittent avatar loading.
  • Replace fixed quick-reaction shortcuts with a compact recent/most-used row plus searchable emoji selection. This remains client presentation, not a server reaction allowlist.
  • Implement a bounded formatting subset—bold, italics, inline code, and IRC-compatible colors—with useful plain-text fallback.
  • Improve command and channel discovery without hiding ordinary IRC behavior behind a second authorization model.

Automation usability

  • Add service-manager examples that keep app keys out of arguments, unit files, and source trees.
  • Publish end-to-end operator and automation-owner walkthroughs using the web management surface.
  • Add an MCP-host example that discovers its currently authorized resources and tools without assuming model-provider behavior.
  • Keep schedulers, model runtimes, provider credentials, prompts, and application-specific state outside the daemon.

Separately scoped work

Custom emoji and stickers

Small server-scoped named assets such as :{name}: are a candidate feature, not an incidental extension of reactions. A design must define:

  • storage and total/per-account limits;
  • accepted PNG, WebP, and GIF processing;
  • animation, accessibility, and bandwidth policy;
  • traditional-client fallback text;
  • authorization and moderation;
  • backup/reset behavior; and
  • denial-of-service bounds.

Arbitrary image attachments and automatic remote previews remain outside this work.

External content

The existing provider model deliberately keeps bytes outside Telex. Future work may improve catalogue presentation and provider operations while preserving direct HTTPS/DCC transfer, named provider disclosure, short-lived capabilities, and requester privacy boundaries.

Deliberate non-goals

  • Multi-server federation.
  • End-to-end encryption claims without a separately designed client protocol.
  • Hosted model execution, prompt storage, or provider API keys.
  • Arbitrary database access for bots or MCP clients.
  • A global social graph.
  • Hidden automated readers.
  • Core-protocol games.
  • Generic hosted uploads or media proxying.

Client experiments and channel-scoped automation can explore many of these ideas without silently widening the server's authority or storage model.

Toward 1.0

A 1.0.0 release should mean:

  • documented compatibility commitments for configuration and native APIs;
  • migration and rollback procedures exercised across supported releases;
  • a maintained real-client matrix;
  • release artifacts with provenance and checksums;
  • no unresolved high-severity security findings;
  • stable operator recovery procedures; and
  • public documentation that matches a clean installation rather than one particular deployment.