本地加密再上传不就好了，多客户端就让用户自己通过其他安全信道传输密钥
（或者麻烦点，密钥不出设备，每个设备独立加密，发送给其他设备就用对方的公钥加密，并用自己的私钥签名，服务端提供信息交换和备份，然后多一个设备就多一个加密副本，收费点 get

@codehz
数据库已经加密。要解决的是每次有修改，都需要将加密后的文件上传，然后另外一个终端必须下载完整个库才能使用，这个过程就会有点儿长。这个问题。

极端情况下这个 DB 文件都快 100M 了，就太麻烦了。

@Chad0000 可以区块链啊（划掉）
每次只编码更改不就可以了，然后定期做一个 GC 压缩

比如 SQLite 直接提供了生成 changeset 的功能，一键合并修改
（但是更高级的冲突合并就得自己实现了）
考虑到只有一个人使用，似乎也用不太到

@codehz
区块链倒是用不上，只上传修改的部分是一个不错的方案。由各终端自行合并。同时后期修改后，点同步时分析修改过的部分，将这部分打包上传即可。

你说的那个 changeset 我去看看，不过很有可能还是需要软件自己处理合并。

感谢提供点子，挺有帮助的！

OP 在那个贴子里提到的存储在用户本地的信息集合，有些类似 Tim Berners Lee 搞的 Solid ( https://en.wikipedia.org/wiki/Solid_(web_decentralization_project) )？不过它更强调的是不同节点之间的互联。

---

有关同步的问题，我有过类似的想法：定义一种协议，它可以描述确定两个节点 A 和 B 之间的数据可以如何同步，并且

- A 和 B 不一定要相等，可以是 A 的子集和 B 的某个子集进行同步
- 比如 A 是一个人手机上的各种类型数据的集合，B 是一个服务器，那 A 只需要把照片这个子集和 B 里面属于 A 的部分同步
- 这个模式已经很常见了，但还没有发现有通用协议去规定它
- 同步当然要是增量的，但基于文件的同步不太靠谱，因为我们没法假定同步工具支持增量同步，也没法假定数据库到底是以何种方式存储的
- Event Sourcing 是个思路：每次修改会产生一条记录，当前数据是所有记录执行后的一个快照。这个设计类似 Flux 或者 Git ，所以很自然地，如果同步双方的记录日志分叉了，还可以尝试 merge
- 继续从 Git 思路出发，客户端和服务端是多对多关系，甚至没有服务端的概念，因为服务端本身也可以作为中继，同步到上游数据库
- 如何避免环出现呢？
- 不知道 OP 用不用 iCloud ，其实 iCloud 就像时刻连接着的一根线，把设备的数据和苹果的服务器做 iTunes 同步。这里同步的是数据库而不是文件（ iCloud 云盘是后来才有的），所以后来它们还开放了 CloudKit 这个东西
- 苹果的自带软件和若干第三方软件都偏好用 iTunes 风格的数据库而不是文件夹存数据。我喜欢这种方式，因为数据库比文件要结构化得多，能存更多元数据，读写同步效率也都更高
- 但并不是所有数据都能放到数据库里，比如很大的照片或录像，它们适合存放在单独的文件里作为 Blob. 如果把这些数据库和 Blob 打包并规范化（开发一个统一 API 操作），那会十分方便，并且可以和第一点提到的协议结合，软件的各个小数据库其实是系统大数据库的一部分（有点像 Windows 注册表了？）
- 某些文档数据库已经自带了管理 Blob 到文件的功能
- 由于数据结构高度统一，快照、备份、回滚这些功能都变得很容易，可以用类似 zfs send/receive 的方法轻松备份和加密

Sigh.. 网站把我 List 的缩进吞了。

然后在上面提到的统一数据库基础上，提供一套 CRUD 接口，每个应用对应一个私有子库，也可以通过认证获得其他库的权限。并且这套接口不只是服务端可以用，客户端也可以用（本地数据库），因为它更像是点对点之间的 sync 而不是全靠请求获得资料的 B-S 模式。

但在客户端，这样有一个问题：数据库对客户端而言非常大。我们可以按需下载那些 Blob 文件，并且不下载过往的操作日志，剩下的数据库不会很大，还可以辅以压缩。（ V2EX 全站的用户和贴子数据装 Sqlite 里应该也只有几个 G ）

有了这套协议，我们就可以实现真·前后端分离的系统了。说简单一点，就是在本地实现了一套类似 LeanCloud 的东西，前端和客户端只需要假设本地或服务器有这个模块，连同步都是由这套实现自动完成。

楼主听过 obsidian 嘛哈哈，它现在有几个同步方案，跟你描述的 4 个场景一模一样，124 方案交给用户自己根据自己需要自己选择去折腾呗。不知道你说的 3 的可信问题是指啥？如何让用户相信自己的数据存你那是安全的嘛？这个感觉真的是个无法解决的问题😓，感觉你只能把口碑做出来以后，让用户自然而然相信你。

@ecnelises
感谢分享。

solid 要比我设想的复杂，我设想的就是数据库和文件都可以通过个人存储备份或者同步而已。个人可能也不需要那么多节点。

不过里面提到的共享可能有帮助，因为我也在考虑共享这个问题，文件的共享没什么问题，直接开一个库里面包括共享的文件列表以及访问密码或者解密方式就行了。但数据共享就麻烦，因为我想让用户可以自行设计所以数据库结构可能完全是动态的，会导致共享数据也要包括数据的定义甚至版本信息。而且数据的展示我还想给用户定义界面的能力，如果界面上加了不在共享里面的数据这样可能会让共享更加麻烦。最终方案可能是共享数据要么不提供界面（系统自动按表和详情去展示）要么用户共享时同时提供界面定义。

在我的设计中文件单独保存（笔记比较特殊目前考虑放数据库中），所以同步分数据库同步和文件同步。数据库增量，文件逐个。但因为数据库结构是用户可改的，如果一个终端长时间不上传，那么后面表结构甚至软件版本已经变了，再同步时可能会复杂。

目前软件设计的是单机软件，数据库准备使用 sqlite ，为了避嫌 /完全取得用户信任没有所谓的服务端。

@cdd2zju
对的，3 指的是用户不放心把数据（主要是数据库）放我这里，所以我设计的就是单机没有服务器，用户通过自己的网盘和自己的云存储账号进行。

@cdd2zju 其实最简单的就是数据库在云端但对于 PIM 系统没有几个人会放心放上去吧。

取消服务端，或者说所有客户端都能作为服务端，类似 DVCS 。
允许部分同步，只关心每个客户端节点需要处理的数据（比如 PC 和手机上生产的数据不一样，处理的数据也经常不一样），并允许后台自动同步，以提升响应和节约同步开销。
是不是要求完全同步才能用，根本上得看用户本人有没有强迫症不能容忍不同步，不是你能一刀切的问题。

说点半相关的：pacman 拒绝支持 git shallow clone （ bugs.archlinux.org/task/34677 ）很多次，乃至殃及下游也无法解决（ https://github.com/Jguer/yay/issues/1713 ）。
考虑到下游从逻辑上确实不那么好解决（不算 fix 只能是 workaround ），所以下游拒绝有合理性，问题出在上游。而上游维护者的理由是既然用了 git ，就该都用整个 repo 。
这种“哲学”（ bbs.archlinux.org/viewtopic.php?id=240972#4 ）原则上就很欠骂，philosophically not even wrong：为什么能心安理得假定带宽之类的基础设施问题一定能够被用户忽略？变相就是说如果出问题（比如嫌弃太慢）就爱用用不用润，然而这种地方是不是出问题根本上就不是用户说了算的。况且，如果 git 就只应该那样用，为什么 git 还要提供 shallow clone ？根本问题是，它以反直觉同时技术上没有必要的理由拒绝（从很多人重复提出就能看出来的）常规需求。
（其实 2202 了，git clone --depth=1 照样容易卡翔失败没法恢复，没断点续传这点本身就很欠揍。）
当然，退一万步讲，好歹它还是允许用 git 了。要是非得要求 svn ，那就不是欠揍的问题了。

以上问题欢迎对号入座。

@FrankHB
这个 DVCS 感觉又像 Git 了，这玩意儿实施起来我感觉更麻烦吧。开发人员可能还好理解，普通用户可能完全理解不了。PIM 这个产品针对个人而非团队使用，数据的安全（不易丢失）更重要，而终端又没那么稳定，比如手机和移动设备也易丢失，不及时把数据集中存储那么就丢了。

同步容易冲突以及量比较大的话，我还有一种设想是引导用户针对不同需要建立不同的数据库，比如写日记是一个，相册是一个，收集资料是一个，记录工作是另外一个。像分类 Tag 等可以由通用库负责。而这又带来跨库查询上的不便，除非同步很有问题才会考虑这么做。

关于要不要必须同步有时候也挺尴尬的，比如写笔记，你在 PC 上写完初稿，同步上传了。此时在手机上如果修改同一个笔记，如果不先同步下载最新版，那么手机上修改后提交可能会面临冲突，合并冲突并不简单。这只是简单数据场景，如果换成复杂的，比如是某种抓取规则。最新版抓取规则都已经换了，而你在手机上打开没有等同步就开始，那么你抓取的数据都与最新版有冲突。这处理起来就更麻烦了。

如果后面研究对比仍然比较复杂，那么可能还真是让用户要么全量同步，要么自架数据库服务器（这部分开源），要么使用官方服务器（适合小白用户，同时愿意相信官方）。

@Chad0000 你搞错了一个要点：集中存储更依赖单一设备可靠性，更容易丢，也就是彻底灭失无法恢复。不一致的存储只要能以合理的代价恢复就不算丢，而物理存储冗余是确保这个意义上不丢数据的不二法门。
和很多开发人员想像的相反，现代 DVCS 实现普遍做好的首先就是低成本的基本分布式内容冗余存储：想放哪就放哪，只要摸得到。这允许实现不易丢失的物理保障。否则，用户至少还得相信一个第三方运维来担保数据的安全，这物理上并没那么直接和靠谱；比起用户自己强的部分，只不过是真丢了数据后能承担补偿责任的事后诸葛亮而已。当然，考虑大多服务供应商存放数据的位置比一般用户物理上能摸到的地方更远，所以不担心数据被偷看的话，混合方案更好。
（ DVCS 实现的多版本管理反倒是其次的。）
只要是要同步的分布式系统就会有理解同步实现的问题。既然要同步，用户至少就得理解和谁同步，谁来保证完整性，否则就实际上会承受设备好好的，最新的完整正确内容却某天稀里糊涂就没了的风险。

@FrankHB
分布式存储方案我暂保留意见哈。

我认为普通个人是没有精力弄多个终端的，所以对于个人来说，可能更现实的方式是多个地方备份：
- 移动硬盘定期备份：插上，然后软件提示备份
- 网盘备份：最好是有 API 的，这样软件可自动备份
- 云存储：API 直接备份，最便宜的 B2
- 个人 NAS
从中再选一个作为同步中心，比如带 API 的网盘或云存储，可以只用来存储 DB ，基本上可以做到在免费额度（一般是 10G ）内就够用的地步。

@Chad0000 只要多端就得支持同步，这个是免不了的，无非是谁做的问题。比如局域网直接共享编辑文件是文件系统能做的，你就不用做（不过现在手机怕是连 CIFS 都普遍没支持好……）；数据库的底层对文件系统的同步你也不用做。但是大部分应用场景都没法支持远程直接修改数据的程序实时实现修改，或者根本不可能合理实现（比如带宽限制），所以这（不管是否用户可见而可能引入冲突）横竖都得你做——要么是提供 UI 允许用户自己同步，要么是启发式判断修改完就附加同步的逻辑，更好的是两者都有。
数据库“在远程无需同步”是你想得太简单了。而你现在想象中需要同步的简化做法，也不过是这种启发式地添加（而不是减少）一个附带同步的操作。
既然你也知道缺陷了，为什么不让用户自己选择？怕用户不懂，默认同步就行了，就是 UI 上的差别。
至于冲突，想要完全避免也是不方便的，比如会限制多端离线编辑（这是用户不喜欢 Web 应用的另一个常规理由）。你只需要在接口支持可能合并以及提供基本的实现（常规 DVCS 支持的文本就可以，工具都现成的，算法都不用自己搞）。具体应该怎么合并不是你需要考虑的，因为合并策略根本取决于数据的用途和用户的习惯，钦定具体一种同样不便。

@Chad0000 普通人用多终端是很常见的。有意识到 PIM 的用户中，一台 PC+一个手机算是基本配置，只有一台 PC 或者一个手机的反而不多见。特别是考虑数据来源的不同（比如 PC 通常不会直接处理照片，手机通常不会录入大量文本），要综合处理不同格式内容的系统基本总是迟早面临跨端同步的需求。

@FrankHB
Git clone 没法断点续传确实很难受，Hg 好歹有 Pack 这种东西，下载的时候能断点续传

其实我这里其实是有更具体的实际需求的，虽然不是你面向的用户层次，但根本上也算是 PIM 最终用户需求。
比如你提到的财产、健康数据之类，我现在是自己用 DSL 手工录入文本存储，大量数据还得清洗，所以数据处理部分我得自己实现。
如果你能针对你的需求提供一个方案，我可能复用你的数据持久层和部分 UI 。中间还是得自己做。你这里看来并没考虑二次开发，不过如果是开源的，我自己改改也能节约点工作量。
而另一个重要数据源是日常的截屏，比如交易和聊天记录存档以及游戏截图。这里大概还得 OCR 之类的所以二次开发要求更高，不过最主要的首先就是……数据存储和同步，然后就是根据图像识别分类（照片自带时间，大部分截图文件名带时间；有些文件名带包名，但更多没有，所以根本还是得分析内容）。
正常来讲，我希望你这里做的，至少框架上还是能足够复用，加点东西就能满足我的实际需求，而不是砍掉太多重来——对我来讲就没多少意义了。
数据量的话，文本几 M ，图像几百 G 吧……
另外我想要一个历时数据库，也就是把记录尽量和日历时间关联起来并提供视图便于查找统计。

@agagega 确实……hg 很多逻辑设计看起来都正常点，CLI 也没那么反人类。
但是 hg 本地存储就有些拉胯，特别是没 git pack 这种，大量小文件存储时间空间效率多数文件系统上都非常捉急……

@FrankHB
上面我可能说得不恰当误导你了，“没精力弄多个终端”是指基于分布式存储的多个终端，每个终端有自己的数据然后终端之间合并，这种我认为是不妥的。而后面你解释的是多个终端，然后同步到一起，这种是 Git 的方式了，还是有统一的数据中心（或者存储的地方）的，这个我们是一致的。

每个终端同步数据时冲突的处理无法避免，那么像你说的参考 Git 客户端或 DVCS 的处理方式可行，我也认同。只不过冲突处理对我来说比较麻烦，对于笔记这种纯文本冲突，可以使用成熟的库来处理，甚至只要是修改了同一处就是让用户确定合并是否正确。但因为这款软件我暂定是很多部分用低代码实现，低代码配置的冲突，以及使用这些代码衍生的数据的冲突（要知道用来定义这些数据的版本可能不一样），可能会把这个问题复杂化。

基于此我才会想搞这么麻烦是不是提供在线的数据中心会更好（数据中心做好自己的备份），每个人都可以架自己的数据中心，起码能保证终端有网络的时候能实时使用最新的，没网络的时候本地先暂存，之后再上传，都远比上面的同步方案简单。

当然现在还没有敲定怎么设计，你提供的建议和反馈都很重要。利弊拿出来讨论才有更好的方案。

@FrankHB #20

感谢提出你的需求，对我来说很有用。我也是有具体需求，所以这样的产品做起来才会有用：自己也是用户。对于这款产品，开源是最后的选项：我目前认为开源了我就基本上没什么指望了。因为数据特别敏感，官方存储始终不好解决信任问题，基于此我觉得没什么营利点。

关于二次开发或插件能力，你可以尽量提需求，我看是否有合适的解决办法。

我目前的想法是对插件提供基础能力，我会将 PIM 中的功能都用插件形式走一遍确保插件系统能支持，如果软件逐一实现的话那就太复杂了，而且无法完全适应个人灵活多变的需求：
- 数据：定义数据（表），访问和修改数据。
- UI：基于软件原始 UI 定义插件 UI 。
- 能力：提供一些 Function 可供用户任意安排，拿任务管理来说
- 启动任务、完成任务：会触发一系列数据读取分析和记录。
- 插件可以提供通过 API 将第三方任务同步过来的能力，或将任务数据同步到第三方。
- 需要 OCR 则系统可以集成，变成基础功能提供给插件用

数据方面，内部表示我用不到多少现成数据库的功能，至少不用典型的 RDBMS 那么复杂，有个面向记录的数据结构加一些简单的索引足够。分类 /贴标签可以用索引做。要用现有数据库，主要动机是大部分持久层和事务的功能不用自己实现了。
对 UI 我的要求更低，因为我不需要低代码管理，所以基本没什么编辑的要求，只要能正确预览和方便索引就行。另外还要加日历等浏览视图，这算是 PIM 软件常规功能。也许像 Windows 事件管理器那种改改加上预览可能都够了（虽然那个也不太有现成品）。
对我来说 OCR 不一定需要集成，主要是比较灵活，我不太确定现成的 OCR 能直接用，应该免不了针对具体需求二次开发。而且也需要同时处理图像提取其它数据，我在想是不是空了专门训练个模型之类。当然，这种定制就算是小众需求了。

@FrankHB
数据库没必要造车，直接使用 sqlite ，3.9 开始支持 json 更方便。

OCR 如果有现成的库可以集成。我使用 C#，不知道你使用什么语言。UI 这边的框架支持自绘动态加载，代码考虑集成 js 运行时或者 python 。深度能力可以通过本地 http 对接这样完全与开发语言没关系。