Feature plan: Step 1 · Step 2 · Step 3 · Step 4

Original Query

From the TODO file:

Make it easy to import/sync content from another instance.

- Make this schedulable too.

Please write Step 1 of docs/fdp/FEATURE_DEVELOPMENT_PROCESS.md.

Understood Intent

An instance operator should be able to bring another instance's content into their own. The user approved Option A first and saved Option B separately for later review. On approval, they deferred scheduling to a separate request and requested a command accepting an instance name/URL, with a possible web UI. This updated scope supersedes the scheduled first release originally proposed below.

Problem Statement

Existing archive import (source unavailable) and background queue capabilities do not yet provide a convenient, repeatable workflow from a remote instance through to visible local content.

Option A — Scheduled archive pull and additive import

Let an operator save a source instance, preview and run an import from its repository download, and enable recurring pulls through the existing background queue.

• Pros: Reuses existing downloads, duplicate detection, conflict reporting, and worker operations; can avoid read-model schema changes.

• Cons: Repeated full downloads grow costly; changed records require review; the current importer needs tighter content boundaries and failure recovery before unattended use.

Option B — Incremental content sync API

Provide a remote change feed that the destination can consume manually or on a schedule, with explicit rules for additions, edits, and deletions.

• Pros: Efficient recurring transfers; clearer support for evolving content and resumable progress.

• Cons: Requires a new cross-instance contract and compatible source deployments; authentication, retention, and conflict semantics expand the first release substantially.

Option C — Git-based repository replication

Have operators connect a remote content repository and schedule fetch-and-merge operations, then refresh the local site's content views.

• Pros: Uses the existing canonical repository and transfers changes efficiently while retaining history.

• Cons: Requires remote Git access and merge recovery; repository-wide replication can mix content with instance settings and trust decisions; harder to make approachable.

Recommendation

Option A is approved with scheduling deferred: deliver on-demand, one-way additive import from a compatible public instance by name/URL. Remote edits become reported conflicts and remote deletions do not delete local content. Incremental sync remains a separate future FDP cycle.

• Complete vertical slice: An operator supplies a source name/URL, optionally previews the import, downloads and imports in one command, sees the result locally, and inspects conflicts or recovers a failed run. Prevent overlapping imports.

• Content boundary: Step 2 defines the requested “all the data” coverage, including associated public content beyond threads/replies, while distinguishing content merging from full-instance restoration.

• Validate early: Confirm archive compatibility, record validation, and visibility under local trust rules. Prove repeat runs avoid duplicates and interrupted imports or failed publication recover without leaving permanently stale content.

• Scope viability: Target one day/eight development stages by reusing the importer. Scheduling and incremental sync are deferred; Step 2 assesses the optional web UI separately from the required CLI outcome.