关掉服务器以后

上周的一个晚上

上周有个晚上，我在手机上看一篇长文，看到一多半，眼睛撑不住，锁屏睡了。第二天早上坐到电脑前，想把剩下那点读完。手放上键盘我才发觉，我默认它会自己跟过来：读到哪儿、哪句话被我标了，都该原样待在那儿。这个默认很省事，省事到我从来没问过它是怎么做到的。

它凭什么跟过来，存在哪台机器上，那家公司明年还在不在，这些我平时不想。方便的东西都这样，用着的时候不觉得，一旦不灵了，才发现自己什么都不知道。那天早上我等了一会儿，页面才出来，进度停在昨晚开始的地方，我又从头翻了一遍才找到那个位置。十分钟的事，算不上损失，可我确实不知道它存在哪。

云端确实把这件事解决了

先说一件真让我付过代价的事。前几年我用过的一个笔记服务宣布关停，留了几个月导出期。东西是导出来了，可当初的层级和标签，还有我随手画的那几笔，基本散了。我花了一个周末把能救的搬进纯文本，剩下的就留在那儿。那之后我偶尔会想，我是不是把太多东西寄存在别人的门面里。

再把话说清楚：云端方案是真好用。换台设备接着读，进度自动对齐，收藏和标注跟着走；手机丢了，内容还在；几个人共读一份材料，谁添了什么一目了然。账号、订阅、云端书签，这些做法成熟到我们不再觉得它是一个选择。服务器替我记住了这些，我付一点订阅费，或者看几条广告，事情就结了。这是很划算的交换，多数时候也是唯一现实的选择。

我过不去的，是它默认的那个前提：你得先有个账号，把东西交出去，然后相信我，或者相信某家公司会一直开着门。

三条线

所以我给 MDViewer 划了本地优先的三条线。数据默认落在你自己的设备上，不经过我的服务器。要跨设备，由你选择同步，默认不上传。第三条最容易被略过：哪天我关掉服务器、不再维护，你已有的文件照样打得开。

第三条问的是寿命：这个应用能活多久，不该由一台服务器的存亡来定。我较真的也是这条——我自己也不能保证明年还在写它。

读到一半的东西

阅读和别的事情不太一样。刷到的内容、读了一半的长文、划线、批注、翻到哪一页，这些更像一个人的笔记，不太像使用数据。笔记该放在自己的抽屉里，要用的时候自己拿。

订阅制、账号体系、云端书签都成立，只是它们都建立在一个前提上：你得先相信我。而阅读这件事，我不太想以「相信一个独立开发者」为门槛。

一条判据

后来我给自己定了一条判据：如果明天我不做了，用户手上还剩下什么。云端方案常见的答案是「一堆打不开的链接」。我想要的答案是普通的 Markdown、普通的文件夹，换个应用也能打开，哪怕那个应用很简陋。

代价

本地优先不是没有代价。多设备之间的合并冲突要自己扛：同一个文件在两台机器上改过，谁后改的、要不要留两个版本，得你自己看。索引要自己建，书多了以后搜索快不快，全看本地那点算力。换手机得手动把文件搬过去，我现在是用数据线连上电脑，一个文件夹一个文件夹地拷。

还有一条反向的：手机丢了，别处又没备份，文件就没了。这一点云方案确实比我强，我不打算绕过去。

同步不做默认，还有个副作用：新用户第一次打开，看见的是一个空书架和「导入文件」四个字。我猜不少人到这一步就走了。

这些麻烦本来可以推给云端，一台服务器、一个账号体系就能盖住。我失去的是那种换台设备就能接着读的顺畅，也失去了「不用想文件在哪」的轻松。有时候我会怀疑，我是不是拿「数据是你的」当理由，掩盖自己做不好同步这件事。这个怀疑到现在也没消掉。

我也不太敢在应用里放一个「一键同步」的按钮。按下去之后，数据去了哪、留在哪，就又变成我说了算。

现在做到哪

MDViewer 现在的规矩是：文件是标准 Markdown，阅读功能不需要账号，同步是可选项，不是门槛。打开的是普通文件夹，三万多字的长文一秒出头，装完不用登录。

还没做到的是多设备无感。现在的同步要你自己挑一个位置，网盘、U 盘、局域网都行，没有一键方案。这是我故意留的口子：先把「数据是你的」做扎实，再谈方便。

昨天晚上我又读到一半，锁屏前把那个文件拷进手机里一个叫「在读」的文件夹。笨是笨了点，但我知道它在哪。