Local-first software

中文的翻译可以看这里。在云服务大行其道的当下，数据相关的问题开始也开始受到重视。如果在创作某样东西时投入了大量的精力，就会有很深的情感，自然会希望可以随时打开它，持续创作，但云服务无法保证这点。有太多可能出状况的地方了：服务出现问题导致无法访问或丢失或泄漏、合规问题、网络问题和隐私问题，还可能调整定价策略。当然像 Google 这样的大公司技术层面是有保障的，但由于依赖网络，体验上跟本地还是会有些差别，而且「网络不好就几乎不能用」这也是个限制。

Local First 不仅是数据存在本地，而且是优先使用本地数据，没有网络也可以正常使用，隐私也有保障。但随之而来的问题是不方便协同和跨平台（其实就是云服务的优势）。CRDT 技术一定程度上让 Local First 的协同变得可能，但依旧很难（想象 Git 的冲突）。所以我觉得这类场景不如放弃协同和跨平台，比如 Sketch。需要协同和跨平台的就放弃 Local First。

这篇文章从 7 个维度深度分析了 Local First 和云服务之间各自的优劣，以及在 Local First 软件如何解决协作的问题。

Unfortunately, cloud apps are problematic in this regard. Although they let you access your data anywhere, all data access must go via the server, and you can only do the things that the server will let you do. In a sense, you don’t have full ownership of that data — the cloud provider does. In the words of a bumper sticker: "There is no cloud, it’s just someone else’s computer."

"Old-fashioned" apps continue to work forever, as long as you have a copy of the data and some way of running the software. Even if the software author goes bust, you can continue running the last released version of the software. Even if the operating system and the computer it runs on become obsolete, you can still run the software in a virtual machine or emulator. As storage media evolve over the decades, you can copy your files to new storage media and continue to access them.

How NAT traversal works

中文翻译可以看这里，也可以看下作者翻译的另一篇文章作为铺垫。

本文的核心是让局域网里的两台电脑互相通信，因为都是在局域网所以无法直接通过公网 IP 来通信，这里就涉及到突破防火墙和 NAT。有一个思路很巧妙，大部分防火墙都设置为宽出严进（如可以请求外部链接，但拒绝外部设备的访问请求），而这个机制的核心是判断最近的出去记录上是否有目标地址，如果有表示这个是受信任的地址，也不管出去的请求是否真的到了这个地址。通过 STUN 服务器拿到两台设备的外网 IP 和端口后，就可以利用这个「协议漏洞」来建立连接了。

正如 80/20 定律一样，20% 的场景可能要花 80% 的功夫才能搞定，有一些 NAT 场景（hard NAT）即使是同一个 Socket 连接，访问不同的 IP 和端口，会在 NAT 设备上产生不同的 PORT，然后就要结合端口扫描来找到正确的 PORT，其中又会涉及到一些技巧来避免被判定为在扫描端口而加入黑名单，等等。

通过这篇文章可以对 NAT 和突破 NAT / 防火墙的限制，让局域网的机器互联有更多的了解。