ChronoSync: The Time-Travel Dev Diary

ChronoSync is a web app paired with a lightweight desktop daemon that continuously captures your entire development environment. Every file change, terminal command, active window, and screen state is recorded as a time-stamped event, stored locally and optionally synced to the cloud. The web UI displays a scrubbable timeline, enabling you to replay any moment of your coding history, search for specific text or patterns, and generate AI-powered session summaries. For a solo developer, this becomes an external memory—never again wonder how you solved that bug or when you introduced that regression. Sharing is secondary but powerful: you can select a time range and publish it as a "moment"—a self-contained replay that others can view without any installation.

The vision is ambitious but intentionally scoped for one person. The daemon is written in Rust for performance and cross-platform compatibility, using platform APIs for file system events (inotify/FSEvents) and window title polling. Screenshots are taken every 5 seconds using system commands (scrot on Linux, screencapture on macOS, or a Windows equivalent) and compressed to thumbnails. The web frontend is built with React and a custom timeline component based on vis-timeline, optimized for scrubbing through thousands of events. Data is stored in SQLite locally; when cloud sync is enabled (e.g., for sharing), selected metadata and thumbnails are pushed to a PostgreSQL-backed API on Node.js. AI summarization uses a local llama.cpp model for privacy, but users can opt into OpenAI for better quality.

The solo developer angle influences every decision: the architecture is monolithic, no microservices, no complex orchestration. The daemon and web app can run on the same machine. The cloud backend is optional and minimal. Features are prioritized by what gives the most personal value first.

Developers, especially solo ones, spend enormous effort context-switching and later struggle to recall why they made a decision or where a bug was introduced. Git logs capture code changes but not the surrounding environment—open tabs, terminal commands, experiment prompts, or just the train of thought. Screen recording is too heavy and privacy-invasive. There's no lightweight, searchable, time-travel tool for coding sessions. ChronoSync fills this gap: a dashcam for your development that lets you rewind and learn from the past.

• Automatically capture every file change, terminal command, active window, and screen thumbnail with <5% performance overhead.
• Provide a web-based timeline viewer with play/pause, scrubbing, variable speed, and search across all captured text (file paths, diffs, commands).
• Enable one-click sharing of any time range as a read-only "moment" viewable in any browser.
• Generate AI-powered session summaries, highlighting key events (refactoring, bug fixes, feature additions) automatically.
• Keep data local-first by default; cloud sync only for sharing, with clear privacy controls.

• Not a version control system: no branching, merging, or conflict resolution. It's a read-only log.
• Not a real-time collaboration tool: no live pair programming or shared cursors.
• Not a full screen recording: screenshots are infrequent and thumbnailed, not video.
• Not an IDE plugin: works with any editor, terminal, or browser.

Desktop Daemon: Rust (for low-level system calls, cross-platform). Uses notify for file system events, xcb/CoreGraphics for active window, and scrot/screencapture for screenshots. SQLite via rusqlite for local storage.

Backend: Node.js with Express, PostgreSQL (for cloud sync), hosted on a single $5 Linode.

Frontend: React, vis-timeline (customized), CSS modules. Hosted on Netlify.

AI: llama.cpp (local) for summarization; optional OpenAI API key.

Communication: REST API between daemon and web app (local HTTP server on daemon), HTTPS for cloud sync.

Packaging: Electron wrapper for the web app to run as a native desktop app (optional).

1. Daemon runs as a background process on the developer's machine. It:

   • Watches a configured directory tree for file changes (create, modify, delete) and records diffs.
   • Polls the active window title every second.
   • Captures a screenshot every 5 seconds (or on significant activity), compresses to a WebP thumbnail (~50KB).
   • Logs terminal commands by polling the shell history file or using script if enabled.
   • Stores events in a local SQLite database: events table (timestamp, type, data) and thumbnails table (blob).
   • Exposes a lightweight HTTP API (GET /events?after=..., GET /thumbnails/:id) for the web UI.

2. Web App runs in the browser (or Electron). It:

   • Connects to the daemon's local HTTP server for data (or to cloud API if synced).
   • Renders a timeline component that aggregates events into a heatmap and displays thumbnails on hover.
   • Allows searching: queries local database via daemon API (or remote API) for full-text search.
   • Playback mode: auto-scrolls through events at configurable speed, showing diffs and terminal output.
   • Sharing: select time range, click "Share", daemon uploads metadata+thumbnails to cloud, returns a short URL.

3. Cloud Backend (optional):

   • Stores shared moments: a table with userId, startTime, endTime, and JSON of events+thumbnail references.
   • Serves static replay pages for shared moments. No authentication for viewers; optional access codes.

For a solo developer, the entire system can run locally: daemon + web app on the same machine. Cloud is only needed to share moments.

• Storage bloat: Screenshots at 5s interval produce ~86k images per day (if 12hr session). With 50KB each, that's 4.3GB/day. Need aggressive compression and configurable retention (e.g., keep last 30 days, delete old).
• Privacy leaks: Sensitive info (passwords, tokens) could appear in screenshots. Need an opt-in redaction or a 'quick delete' feature to scrub events.
• Performance overhead: Constant file watching and polling might degrade dev experience. Must be heavily optimized (e.g., ignore node_modules, use debouncing).
• Solo dev burnout: Maintaining two codebases (daemon and web) plus packaging for three OSes is a lot. Should consider starting with macOS only.

• Should terminal capture be done via script output or by reading shell history? The former gives real-time output but creates large logs; the latter is only commands.
• How to detect project context switches automatically (e.g., by directory or active window title) to create session boundaries?
• Should the daemon also capture clipboard content for context? Privacy implications.
• Is a local web server enough, or should we build an Electron app for a tighter integration?

I got about two weeks into building the daemon prototype (Rust, file watching, SQLite) and realized the screenshot storage issue was a deal-breaker for my laptop's SSD. Then I pivoted to a simpler project and never came back. The idea has remained a what-if for a solo dev's perfect external memory.

This is not a product for everyone—it's a relentless self-quantification tool for a developer who wants total recall. The solo dev constraint makes it easier: no team consensus, no permissions, just build what you need. The first prototype could be just the daemon with a basic web viewer, ignoring AI and sharing. That alone would be useful.