同步 (Sync)

Eidos 遵循 数据本地优先 (Local-First) 的原则。你的数据默认存储在本地设备上，同步被视为一层可选能力，用于跨设备衔接、远程备份与恢复。

同步方案的演进

Eidos 的同步方案是渐进式的，你可以根据使用阶段选择合适的方式：

1. 手动拷贝

最直接的方式是直接复制 .eidos 目录并粘贴到其他设备的相同位置。由于 Eidos 所有的内容（数据库和文件）都完整存储在该目录下，手动拷贝可以实现最原始的“同步”。

2. 第三方同步工具 (如 Git)

将 Space 物理目录放在 Git 仓库或同步盘（如 iCloud, Dropbox）中是可接受的过渡方案，但它并非最优解：

版本管理缺失：SQLite 是二进制文件而非文本文件，Git 等工具无法实现细粒度的版本对比或合并。
仓库体积爆炸：随着使用，SQLite 文件的任何变动都会导致 Git 产生一份全量的历史记录，导致 Git 仓库体积迅速膨胀。
同步效率低：每次同步都是全量传输大文件，随着数据库增大，同步速度会越来越慢。

3. Eidos 原生同步 (Graft)

为了克服上述局限，Eidos 采用了基于 Graft 的原生同步方案。它将单文件的 db.sqlite3 转化为对象化的存储格式，实现了更高效的增量同步和远程备份。

当前同步最擅长什么

现阶段，Eidos Sync 更适合被理解为一项 面向单人、多设备的同步与备份能力。

它尤其适合以下场景：

在笔记本、台式机和其他个人设备之间安全切换同一个 Space
将 .eidos 数据保存在 S3 兼容存储中，作为远程备份
在新设备上通过克隆远程空间来恢复 Space
保留历史版本，降低同步异常直接演变成静默数据丢失的风险

它暂时不适合被理解为支持多人同时在线编辑同一内容的实时协作系统。

原生同步架构概览

Eidos 通过中心化的 S3 兼容存储桶作为中转，实现跨设备的数据同步。同步的核心是 Space 物理目录下的 .eidos 文件夹，它完整包含了数据库的版本历史（.graft）以及所有的静态资源文件（files）。

这种设计确保了你在任何设备上看到的目录结构都是一致的，远程存储桶即是本地物理目录的完整云端镜像。

                ┌────────────────────────┐
                │    Remote S3 Bucket    │
                │  s3://bucket/my-space/ │
                │ └── .eidos/            │
                │     ├── .graft/        │
                │     └── files/         │
                └──────────┬─────────────┘
                           │
           ┌───────────────┴────────────────┐
           │              Sync              │
┌──────────┴─────────────┐      ┌───────────┴────────────┐
│         macOS          │      │        Windows         │
│ /Users/mayne/my-space/ │      │ D:\Eidos\my-space\     │
│ └── .eidos/            │      │ └── .eidos\            │
│     ├── .graft/        │      │     ├── .graft\        │
│     └── files/         │      │     └── files\         │
└────────────────────────┘      └────────────────────────┘

物理存储结构变化

开启原生同步后，Eidos 会将单文件的 db.sqlite3 转化为对象化存储格式（存放在 .graft 目录），其目的是实现：

流式传输：仅同步发生变化的增量数据块，无需每次都上传整个数据库大文件。
版本管理：在本地保留历史快照，方便多设备间的合并、回滚及冲突检测。

未启用同步

文件夹my-space/
- 文件夹.eidos/
  - db.sqlite3 (数据库文件)
  - 文件夹files/ (静态资源)
    …

已启用同步

文件夹my-space/
- 文件夹.eidos/
  - 文件夹.graft/ (VFS 存储目录)
    …
  - 文件夹files/ (静态资源)
    …

冲突处理

Eidos 的同步机制基于 Graft，其工作流与 Git 非常相似。同步方案主要为单人、多设备切换场景设计，不具备 CRDT 等实时协同系统的自动冲突解决能力。

为减少冲突，推荐在切换设备使用时遵循 Pull → Edit → Push 模式：

      Device A                 Cloud                  Device B
       (Work)                  (S3)                   (Idle)
        │                       │                       │
     [ Edit ]                   │                       │
        │         Push          │                       │
        └──────────────────────▶│                       │
                                │         Pull          │
        │                       │──────────────────────▶│
        │                       │                    [ Edit ]
        │                       │         Push          │
        │                       │◀──────────────────────┘

Pull → Edit：开始工作前，先确保拉取了其他设备的最新改动。
Edit → Push：结束工作后，及时将改动推送至云端。
优先避免冲突：同一时刻最好只在一台设备上主动编辑同一个 Space。
远程备份仍然有价值：即使同步不是完全自动合并，远程副本依旧是重要的异地备份与恢复来源。
手动冲突解决：如果多个设备同时修改了相同数据，Graft 会识别并提示你进行手动仲裁。

备份与恢复

同步同时也是 Eidos 备份能力的基础：

异地备份：你的 Space 数据可以保存在远程 S3 兼容存储中，而不是只存在于一台机器上。
空间恢复：如果你更换设备或丢失本地数据，可以从远程 provider 再次克隆恢复空间。
带历史的存储：Graft 会在本地和远端保存带版本历史的数据，相比手动复制单个 SQLite 文件，恢复路径更完整。

如果你的主要目标是灾难恢复，而不是频繁跨设备切换，那么 Eidos Sync 仍然有价值，因为它为整个 .eidos 目录提供了结构化的远程备份。

同步供应商 (Provider)

Eidos 支持多种同步供应商：

eidos.space (官方托管)：零配置，登录账号即可使用。数据存储在官方提供的加密 S3 存储桶中，用于同步、备份与恢复。
自定义 S3 兼容服务：使用你自己的 S3 存储（AWS S3, Cloudflare R2, MinIO 等），完全掌控数据。

下一步

了解如何基于同步数据构建发布服务