urit/docs/ROADMAP-v0.3.0.md

# URIT BBS — v0.3.0 Roadmap

Status: **Planning**
Previous: v0.2.0 (steps 10a–17) — telnet, auth, message boards, mail, file libraries,
bulletins, HTTP file server, inter-node chat, sysop console, sysop guide.

---

## Step 18 — SSH Support

**Priority: 1 — High value, low effort**

The config section (`[ssh]`) is already defined and parsed. The session layer
(`internal/session`) is transport-agnostic — it works on any `net.Conn`. Wiring
up SSH is primarily a listener and key-management task.

### Sub-steps

- **18a — SSH listener and host key management.**
  Add an SSH listener to the server using `golang.org/x/crypto/ssh`. Generate a
  host key on first run (or via `urit init`) and store it at the configured path.
  Accept connections, negotiate a PTY channel, and hand the resulting `net.Conn`
  equivalent to the existing `handleConnection` flow.

- **18b — Password authentication callback.**
  Wire the SSH password callback to the same `auth.Check` path used by telnet
  login. On successful auth, skip the telnet login prompts and drop the user
  directly into the post-login flow (logon.ans → main menu). Guest access via
  SSH should be configurable (allow/deny in config).

- **18c — Terminal handling.**
  Read PTY dimensions from the SSH channel request (replaces telnet NAWS). Map
  SSH window-change requests to the session's terminal size updates. Verify ANSI
  escape passthrough works correctly over the SSH channel.

### Notes

- The SSH user's identity is known at connection time (unlike telnet, where login
  happens after connecting), so the session lifecycle needs a minor branch: skip
  the welcome.ans → login prompt sequence and jump to the authenticated path.
- Public key auth is a natural follow-on but not required for the initial
  implementation. Password auth matches the existing BBS credential model.
- Vendor `golang.org/x/crypto/ssh` into the vendor directory.


## Step 19 — Door Games

**Priority: 2 — Highest user-facing impact**

Door games are external programs launched from within the BBS, with the user's
terminal piped through. This was the killer feature of multi-node BBSes in the
late '80s and '90s. Supporting even a basic door interface opens up a large
ecosystem of existing door game binaries.

### Sub-steps

- **19a — Door configuration and menu integration.**
  Add a `[doors]` config section defining available doors: name, command path,
  arguments, working directory, and required SecStatus. Add a `[D]oors` command
  to the main menu (relocate the existing `[D] Download` to another key or make
  it a sub-option). List available doors and let the user select one.

- **19b — Dropout file generation.**
  Generate a DOOR32.SYS dropout file before launching the door. DOOR32.SYS is
  the most widely supported modern format and includes: comm type (2=telnet),
  socket handle, baud rate (0 for telnet), BBS name, user info, time remaining,
  and node number. Write the file to a per-node temp directory.

- **19c — Process execution and I/O bridging.**
  Launch the door process with `os/exec`, connecting its stdin/stdout to the
  user's telnet (or SSH) connection. Set environment variables that doors
  commonly expect: `DOORNODE`, `DROPFILE`, etc. The door process inherits the
  terminal. On exit, return the user to the main menu. Handle process timeouts
  tied to the user's remaining session time.

- **19d — Cleanup and logging.**
  Remove temp dropout files after the door exits. Log door usage (door name,
  user, duration). Handle abnormal door exits gracefully (process crash, timeout,
  signal). Ensure the terminal state is sane after the door returns (re-send
  ANSI reset, re-negotiate telnet options if needed).

### Notes

- Many classic doors expect a DOS-like environment. Running them may require
  DOSBox or similar on Linux. URIT's role is just the I/O bridge and dropout
  file — the door binary's compatibility is the sysop's responsibility.
- Native Linux doors (written for systems like Mystic, Synchronet) will work
  more naturally. Some modern door games are written specifically for telnet BBSes.
- Consider a `door_log` table for tracking door usage statistics.


## Step 20 — Message Threading

**Priority: 3 — Model is ready, UI work needed**

The `ReplyTo` field exists on the Message model but is not surfaced in the UI.
Wiring it up gives boards a threaded conversation feel rather than a flat
chronological list.

### Sub-steps

- **20a — Reply command in message reader.**
  When reading a message, add an `[R]eply` option that pre-fills the subject
  with "Re: {original subject}" and sets ReplyTo to the parent message ID.
  The compose flow is otherwise identical to posting a new message.

- **20b — Thread-aware message listing.**
  Modify the board message list to indicate threading. Two approaches to
  consider: indented tree view (classic Usenet style) or flat list with
  "Re: ..." subjects and a "view thread" command that filters to a single
  conversation. The flat approach is simpler and more BBS-authentic.

- **20c — Store support for thread queries.**
  Add `ListMessageThread(boardID, rootMessageID)` to the store interface. This
  returns all messages in a thread (the root plus all descendants) in
  chronological order. Use a recursive CTE in SQLite for efficient traversal.

### Notes

- Keep the default board view as a flat chronological list — threading is
  additive, not a replacement. Users who don't care about threads should see
  no change in behavior.
- The HTTP side doesn't currently display messages, but if it ever does,
  threading support in the store will carry over naturally.


## Step 21 — Email Notifications

**Priority: 4 — Bridges BBS and modern communication**

Lightweight email notifications that pull users back to the BBS when something
happens that's relevant to them.

### Sub-steps

- **21a — SMTP configuration.**
  Add an `[email]` config section: enabled flag, SMTP host/port, from address,
  auth credentials (optional), TLS mode (none/starttls/tls). Add an `Email`
  field to the User model for the notification address (set during registration
  or via account settings).

- **21b — Notification triggers.**
  Send emails on: new private mail received, reply to a message the user posted
  (requires step 20), and sysop broadcast (optional). Each trigger should be
  individually toggleable per user via account preferences.

- **21c — Mail queue and sender.**
  Implement a background goroutine that processes a notification queue. Outbound
  emails are queued (in-memory channel or a database table for persistence) and
  sent asynchronously so they never block the BBS session. Rate limit to avoid
  overwhelming the SMTP relay. Include an unsubscribe link or instructions in
  every email.

- **21d — User preferences.**
  Add a notification preferences submenu to the `[A]ccount` command. Let users
  set their email address, enable/disable each notification type, and set a
  digest preference (immediate vs. daily summary). Store preferences in a new
  `user_preferences` table or as additional fields on the user record.

### Notes

- Keep emails plain text with minimal formatting — matches the BBS aesthetic
  and avoids HTML email complexity.
- Consider a daily digest mode that batches notifications into a single email
  to avoid spamming active boards.
- The email address doubles as an account recovery mechanism in the future.


## Step 22 — Automated Backup

**Priority: 5 — Operational reliability**

A `urit backup` subcommand that snapshots all BBS state into a single archive.
Designed to be run from cron on unattended systems.

### Sub-steps

- **22a — Database snapshot.**
  Use SQLite's online backup API (`sqlite3_backup_init`) via the CGo binding to
  create a consistent snapshot of the database while the server is running. This
  is safe for concurrent reads/writes — no need to stop the server. Write the
  snapshot to a temp file, then move it into the backup directory.

- **22b — File collection.**
  Copy the screens directory and all library file directories (paths read from
  the library records in the database) into the backup staging area. Skip files
  that haven't changed since the last backup if a `--incremental` flag is set
  (compare mtimes).

- **22c — Archive and rotation.**
  Tar/gzip the staged files into a timestamped archive:
  `urit-backup-YYYYMMDD-HHMMSS.tar.gz`. Support a `--keep N` flag that
  automatically deletes backups older than the N most recent. Default output
  directory configurable via `--output` flag or a `[backup]` config section.

- **22d — Cron integration.**
  Document cron usage in the sysop guide. Example:
  `0 3 * * * /opt/urit/urit backup -config /opt/urit/config.toml --keep 7`
  The command should exit cleanly with appropriate exit codes (0=success,
  1=partial failure, 2=fatal error) and log to stdout for cron mail capture.

### Notes

- The backup command connects to the database read-only — it does not need the
  server to be running, but it works safely if it is.
- Consider adding a `--verify` flag that restores the backup to a temp directory
  and runs a schema integrity check.
- A `urit restore` subcommand is a natural follow-on but lower priority.


## Steps 23+ — Future Considerations

The following features are candidates for future versions. Order and scope are
flexible.

### Full-text search (Step 23)

Add keyword search across message boards and mail using SQLite's FTS5 extension.
A `[/]` command at the board level searches subject and body text. Results
displayed as a filtered message list. FTS5 is already compiled into the CGo
binding — the work is creating the virtual table, keeping it in sync with
inserts, and building the search UI.

### File descriptions on telnet (Step 24)

The telnet library browser shows filenames but lacks the rich file listing that
classic BBSes were known for. Add a proper file list display with descriptions,
sizes, dates, download counts, and uploader names — the traditional columnar
BBS file list format. The data is all in the store already; this is purely a
display task.

### ANSI auto-detection (Step 25)

Detect terminal capabilities during telnet negotiation or ask during login.
Provide plain-text fallback screens for minimal clients. Add a user preference
to override detection. Low priority since virtually all modern telnet clients
support ANSI, but it's a polish item for accessibility.

### Rate limiting and connection throttling (Step 26)

Add per-IP connection limiting (max N concurrent connections per IP) and a brief
delay after failed login attempts. The max node count provides a global cap, but
per-IP limits would prevent a single source from consuming all nodes. Important
for public-facing systems.

### Web admin console expansion (Step 27)

Extend the existing `/admin` dashboard with full CRUD for users, boards,
libraries, and bulletins — a complete browser-based replacement for the telnet
sysop menu. The middleware, template system, and store methods all exist; this
is primarily HTML form work. See the step 16 discussion for scope analysis.

---

## Version Summary

| Step | Feature                | Priority | Effort   |
|------|------------------------|----------|----------|
| 18   | SSH support            | 1        | Medium   |
| 19   | Door games             | 2        | Medium   |
| 20   | Message threading      | 3        | Low      |
| 21   | Email notifications    | 4        | Medium   |
| 22   | Automated backup       | 5        | Low–Med  |
| 23   | Full-text search       | —        | Low      |
| 24   | Telnet file listings   | —        | Low      |
| 25   | ANSI auto-detection    | —        | Low      |
| 26   | Rate limiting          | —        | Low      |
| 27   | Web admin expansion    | —        | High     |