commit 77aa85b5ad5fe2db2303c76850a3f78e37eda53b
parent 378564ad5d813ae894184620d4ca2a696e04e9c7
Author: Shimmy Xu <shimmy.xu@shimmy1996.com>
Date: Fri, 10 Apr 2020 10:05:35 -0500
Touch up and translate Blog 9 from Outer Space
Diffstat:
3 files changed, 138 insertions(+), 21 deletions(-)
diff --git a/content/posts/2020-04-10-blog-9-from-outer-space.en.md b/content/posts/2020-04-10-blog-9-from-outer-space.en.md
@@ -5,18 +5,18 @@ slug = "blog-9-from-outer-space"
draft = false
+++
-Recently, I've been thinking about ways to unify my micro blog entries with my current site, and I've been reconsidering the ideas from [IndieWeb](https://indieweb.org/): unlike [ActivityPub](https://activitypub.rocks/) (the protocol Mastodon, Pleroma and the likes use for federation), which seems to want everything be done dynamically via server APIs and JSON responses, the various standards recommended by the IndieWeb community allows machine readable feed to be generated straight from a static HTML file correctly marked-up. A core idea that IndieWeb seem to implicitly rely on is the lifetime of the URIs, and to a greater extent, site owner's control over the domain name. Withe the recent [drama](https://www.eff.org/deeplinks/2020/03/members-congress-once-again-urge-icann-save-dot-org) regarding the .ORG domain, I came to realize that a future in which domain names are too expansive to maintain (or are subject to seizures by various entities) may not actually be too distant, and this could seriously undermine the entire premise IndieWeb is built upon, not to mention the a lot more common link rots. Fortunately, I think the [IPFS](https://ipfs.io/) (InterPlanetary File System) has the potential to solve both problems.
+Recently, I've been thinking about ways to unify my micro blog entries with my current site, and I've been reconsidering the ideas from [IndieWeb](https://indieweb.org/): unlike [ActivityPub](https://activitypub.rocks/) (the protocol Mastodon, Pleroma and the likes use for federation), which seems to want everything be done dynamically via server APIs and JSON responses, the various standards recommended by the IndieWeb community allows machine readable feed to be generated straight from a static HTML file correctly marked-up. A core idea that IndieWeb seem to implicitly rely on is the lifetime of the URIs, and to a greater extent, site owner's control over the domain name. Withe the recent [drama](https://www.eff.org/deeplinks/2020/03/members-congress-once-again-urge-icann-save-dot-org) regarding the .ORG domain, I came to realize that a future in which domain names are too expensive to maintain (or are subject to seizures by various entities) may not actually be too distant, and this could seriously undermine the entire premise IndieWeb is built upon, not to mention the a lot more common link rots. Fortunately, I think the [IPFS](https://ipfs.io/) (InterPlanetary File System) has the potential to solve both problems.
## A Crash Course on IPFS {#a-crash-course-on-ipfs}
-Now, now, I know IPFS has a really buzz-wordy vibe when compared to say the [Dat protocol](https://dat.foundation/), [pingfs](https://github.com/yarrick/pingfs), or even [Scruttlebutt](https://scuttlebutt.nz/), and the various cryptocurrency start-ups that bundle IPFS and all kinds of acronyms in their marketing materials surely doesn't do it any favors, but it does seem like the most established and ready-to-use. Here's my best attempt at explaining IPFS, with information mostly obtained from the [official documentation](https://docs.ipfs.io/) and [this talk](https://www.youtube.com/watch?v=HUVmypx9HGI). In case you are interested in further implementation details, [this session from IPFS Camp 2019](https://www.youtube.com/watch?v=Z5zNPwMDYGg) is a great resource.
+Now, now, I know when compared similar projects like the [Dat protocol](https://dat.foundation/), [pingfs](https://github.com/yarrick/pingfs), or even [Scruttlebutt](https://scuttlebutt.nz/), IPFS has a really buzz-wordy vibe (trust me, I was as skeptical as you are at the beginning) to it, and the various cryptocurrency start-ups that bundle IPFS and all kinds of acronyms in their marketing materials surely doesn't do it any favors, but it does seem like the most established and ready-to-use. Here's my best attempt at explaining IPFS, with information mostly obtained from the [official documentation](https://docs.ipfs.io/) and [this talk](https://www.youtube.com/watch?v=HUVmypx9HGI). In case you are interested in further implementation details, [this session from IPFS Camp 2019](https://www.youtube.com/watch?v=Z5zNPwMDYGg) is a great resource.
A simplified interpretation of link to an web page is but a fancy way to point to a file on some server. Just like path to a file, the link would be unreachable if the server is down, even if someone sitting in the same room might have the contents cached. In IPFS, files (or data blocks) are addressed by corresponding cryptographic hashes of their contents, and stored in a distributed fashion across all peers. This means no centralized facility is required to access the files, file integrity can be easily verified, P2P sharing can be used to speed up access, and files stored this way are inherently immutable.
-Not being able to change files seems like a rather large price to pay, but just like any other problem in computer science, this can be solved by adding a layer of abstraction. IPNS (InterPlanetary Name System) utilizes public-key cryptography to create immutable addresses that can point to different files. An IPNS address is basically the hash of a public key. An IPNS lookup would involve searching for files (each containing an IPFS address) signed by the corresponding private keys, identifying the most recent one, and redirecting to the correct file. To utilize IPNS, the user would start by creating a public-private key pair, followed by uploading desired files into IPNS, and sign and upload a pointer file containing IPFS address to the uploaded content. When an update is desired, the user only need to sign and upload another pointer file to the new location.
+Not being able to change files seems like a rather large price to pay, but just like any other problem in computer science, this can be solved by adding a layer of abstraction. IPNS (InterPlanetary Name System) utilizes public-key cryptography to create immutable addresses that can point to different files. An IPNS address is basically the hash of a public key. An IPNS lookup would involve retrieval of the public key, searching for files (each containing an IPFS address) signed by the corresponding private keys, identifying the most recent one, and finally redirecting to the correct file. To utilize IPNS, the user would start by creating a public-private key pair, followed by uploading desired files into IPNS, and sign and upload a pointer file containing IPFS address to the uploaded content. When an update is desired, the user only need to sign and upload another pointer file to the new location.
-A lot of ideas used in IPFS has been explored before by projects like BitTorrent (peer-to-peer sharing), [Fossil](https://en.wikipedia.org/wiki/Fossil%5F(file%5Fsystem)) and [Venti](https://en.wikipedia.org/wiki/Venti) from Plan9 (write-once data blocks and path redirection), git (Merkle tree), etc. However, the killer feature is how easily IPFS integrates with existing infrastructure. Not only are there HTTP gateways that allows for accessing IPFS/IPNS from web browsers instead of IPFS clients, but also compatibility with FUSE (Filesystem in Userspace), which actually allows you to mount the entire IPFS as a read-only partition (sure this also makes hosting static websites possible, but you have to admit that having access to a global-scale P2P shared drive is way cooler).
+A lot of ideas used in IPFS has been explored before by projects like BitTorrent (peer-to-peer sharing), [Fossil](https://en.wikipedia.org/wiki/Fossil%5F(file%5Fsystem)) and [Venti](https://en.wikipedia.org/wiki/Venti) from Plan9 (write-once data blocks and path redirection), git (Merkle tree/directed acyclic graph), etc. However, the killer feature is how easily IPFS integrates with existing infrastructure. Not only are there HTTP gateways that allows for accessing IPFS/IPNS from web browsers instead of IPFS clients, but also compatibility with FUSE (Filesystem in Userspace), which actually allows you to mount the entire IPFS as a read-only partition: sure this also makes hosting static websites possible, but you have to admit that having access to a global-scale (or should I say, interplanetary?) P2P shared drive is way cooler.
## Hosting Static Websites on IPFS {#hosting-static-websites-on-ipfs}
@@ -25,10 +25,13 @@ The [official guide](https://docs-beta.ipfs.io/how-to/command-line-quick-start/)
- Run `ipfs init` and `ipfs daemon` to initialize and start the IPFS client.
- Generate the website files and run `ipfs add -r <website-root>` to send its contents onto the IPFS. The last few lines of the output should tell you the hash for the root directory.
-- If you want to make use of IPNS, run `ipfs name publish <website-root-hash>` to direct the IPNS link to the folder you just uploaded. The IPNS address can be obtained via `ipfs id | grep ID`.
-- Repeat the last two steps every time and the website files are updated or rebuilt. The process has little overhead due to the inherent deduplication in addressing, making it particularly suitable for static sites where smaller files (HTML and CSS files) tend to change more often than larger files (photos and other media files).
+- If you want to make use of IPNS, run `ipfs name publish <website-root-hash>` to direct the IPNS link to the folder you just uploaded. The IPNS public key hash can be obtained via `ipfs key list -l`.
+- Repeat the last two steps every time and the website files are updated or rebuilt. The process has little overhead due to the inherent deduplication in addressing, making it particularly suitable for static sites where larger files (like photos) tend to change less often.
-Once this is done, you can access your website at either `<gatway-address>/ipfs/<website-root-hash>` or `<gatway-address>/ipns/<ipns-address>` from any HTTP gateway: you can use the local one (likely at `127.0.0.1:8080`) started by the IPFS daemon, or any of [the public ones](https://ipfs.github.io/public-gateway-checker/) (comes with extra risk of MITM attacks from the gateway owners as file retrieval is done on the gateway servers). You can also make use of the [DNSLink](https://docs.ipfs.io/guides/concepts/dnslink/) functionality, by adding a TXT record to your existing domain:
+Once this is done, you can access your website at either `<gatway-address>/ipfs/<website-root-hash>` or `<gatway-address>/ipns/<ipns-address>` from any HTTP gateway: you can use the local one (likely at `127.0.0.1:8080`) started by the IPFS daemon, or any of [the public ones](https://ipfs.github.io/public-gateway-checker/) (comes with extra risk of MITM attacks from the gateway owners as file retrieval is done on the gateway servers). In case you have multiple websites, you can generate more IPNS key pairs using `ipns key gen`, and specify `--key` when running `ipfs name publish` to a specific IPNS address.
+
+Before IPFS [supports import/export of the IPNS keys](https://github.com/ipfs/go-ipfs/issues/4240) though (so that we can backup keys and publish from multiple devices), [DNSLink](https://docs.ipfs.io/guides/concepts/dnslink/) can be used to more conveniently maintain access to a site, albeit at the cost of depending on owning a domain name and trusting the DNS host provider. To allow access to the site from the gateways via `/ipns/<domain-name>`,
+simply add a TXT record to the domain:
```text
dnslink=/ipfs/<website-root-hash>
@@ -40,17 +43,19 @@ or
dnslink=/ipns/<ipns-address>
```
-This would allow access to the website from the gateways via `/ipns/<domain-name>`, easier to remember for most. For instance, you can now access this site using the `ipfs.io` gateway [here](https://ipfs.io/ipns/shimmy1996.com/).
+For instance, you can now access this site using at [`/ipns/shimmy1996.com`](https://ipfs.io/ipns/shimmy1996.com/) (this is a link using the ipfs.io gateway). While not flawless, to me this is a reasonable compromise for now.
-Do note that because the additional IPFS address in the URL when accessing the files from HTTP gateways, we need to use relative URLs in the generated files. In Hugo, this can be achieved by setting
+Do note that like using any offline HTML files, we need to use relative URLs in the generated web pages. In Hugo, this can be achieved by setting
```toml
relativeURLs = true
```
+in `config.toml`.
+
Of course, being a P2P network, IPFS won't be able to retrieve the files if there is no copy to work with at all. By default, IPFS client would [pin](https://docs.ipfs.io/guides/concepts/pinning/) anything you shared from the local machine: pinned contents won't get deleted, ensuring at least one copy of the shared content is available on IPFS. You can unpin outdated versions of the website, or if you want, find and pin the shared directory on multiple machines for some redundancy.
## The Stars, Like Dust {#the-stars-like-dust}
-Back to the issue with IndieWeb: the increasingly shady domain name system and link rots makes URI stability in HTTP is hard to maintain. However, what if we use IPFS/IPNS addresses as URIs? It's a match made in heaven: we get robust distributed access to static web pages, gated by Mathematics instead of FBI warnings. Removing the need for maintaining a server also lowers the barrier of entry of owning a website. The HTTP protocol has existed for 29 years, and IPFS, only 5. I don't know if IPFS will continue to exist for the next 24 years to come, but if it does, I'm sure we will be looking at a more robust, perhaps more chaotic, but more lively and colorful online world.
+Back to the issue with IndieWeb: the increasingly shady domain name system and link rots makes URI stability in HTTP hard to maintain. However, what if we use IPFS/IPNS addresses as URIs? It's a match made in heaven: we get robust distributed access to static web pages, gated by Mathematics instead of FBI warnings, that can theoretically last forever. Removing the need for maintaining a server also lowers the barrier of entry of owning a website. The HTTP protocol has existed for 29 years, and IPFS, only 5. I don't know if IPFS will continue to exist for the next 24 years to come, but if it does, I hope we will be looking at a perhaps more chaotic, but more robust, lively, and colorful, online world.
diff --git a/content/posts/2020-04-10-blog-9-from-outer-space.zh.md b/content/posts/2020-04-10-blog-9-from-outer-space.zh.md
@@ -0,0 +1,60 @@
++++
+title = "外太空九号博客"
+date = 2020-04-10T09:53:00-05:00
+slug = "blog-9-from-outer-space"
+draft = false
++++
+
+最近，我在想办法将我的微型博客整合到当前网站里，所以我开始在重新考虑[IndieWeb](https://indieweb.org/)所提倡的一些构想：与希望一切都通过服务器API和JSON响应来动态完成的[ActivityPub](https://activitypub.rocks/)（长毛象（Mastodon），Pleroma等用于互联的协议）不同，IndieWeb社区推荐的不少标准都支持从有正确标记的静态HTML文件中直接生成机器可读的网站源。IndieWeb隐含地依赖的一大核心要素是URI（统一资源标志符）的稳定性，或者从更高的角度来说，站点所有者对域名的控制。由于最近关于.ORG域名的[闹剧](https://www.eff.org/deeplinks/2020/03/members-congress-once-again-urge-icann-save-dot-org)，我逐渐意识到，一个域名昂贵到无法维护（或可能随时被扣押）的未来可能并不是遥不可及的。这可能会严重破坏整个IndieWeb赖以建立的前提，更不用说更常见的链接失效。幸运的是，我觉得[IPFS](https://ipfs.io/)（星际文件系统）有潜力能够解决这两个问题。
+
+
+## IPFS 速成班 {#ipfs-速成班}
+
+好的，好的，我知道和一些类似的项目，例如[Dat协议](https://dat.foundation/)，[pingfs](https://github.com/yarrick/pingfs)，甚至[Scruttlebutt](https://scuttlebutt.nz/)，比起来，IPFS的名称听起来非常不靠谱（相信我，我开始时也和你一样怀疑），而不少加密货币类创业公司将IPFS与各种首字母缩写词混杂在其营销资料中的事实更降低了它的可信度，但IPFS看起来的确是类似项目中最成熟且易于使用的。以下我对解释IPFS所做的尝试，其信息大部分来自[官方文档](https://docs.ipfs.io/)和[这一演座](https://www.youtube.com/watch?v=HUVmypx9HGI)。如果你对进一步的实施细节感兴趣，[这一来自IPFS Camp 2019的专题讨论](https://www.youtube.com/watch?v=Z5zNPwMDYGg)是一个很好的资源。
+
+简单地说，一条网页链接只是指向某服务器上文件路径的一种花哨说法。就像一般的文件路径一样，服务器下线后，即使坐在同一房间的某人可能缓存了网页内容，该链接也无法被访问。在IPFS中，文件（或数据块）通过与其内容相应的加密哈希值作为地址，并以分布式的方式存储在所有用户群中。这意味着我们不需要中心化的设施来访问文件、可以简单地地验证文件完整性、可以使用P2P共享来加快访问速度、以及以这种方式存储的文件内容是无法改变的。
+
+无法更改文件内容相比我们所得到的好处来说似乎是一个相当昂贵的代价，但是就像计算机科学中的任何其他问题一样，这可以通过添加抽象层来解决。解决这一问题的IPNS（星际域名系统）利用公钥加密来创建可以指向不同文件的不可变地址。IPNS地址基本上就是某个公钥的哈希值。一次IPNS查找包括取回公钥本身、搜索具有相应的私钥签名的指针文件（一个包含IPFS地址的文件）、辨认最新的指针文件、以及重定向到正确的地址几个步骤。要利用IPNS，用户首先要创建一个公私钥对，然后将公钥、想分享的文件和带有签名的指针文件上传到IPFS上。当需要更新时，用户只需要签署并上传新的指针文件就可以了。
+
+IPFS的不少方面都可以在过去的项目中看到踪影，例如BitTorrent（P2P共享）、Plan 9下的[Fossil](https://zh.wikipedia.org/zh-cn/Fossil%5F(%25E6%25AA%2594%25E6%25A1%2588%25E7%25B3%25BB%25E7%25B5%25B1))和[Venti](https://en.wikipedia.org/wiki/Venti)（一次写入的数据块和路径重定向）、和git（哈希树/有向无环图）。但是，IPFS的杀手级功能在于其与现有架构集成的便捷程度。专用的HTTP网关允许从浏览器（而不是IPFS客户端）中直接访问IPFS或IPNS地址，而且IPFS还具有与FUSE（用户空间中的文件系统）的兼容性，这意味着我们甚至可以将整个IPFS挂载为一个只读分区：这一兼容性也让我们能够托管静态网站，但是我必须承认，访问全球（甚至星际）规模的P2P共享盘是个明显更酷的用法。
+
+
+## 在 IPFS 上架设静态网站 {#在-ipfs-上架设静态网站}
+
+[官方指南](https://docs-beta.ipfs.io/how-to/command-line-quick-start/)已经很好地概述了使用方法。以下是简要概括：
+
+- 运行`ipfs init`和`ipfs daemon`初始化并启动IPFS守护进程。
+- 生成网站文件并运行`ipfs add -r <网站文件路径>`将其内容发送到IPFS。输出的最后几行会有路径根目录的哈希值。
+- 如果要使用IPNS，请运行`ipfs name publish <网站根目录哈希>`以将IPNS链接定向到刚刚上传的文件夹上。IPNS公钥的哈希值可以通过`ipfs key list -l`获得。
+- 在更新或重建网站文件时重复以上两个步骤。由于IPFS寻址过程固有的数据去重功能，该过程的实际开销并不大。对静态站点这一用例来说非常合适：越大的文件（例如照片）更新频率就越低。
+
+完成此操作后，我们就可以从任何专用HTTP网关使用`<网关地址>/ipfs/<网站根目录哈希>`或`<网关地址>/ipns/<ipns地址>`来访问刚才上传的网站了：我们可以使用由IPFS守护进程启动的本地网关（通常位于`127.0.0.1:8080`），也可以使用[公共网关](https://ipfs.github.io/public-gateway-checker/)（由于IPFS文件取回需要在运行网关的服务器上进行，因此使用公共网关有遭受来自服务器所有者的中间人攻击的额外风险）。如果想要架设多个网站，则可以使用`ipns key gen`来生成更多IPNS密钥对，并在执行`ipfs name publish`时通过`--key`选项指定发布地址。
+
+在IPFS[支持IPNS密钥的导入/导出](https://github.com/ipfs/go-ipfs/issues/4240)之前（这有助于我们备份密钥并从多台设备发布内容），[DNSLink](https://docs.ipfs.io/guides/concepts/dnslink/)可用于更方便地维护到站点的网关，但代价是需要拥有域名并信任DNS服务提供者。要想通过 `/ipns/<域名>` 从HTTP网关访问站点，只需为域名加入一下TXT记录：
+
+```text
+dnslink=/ipfs/<网站根目录哈希>
+```
+
+或
+
+```text
+dnslink=/ipns/<ipns地址>
+```
+
+例如本站就可以通过[`/ipns/shimmy1996.com`](https://ipfs.io/ipns/shimmy1996.com/)（该链接使用ipfs.io架设的公共网关）来访问。虽然算不上是一个完全没有缺点的办法，但对我来说这是个合理的妥协。
+
+对了，还需要注意的是，正如同使用任何脱机HTML文件时一样，我们需要在生成的网页中使用相对链接。在Hugo中，这可以通过在`config.toml`中加入
+
+```toml
+relativeURLs = true
+```
+
+来实现。
+
+当然，作为一个P2P网络，IPFS无法取回已经不存在于任何节点上的文件。默认情况下，IPFS客户端会[固定](https://docs.ipfs.io/guides/concepts/pinning/)从本地计算机共享的任何内容：固定内容不会被删除，这确保IPFS上至少有一个可用的副本。我们可以取消固定网站的过时版本，或者，如果需要，在多台设备上查找并固定网站地址以防万一。
+
+
+## 繁星若尘 {#繁星若尘}
+
+回到IndieWeb的问题上：越来越黑的域名系统和链接失效使基于HTTP的URI的稳定性难以保证。但是，如果我们使用IPFS或IPNS地址作为URI呢？简直完美！我们通过由数学而非FBI警告所控制的地址获得了（理论上可以永久持续下去的）对静态网页的稳定分布式访问。消除拥有服务器的需要还降低了拥有个人网站的门槛。HTTP协议已经存在了29年，而IPFS仅存在了5年。我不知道IPFS在接下来的24年中是否还会继续存在，但是如果是的话，我希望我们会看到一个或许更加混乱，但更加健壮、充满活力、多彩的在线世界。
diff --git a/org/2020.org b/org/2020.org
@@ -321,7 +321,7 @@ don't cover all the bases in my experience.
在解决了我在线存在的只写任务需求后，我将继续探索剩下的两个难题：只读（内容消费）和交互（通讯方式）类操作。目前，订阅源和电子邮件是我最好的答案，但是它们仍然不足以涵盖我所有的需求。
-* TODO Blog 9 from Outer Space
+* DONE Blog 9 from Outer Space
:PROPERTIES:
:EXPORT_HUGO_SLUG: blog-9-from-outer-space
:END:
@@ -333,25 +333,28 @@ CLOSED: [2020-04-10 Fri 01:27]
:EXPORT_TITLE: Blog 9 from Outer Space
:END:
-Recently, I've been thinking about ways to unify my micro blog entries with my current site, and I've been reconsidering the ideas from [[https://indieweb.org/][IndieWeb]]: unlike [[https://activitypub.rocks/][ActivityPub]] (the protocol Mastodon, Pleroma and the likes use for federation), which seems to want everything be done dynamically via server APIs and JSON responses, the various standards recommended by the IndieWeb community allows machine readable feed to be generated straight from a static HTML file correctly marked-up. A core idea that IndieWeb seem to implicitly rely on is the lifetime of the URIs, and to a greater extent, site owner's control over the domain name. Withe the recent [[https://www.eff.org/deeplinks/2020/03/members-congress-once-again-urge-icann-save-dot-org][drama]] regarding the .ORG domain, I came to realize that a future in which domain names are too expansive to maintain (or are subject to seizures by various entities) may not actually be too distant, and this could seriously undermine the entire premise IndieWeb is built upon, not to mention the a lot more common link rots. Fortunately, I think the [[https://ipfs.io/][IPFS]] (InterPlanetary File System) has the potential to solve both problems.
+Recently, I've been thinking about ways to unify my micro blog entries with my current site, and I've been reconsidering the ideas from [[https://indieweb.org/][IndieWeb]]: unlike [[https://activitypub.rocks/][ActivityPub]] (the protocol Mastodon, Pleroma and the likes use for federation), which seems to want everything be done dynamically via server APIs and JSON responses, the various standards recommended by the IndieWeb community allows machine readable feed to be generated straight from a static HTML file correctly marked-up. A core idea that IndieWeb seem to implicitly rely on is the lifetime of the URIs, and to a greater extent, site owner's control over the domain name. Withe the recent [[https://www.eff.org/deeplinks/2020/03/members-congress-once-again-urge-icann-save-dot-org][drama]] regarding the .ORG domain, I came to realize that a future in which domain names are too expensive to maintain (or are subject to seizures by various entities) may not actually be too distant, and this could seriously undermine the entire premise IndieWeb is built upon, not to mention the a lot more common link rots. Fortunately, I think the [[https://ipfs.io/][IPFS]] (InterPlanetary File System) has the potential to solve both problems.
*** A Crash Course on IPFS
-Now, now, I know IPFS has a really buzz-wordy vibe when compared to say the [[https://dat.foundation/][Dat protocol]], [[https://github.com/yarrick/pingfs][pingfs]], or even [[https://scuttlebutt.nz/][Scruttlebutt]], and the various cryptocurrency start-ups that bundle IPFS and all kinds of acronyms in their marketing materials surely doesn't do it any favors, but it does seem like the most established and ready-to-use. Here's my best attempt at explaining IPFS, with information mostly obtained from the [[https://docs.ipfs.io/][official documentation]] and [[https://www.youtube.com/watch?v=HUVmypx9HGI][this talk]]. In case you are interested in further implementation details, [[https://www.youtube.com/watch?v=Z5zNPwMDYGg][this session from IPFS Camp 2019]] is a great resource.
+Now, now, I know when compared similar projects like the [[https://dat.foundation/][Dat protocol]], [[https://github.com/yarrick/pingfs][pingfs]], or even [[https://scuttlebutt.nz/][Scruttlebutt]], IPFS has a really buzz-wordy vibe (trust me, I was as skeptical as you are at the beginning) to it, and the various cryptocurrency start-ups that bundle IPFS and all kinds of acronyms in their marketing materials surely doesn't do it any favors, but it does seem like the most established and ready-to-use. Here's my best attempt at explaining IPFS, with information mostly obtained from the [[https://docs.ipfs.io/][official documentation]] and [[https://www.youtube.com/watch?v=HUVmypx9HGI][this talk]]. In case you are interested in further implementation details, [[https://www.youtube.com/watch?v=Z5zNPwMDYGg][this session from IPFS Camp 2019]] is a great resource.
A simplified interpretation of link to an web page is but a fancy way to point to a file on some server. Just like path to a file, the link would be unreachable if the server is down, even if someone sitting in the same room might have the contents cached. In IPFS, files (or data blocks) are addressed by corresponding cryptographic hashes of their contents, and stored in a distributed fashion across all peers. This means no centralized facility is required to access the files, file integrity can be easily verified, P2P sharing can be used to speed up access, and files stored this way are inherently immutable.
-Not being able to change files seems like a rather large price to pay, but just like any other problem in computer science, this can be solved by adding a layer of abstraction. IPNS (InterPlanetary Name System) utilizes public-key cryptography to create immutable addresses that can point to different files. An IPNS address is basically the hash of a public key. An IPNS lookup would involve searching for files (each containing an IPFS address) signed by the corresponding private keys, identifying the most recent one, and redirecting to the correct file. To utilize IPNS, the user would start by creating a public-private key pair, followed by uploading desired files into IPNS, and sign and upload a pointer file containing IPFS address to the uploaded content. When an update is desired, the user only need to sign and upload another pointer file to the new location.
+Not being able to change files seems like a rather large price to pay, but just like any other problem in computer science, this can be solved by adding a layer of abstraction. IPNS (InterPlanetary Name System) utilizes public-key cryptography to create immutable addresses that can point to different files. An IPNS address is basically the hash of a public key. An IPNS lookup would involve retrieval of the public key, searching for files (each containing an IPFS address) signed by the corresponding private keys, identifying the most recent one, and finally redirecting to the correct file. To utilize IPNS, the user would start by creating a public-private key pair, followed by uploading desired files into IPNS, and sign and upload a pointer file containing IPFS address to the uploaded content. When an update is desired, the user only need to sign and upload another pointer file to the new location.
-A lot of ideas used in IPFS has been explored before by projects like BitTorrent (peer-to-peer sharing), [[https://en.wikipedia.org/wiki/Fossil_(file_system)][Fossil]] and [[https://en.wikipedia.org/wiki/Venti][Venti]] from Plan9 (write-once data blocks and path redirection), git (Merkle tree), etc. However, the killer feature is how easily IPFS integrates with existing infrastructure. Not only are there HTTP gateways that allows for accessing IPFS/IPNS from web browsers instead of IPFS clients, but also compatibility with FUSE (Filesystem in Userspace), which actually allows you to mount the entire IPFS as a read-only partition (sure this also makes hosting static websites possible, but you have to admit that having access to a global-scale P2P shared drive is way cooler).
+A lot of ideas used in IPFS has been explored before by projects like BitTorrent (peer-to-peer sharing), [[https://en.wikipedia.org/wiki/Fossil_(file_system)][Fossil]] and [[https://en.wikipedia.org/wiki/Venti][Venti]] from Plan9 (write-once data blocks and path redirection), git (Merkle tree/directed acyclic graph), etc. However, the killer feature is how easily IPFS integrates with existing infrastructure. Not only are there HTTP gateways that allows for accessing IPFS/IPNS from web browsers instead of IPFS clients, but also compatibility with FUSE (Filesystem in Userspace), which actually allows you to mount the entire IPFS as a read-only partition: sure this also makes hosting static websites possible, but you have to admit that having access to a global-scale (or should I say, interplanetary?) P2P shared drive is way cooler.
*** Hosting Static Websites on IPFS
The [[https://docs-beta.ipfs.io/how-to/command-line-quick-start/][official guide]] already outlines the general usage pattern pretty well. Here's the TLDR:
- Run =ipfs init= and =ipfs daemon= to initialize and start the IPFS client.
- Generate the website files and run =ipfs add -r <website-root>= to send its contents onto the IPFS. The last few lines of the output should tell you the hash for the root directory.
-- If you want to make use of IPNS, run =ipfs name publish <website-root-hash>= to direct the IPNS link to the folder you just uploaded. The IPNS address can be obtained via =ipfs id | grep ID=.
-- Repeat the last two steps every time and the website files are updated or rebuilt. The process has little overhead due to the inherent deduplication in addressing, making it particularly suitable for static sites where smaller files (HTML and CSS files) tend to change more often than larger files (photos and other media files).
+- If you want to make use of IPNS, run =ipfs name publish <website-root-hash>= to direct the IPNS link to the folder you just uploaded. The IPNS public key hash can be obtained via =ipfs key list -l=.
+- Repeat the last two steps every time and the website files are updated or rebuilt. The process has little overhead due to the inherent deduplication in addressing, making it particularly suitable for static sites where larger files (like photos) tend to change less often.
-Once this is done, you can access your website at either =<gatway-address>/ipfs/<website-root-hash>= or =<gatway-address>/ipns/<ipns-address>= from any HTTP gateway: you can use the local one (likely at =127.0.0.1:8080=) started by the IPFS daemon, or any of [[https://ipfs.github.io/public-gateway-checker/][the public ones]] (comes with extra risk of MITM attacks from the gateway owners as file retrieval is done on the gateway servers). You can also make use of the [[https://docs.ipfs.io/guides/concepts/dnslink/][DNSLink]] functionality, by adding a TXT record to your existing domain:
+Once this is done, you can access your website at either =<gatway-address>/ipfs/<website-root-hash>= or =<gatway-address>/ipns/<ipns-address>= from any HTTP gateway: you can use the local one (likely at =127.0.0.1:8080=) started by the IPFS daemon, or any of [[https://ipfs.github.io/public-gateway-checker/][the public ones]] (comes with extra risk of MITM attacks from the gateway owners as file retrieval is done on the gateway servers). In case you have multiple websites, you can generate more IPNS key pairs using =ipns key gen=, and specify =--key= when running =ipfs name publish= to a specific IPNS address.
+
+Before IPFS [[https://github.com/ipfs/go-ipfs/issues/4240][supports import/export of the IPNS keys]] though (so that we can backup keys and publish from multiple devices), [[https://docs.ipfs.io/guides/concepts/dnslink/][DNSLink]] can be used to more conveniently maintain access to a site, albeit at the cost of depending on owning a domain name and trusting the DNS host provider. To allow access to the site from the gateways via =/ipns/<domain-name>=,
+simply add a TXT record to the domain:
#+begin_example
dnslink=/ipfs/<website-root-hash>
#+end_example
@@ -359,17 +362,66 @@ or
#+begin_example
dnslink=/ipns/<ipns-address>
#+end_example
-This would allow access to the website from the gateways via =/ipns/<domain-name>=, easier to remember for most. For instance, you can now access this site using the =ipfs.io= gateway [[https://ipfs.io/ipns/shimmy1996.com/][here]].
+For instance, you can now access this site using at [[https://ipfs.io/ipns/shimmy1996.com/][=/ipns/shimmy1996.com=]] (this is a link using the ipfs.io gateway). While not flawless, to me this is a reasonable compromise for now.
-Do note that because the additional IPFS address in the URL when accessing the files from HTTP gateways, we need to use relative URLs in the generated files. In Hugo, this can be achieved by setting
+Do note that like using any offline HTML files, we need to use relative URLs in the generated web pages. In Hugo, this can be achieved by setting
#+BEGIN_SRC toml
relativeURLs = true
#+END_SRC
+in =config.toml=.
Of course, being a P2P network, IPFS won't be able to retrieve the files if there is no copy to work with at all. By default, IPFS client would [[https://docs.ipfs.io/guides/concepts/pinning/][pin]] anything you shared from the local machine: pinned contents won't get deleted, ensuring at least one copy of the shared content is available on IPFS. You can unpin outdated versions of the website, or if you want, find and pin the shared directory on multiple machines for some redundancy.
*** The Stars, Like Dust
-Back to the issue with IndieWeb: the increasingly shady domain name system and link rots makes URI stability in HTTP is hard to maintain. However, what if we use IPFS/IPNS addresses as URIs? It's a match made in heaven: we get robust distributed access to static web pages, gated by Mathematics instead of FBI warnings. Removing the need for maintaining a server also lowers the barrier of entry of owning a website. The HTTP protocol has existed for 29 years, and IPFS, only 5. I don't know if IPFS will continue to exist for the next 24 years to come, but if it does, I'm sure we will be looking at a more robust, perhaps more chaotic, but more lively and colorful online world.
+Back to the issue with IndieWeb: the increasingly shady domain name system and link rots makes URI stability in HTTP hard to maintain. However, what if we use IPFS/IPNS addresses as URIs? It's a match made in heaven: we get robust distributed access to static web pages, gated by Mathematics instead of FBI warnings, that can theoretically last forever. Removing the need for maintaining a server also lowers the barrier of entry of owning a website. The HTTP protocol has existed for 29 years, and IPFS, only 5. I don't know if IPFS will continue to exist for the next 24 years to come, but if it does, I hope we will be looking at a perhaps more chaotic, but more robust, lively, and colorful, online world.
+
+** DONE zh
+CLOSED: [2020-04-10 Fri 09:53]
+:PROPERTIES:
+:EXPORT_FILE_NAME: 2020-04-10-blog-9-from-outer-space.zh.md
+:EXPORT_TITLE: 外太空九号博客
+:END:
+
+最近，我在想办法将我的微型博客整合到当前网站里，所以我开始在重新考虑[[https://indieweb.org/][IndieWeb]]所提倡的一些构想：与希望一切都通过服务器API和JSON响应来动态完成的[[https://activitypub.rocks/][ActivityPub]]（长毛象（Mastodon），Pleroma等用于互联的协议）不同，IndieWeb社区推荐的不少标准都支持从有正确标记的静态HTML文件中直接生成机器可读的网站源。IndieWeb隐含地依赖的一大核心要素是URI（统一资源标志符）的稳定性，或者从更高的角度来说，站点所有者对域名的控制。由于最近关于.ORG域名的[[https://www.eff.org/deeplinks/2020/03/members-congress-once-again-urge-icann-save-dot-org][闹剧]]，我逐渐意识到，一个域名昂贵到无法维护（或可能随时被扣押）的未来可能并不是遥不可及的。这可能会严重破坏整个IndieWeb赖以建立的前提，更不用说更常见的链接失效。幸运的是，我觉得[[https://ipfs.io/][IPFS]]（星际文件系统）有潜力能够解决这两个问题。
+
+*** IPFS 速成班
+好的，好的，我知道和一些类似的项目，例如[[https://dat.foundation/][Dat协议]]，[[https://github.com/yarrick/pingfs][pingfs]]，甚至[[https://scuttlebutt.nz/][Scruttlebutt]]，比起来，IPFS的名称听起来非常不靠谱（相信我，我开始时也和你一样怀疑），而不少加密货币类创业公司将IPFS与各种首字母缩写词混杂在其营销资料中的事实更降低了它的可信度，但IPFS看起来的确是类似项目中最成熟且易于使用的。以下我对解释IPFS所做的尝试，其信息大部分来自[[https://docs.ipfs.io/][官方文档]]和[[https://www.youtube.com/watch?v=HUVmypx9HGI][这一演座]]。如果你对进一步的实施细节感兴趣，[[https://www.youtube.com/watch?v=Z5zNPwMDYGg][这一来自IPFS Camp 2019的专题讨论]]是一个很好的资源。
+
+简单地说，一条网页链接只是指向某服务器上文件路径的一种花哨说法。就像一般的文件路径一样，服务器下线后，即使坐在同一房间的某人可能缓存了网页内容，该链接也无法被访问。在IPFS中，文件（或数据块）通过与其内容相应的加密哈希值作为地址，并以分布式的方式存储在所有用户群中。这意味着我们不需要中心化的设施来访问文件、可以简单地地验证文件完整性、可以使用P2P共享来加快访问速度、以及以这种方式存储的文件内容是无法改变的。
+
+无法更改文件内容相比我们所得到的好处来说似乎是一个相当昂贵的代价，但是就像计算机科学中的任何其他问题一样，这可以通过添加抽象层来解决。解决这一问题的IPNS（星际域名系统）利用公钥加密来创建可以指向不同文件的不可变地址。IPNS地址基本上就是某个公钥的哈希值。一次IPNS查找包括取回公钥本身、搜索具有相应的私钥签名的指针文件（一个包含IPFS地址的文件）、辨认最新的指针文件、以及重定向到正确的地址几个步骤。要利用IPNS，用户首先要创建一个公私钥对，然后将公钥、想分享的文件和带有签名的指针文件上传到IPFS上。当需要更新时，用户只需要签署并上传新的指针文件就可以了。
+
+IPFS的不少方面都可以在过去的项目中看到踪影，例如BitTorrent（P2P共享）、Plan 9下的[[https://zh.wikipedia.org/zh-cn/Fossil_(%25E6%25AA%2594%25E6%25A1%2588%25E7%25B3%25BB%25E7%25B5%25B1)][Fossil]]和[[https://en.wikipedia.org/wiki/Venti][Venti]]（一次写入的数据块和路径重定向）、和git（哈希树/有向无环图）。但是，IPFS的杀手级功能在于其与现有架构集成的便捷程度。专用的HTTP网关允许从浏览器（而不是IPFS客户端）中直接访问IPFS或IPNS地址，而且IPFS还具有与FUSE（用户空间中的文件系统）的兼容性，这意味着我们甚至可以将整个IPFS挂载为一个只读分区：这一兼容性也让我们能够托管静态网站，但是我必须承认，访问全球（甚至星际）规模的P2P共享盘是个明显更酷的用法。
+
+*** 在 IPFS 上架设静态网站
+[[https://docs-beta.ipfs.io/how-to/command-line-quick-start/][官方指南]]已经很好地概述了使用方法。以下是简要概括：
+- 运行=ipfs init=和=ipfs daemon=初始化并启动IPFS守护进程。
+- 生成网站文件并运行=ipfs add -r <网站文件路径>=将其内容发送到IPFS。输出的最后几行会有路径根目录的哈希值。
+- 如果要使用IPNS，请运行=ipfs name publish <网站根目录哈希>=以将IPNS链接定向到刚刚上传的文件夹上。IPNS公钥的哈希值可以通过=ipfs key list -l=获得。
+- 在更新或重建网站文件时重复以上两个步骤。由于IPFS寻址过程固有的数据去重功能，该过程的实际开销并不大。对静态站点这一用例来说非常合适：越大的文件（例如照片）更新频率就越低。
+
+完成此操作后，我们就可以从任何专用HTTP网关使用=<网关地址>/ipfs/<网站根目录哈希>=或=<网关地址>/ipns/<ipns地址>=来访问刚才上传的网站了：我们可以使用由IPFS守护进程启动的本地网关（通常位于=127.0.0.1:8080=），也可以使用[[https://ipfs.github.io/public-gateway-checker/][公共网关]]（由于IPFS文件取回需要在运行网关的服务器上进行，因此使用公共网关有遭受来自服务器所有者的中间人攻击的额外风险）。如果想要架设多个网站，则可以使用=ipns key gen=来生成更多IPNS密钥对，并在执行=ipfs name publish=时通过=--key=选项指定发布地址。
+
+在IPFS[[https://github.com/ipfs/go-ipfs/issues/4240][支持IPNS密钥的导入/导出]]之前（这有助于我们备份密钥并从多台设备发布内容），[[https://docs.ipfs.io/guides/concepts/dnslink/][DNSLink]]可用于更方便地维护到站点的网关，但代价是需要拥有域名并信任DNS服务提供者。要想通过 =/ipns/<域名>= 从HTTP网关访问站点，只需为域名加入一下TXT记录：
+#+begin_example
+ dnslink=/ipfs/<网站根目录哈希>
+#+end_example
+或
+#+begin_example
+ dnslink=/ipns/<ipns地址>
+#+end_example
+例如本站就可以通过[[https://ipfs.io/ipns/shimmy1996.com/][=/ipns/shimmy1996.com=]]（该链接使用ipfs.io架设的公共网关）来访问。虽然算不上是一个完全没有缺点的办法，但对我来说这是个合理的妥协。
+
+对了，还需要注意的是，正如同使用任何脱机HTML文件时一样，我们需要在生成的网页中使用相对链接。在Hugo中，这可以通过在=config.toml=中加入
+#+BEGIN_SRC toml
+ relativeURLs = true
+#+END_SRC
+来实现。
+
+当然，作为一个P2P网络，IPFS无法取回已经不存在于任何节点上的文件。默认情况下，IPFS客户端会[[https://docs.ipfs.io/guides/concepts/pinning/][固定]]从本地计算机共享的任何内容：固定内容不会被删除，这确保IPFS上至少有一个可用的副本。我们可以取消固定网站的过时版本，或者，如果需要，在多台设备上查找并固定网站地址以防万一。
+
+*** 繁星若尘
+回到IndieWeb的问题上：越来越黑的域名系统和链接失效使基于HTTP的URI的稳定性难以保证。但是，如果我们使用IPFS或IPNS地址作为URI呢？简直完美！我们通过由数学而非FBI警告所控制的地址获得了（理论上可以永久持续下去的）对静态网页的稳定分布式访问。消除拥有服务器的需要还降低了拥有个人网站的门槛。HTTP协议已经存在了29年，而IPFS仅存在了5年。我不知道IPFS在接下来的24年中是否还会继续存在，但是如果是的话，我希望我们会看到一个或许更加混乱，但更加健壮、充满活力、多彩的在线世界。
* TODO Specmania
:PROPERTIES: