Skip to main content

Long Echo Comes Alive: From Philosophy to Orchestration

4 min read Updated:
long-term-thinking data-preservation cli python sqlite personal-archival

A year ago, I wrote about Long Echo as a philosophy for preserving AI conversations across decades. The key insight was graceful degradation: design archives that work progressively even as technology disappears.

That philosophy has now become a tool.

From Philosophy to Tool

The original Long Echo was intentionally not code. It was a set of principles documented in CTK’s repository. The hard problems of conversation parsing, storage, and search were already solved by toolkits like CTK, BTK, and EBK.

What was missing was the unification layer. Each toolkit exports its own ECHO-compliant archive, but combining them into a single browsable experience required manual work. That’s what longecho now provides.

What longecho Does Now

longecho is a CLI tool with five capabilities:

longecho check ~/my-data/       # Validate ECHO compliance
longecho discover ~/            # Find ECHO sources
longecho search ~/ "query"      # Search README descriptions
longecho build ~/my-archive/    # Generate static site
longecho serve ~/my-archive/    # Preview locally via HTTP

The check, discover, and search commands existed in the original specification. What’s new is build and serve—the orchestration layer.

Building a Unified Site

The build command takes a hierarchical archive and generates a static site:

longecho build ~/my-archive/

This produces a site/ directory with:

  • An index page linking to all sub-archives
  • Navigation between sources
  • Automatic linking to existing sub-site builds

If a sub-archive already has its own site/ directory (like CTK’s exports), longecho links to it. Use --bundle to copy everything into a portable, self-contained site.

Live Preview

The serve command provides local HTTP preview:

longecho serve ~/my-archive/ --port 8000

It builds the site if needed, then serves it for browser viewing.

The Manifest

ECHO compliance requires only a README. But for machine-readable metadata, longecho supports an optional manifest:

version: "1.0"
name: "Alex's Data Archive"
description: "Personal data archive"
sources:
  - path: "conversations/"
    order: 1
  - path: "bookmarks/"
    order: 2
  - path: "ebooks/"
    order: 3

The manifest enables:

  • Explicit ordering of sources in generated sites
  • Selective inclusion via the browsable flag
  • Override names for cleaner presentation
  • Icon hints for UI presentation

Without a manifest, longecho auto-discovers sub-archives by looking for directories with README files. The manifest provides explicit control when needed.

Hierarchical Archives in Practice

My actual archive structure looks like this:

longecho-archive/
├── README.md
├── manifest.yaml
├── conversations/           # CTK export
│   ├── README.md
│   ├── conversations.db
│   └── site/
├── bookmarks/               # BTK export
│   ├── README.md
│   ├── bookmarks.db
│   └── site/
└── ebooks/                  # EBK export
    ├── README.md
    ├── ebooks.db
    └── site/

Each subdirectory is independently ECHO-compliant:

  • conversations/ contains my AI conversation history from ChatGPT, Claude, and others
  • bookmarks/ contains years of saved links with hierarchical tags
  • ebooks/ contains my ebook library with extracted highlights

Running longecho build creates a unified site/ at the root that links everything together. Each toolkit’s export is preserved exactly—longecho doesn’t modify the underlying data.

ECHO Compliance in Practice

The minimal requirement for ECHO compliance is:

  1. A README.md or README.txt at the root
  2. Data in durable formats

That’s it. No manifest, no special structure, no version numbers.

The toolkits naturally satisfy this:

  • CTK exports with README explaining the SQLite schema
  • BTK exports with README describing bookmark format
  • EBK exports with README documenting ebook metadata

longecho doesn’t impose additional requirements. It works with what the toolkits already produce.

Why This Matters

The philosophy hasn’t changed. Archives should work without tools:

If you have…You can still…
longechoBrowse a beautiful unified site
A web browserOpen any toolkit’s site/index.html
SQLiteQuery the databases directly
A text editorRead the README files

What’s new is convenience. Instead of manually copying files and editing HTML, longecho build generates the unified view automatically. But the underlying archive remains simple: directories with README files and durable-format data.

Implementation Notes

longecho is written in Python with Typer for the CLI and Jinja2 for HTML templates. The codebase is small (under 1000 lines) and well-tested (78% coverage, 114 tests).

Key design decisions:

  • Link by default, bundle optionally: Generated sites link to sub-archive sites rather than copying them. This keeps the output small and avoids duplication. The --bundle flag creates a fully portable copy when needed.

  • Auto-discovery with override: Without a manifest, longecho finds ECHO sources automatically. With a manifest, you get explicit control.

  • No data transformation: longecho never modifies the underlying data. It generates HTML that links to what already exists.

Status and What’s Next

longecho is alpha quality with core functionality working. The test suite covers the major paths, and I’m using it for my own archives.

What might come next:

  • Search integration: Cross-archive search combining all toolkit indexes
  • Theme support: Custom templates for generated sites
  • Watch mode: Rebuild automatically when sources change

But the core is stable: check, discover, build, serve. The philosophy is now a tool.

The archive is not a monument. It is a conversation that outlasts its participants.

Resources

Related Posts

Discussion