加入 IndieWeb 所学到的东西

出于好奇，我决定探究一些博客和Mastodon帖子里反复出现的IndieWeb标签究竟是什么。很快我发现，它绝非空洞的概念，也不是对90年代互联网的怀旧情结，而是一套有着明确理念、协议和活跃社群的运动！随着我深入阅读他们的维基百科，我愈发理解其立场与方案的精妙之处。我对此热情高涨，决定采纳那些适合我网站的协议。经过测试和调整后，我可以肯定这段体验非常积极：我学到了很多知识，网站的用户体验（UX）也有所提升，整个过程充满乐趣。

因此，我整理了过去几个月的笔记，写下这篇文章。希望它能帮助更多人了解IndieWeb，同时让互联网生态更健康。另外，我也会分享自己具体实现了哪些功能、放弃了哪些以及原因，还有哪些建议最实用。

但首先，我们需要回答一个核心问题。

什么是IndieWeb

IndieWeb自称为“以用户为核心的商业互联网替代方案”。它不提供软件或框架，而是一套思想基础，主动接纳多元的方法和项目。正如其主页所言：“我们以人为本，而非以项目为本”。

IndieWeb起源于2010年，当时Aaron Parecki和Tantek Çelik参加了在波特兰举办的联邦社交网络峰会。他们意识到，行业需要一种不同的思路：少些协议，多关注内容创作者。2011年，第一届IndieWebCamp在波特兰举办，此后每年全球各地都会举办此类活动，同时还有Homebrew Website Club——人们聚在一起优化个人网站的线下聚会。

IndieWeb的三大支柱是：

内容归你所有：你在网上发布的内容属于你，而非某家企业。太多公司倒闭时，用户的数据也随之消失。
互联互通更自由：你的文章可以分发到任意平台，而非局限于某一个；其他平台的评论、点赞等互动也能同步回你的网站，让你在一处就能管理所有内容。
控制权在你手中：你可以按任意格式发布任何内容，且拥有永久有效的可读URL。

简言之，IndieWeb是一群认同上述理念的个人独立网站组成的社群。

这也解释了为何它不禁止使用社交网络，但坚决反对“围墙花园”模式。

敌人有个名字：信息孤岛

IndieWeb的整套术语体系都围绕一个对立概念构建：信息孤岛（silo），也叫围墙花园。其维基百科定义为：由营利性企业拥有的中心化网站，主张对用户贡献的内容拥有部分权利，并通过某种方式限制访问。它的特征包括：

要求用户创建特定于该网站的账号才能参与互动
仅允许用户与同一网站内的其他账号互动
通常还会附加：限制性服务条款、对用户在平台内创作内容的版权主张、阻止搜索引擎抓取的壁垒，或限制内容导入导出的障碍

为什么这是个问题？因为信息孤岛会消亡，而它们消亡时会带走你的内容。网站消亡列表页面（副标题为“精彩旅程的终点”，调侃企业常用的委婉语“我们的精彩旅程”）记录了一串令人痛心的事件：

GeoCities：雅虎于2009年10月26日关闭该服务，2300万网页就此消失。
MySpace：2019年服务器迁移期间，丢失了运营前12年上传的所有音乐，涉及1400万艺术家的5000多万首歌曲。
Google+：2019年4月关闭。
Posterous、FriendFeed、Vine、Yahoo Groups、TinyLetter、Cohost……名单还在不断变长，甚至设有“即将关闭”和“被收购”板块——收购往往是关闭的前兆。

信息孤岛甚至不需要消亡，互联网本身就天生脆弱。根据皮尤研究中心2024年的一项研究，2013年存在的网页中，有38%在十年后已无法访问。

IndieWeb的结论不是“不要使用社交网络”，而是更灵活的方案：你可以用任何平台，但要确保内容的权威版本存储在你自己控制的域名下。

为此，它制定了一系列原则，对抗网络的脆弱性。

核心原则

社群遵循11项原则：

数据归你所有：你的内容、元数据和身份信息都存储在自己的域名下，且你能长期访问它们。
使用并发布可见数据：优先面向人类，其次才是机器。如果HTML本身就能承载数据，就无需额外开发API。
按需构建：为自己开发工具，而非假想中的用户。“如果为假想用户设计，他们可能根本不存在；为自己开发，你自己就是真实存在的用户。”
自用自研工具：每天都使用自己开发的工具。“如果你自己都不依赖它，凭什么指望别人用？”
记录你的成果：你已经有表达想法的平台，用它记录你的开发流程、创意和代码。这既能帮助他人，也能帮到未来的自己。
开源你的成果：非强制要求，但能帮助他人更快加入独立网络。
体验优先于协议：先关注用户体验，再选择最简单、最精简的协议来支撑，绝不画蛇添足。他们将此总结为“先做体验，再搞底层”。
模块化设计：打造小巧、松散耦合的组件，避免依赖特定设备、语言或平台。
追求长期存续：为“持久互联网”而构建。“人类社会能保存古代纸莎草文献、维多利亚时代的照片和恐龙化石，我们也应该能打造无需以进步之名每隔几年就推翻一切的网络技术。”
倡导多元性：主动鼓励多样化的实现方式，让社群比单一模式更具韧性。
最重要的是，享受过程：回忆一下90年代的互联网、GeoCities网站、花哨的背景和动态GIF图。“它可能丑陋、代码糟糕，但充满乐趣。让互联网保持独特和有趣。”

这些原则的编号仅作参考，无优先级之分。社群不要求你全部遵守，但希望你将它们铭记于心。

但IndieWeb并非只有原则，它还制定了一系列标准，让网站更开放、更具互操作性，也更不易消失。

技术实现细节

IndieWeb不发明新平台，而是定义了一组可相互组合的小型标准。官方索引按诞生时间和普及程度对它们进行排序。

我们逐一介绍：

起点：你的域名

这不是协议，却是一切的前提：将你自己的域名作为在线身份的核心标识。这是入门指南的第一步，也是社群认定“加入IndieWeb”的最低要求。哪怕未来你更换主机或内容管理系统（CMS），只要保留域名，所有链接、读者和搜索排名都能保留。

microformats2：用HTML当API

microformats2解决了一个问题：无需发布额外文件或开发API，就能让内容被机器读取。

它的实现方式十分巧妙——只需在现有HTML中添加CSS类。前缀代表数据类型：h-*表示根元素，p-*表示纯文本，u-*表示URL，dt-*表示日期，e-*表示嵌入的HTML。两个核心词汇是：

h-card代表你的身份，相当于线上名片。只需在主页上添加姓名、URL和照片，读者就能在你的帖子旁显示你的个人资料，应用程序也能识别你。它就像基于域名的Gravatar头像服务，而非基于邮箱：

<a class="h-card" href="https://example.com">
<img src="/photo.png" alt="" />
Jane Doe
</a>

h-entry是内容单元，即单条帖子的标记。维基百科称它为“IndieWeb的核心构建模块”：

<article class="h-entry">
<h1 class="p-name">Article title</h1>
<p>By <a class="p-author h-card" href="https://example.com">Jane Doe</a>,
<time class="dt-published" datetime="2026-07-19">July 19, 2026</time></p>
<div class="e-content">
<p>The post content...</p>
</div>
</article>

还有h-feed，它可以将多个h-entry元素组合起来，让你的列表页变成可直接从HTML订阅的信息流。

维基百科里有一句我很喜欢的总结：你的网站就是你的API

读取内容用microformats，发布内容用Micropub（我们稍后介绍）。

rel="me"：无需中央机构的身份验证

rel-me是最简单的标准，效果却立竿见影。它是链接上的一个属性，意思是“此链接指向的页面与当前页面属于同一人”： <a href="https://mastodon.social/@jane" rel="me">Mastodon</a> 验证需要双向确认：你的网站链接到社交平台个人主页，同时个人主页也要链接回你的网站，且两处链接都带有rel="me"属性。这样就能实现分布式身份验证，无需任何中央机构参与。这正是Mastodon绿色认证标识背后的机制：如果你的页面和Mastodon主页互相添加了rel-me链接，Mastodon就会显示你的域名已认证。Threads、PixelFed、GitHub、Keybase和维基百科也支持这一机制。

在rel-me之上还有RelMeAuth：用个人URL登录其他服务，将身份验证委托给你的主页所链接的OAuth提供商（如GitHub）。它是IndieLogin等服务的基础。

Webmention：网站间的对话

Webmention是核心标准，自2017年1月12日起成为W3C推荐标准，是Pingback的现代替代方案。它解决了网站间的对话问题：无需第三方平台，就能实现跨网站的评论、点赞、回复和转发。很多人用它替代Disqus评论系统。

流程设计得非常简洁：

我写了一篇文章，其中链接到你的一篇文章。
我的服务器访问你的文章，查找你的接收端点：可能是HTTP头中的Link: <...>; rel="webmention"，也可能是HTML中的<link rel="webmention">标签。
我的服务器发送一个POST请求，只包含两个参数：source（我的文章链接）和target（你的文章链接）。

POST /webmention HTTP/1.1
Host: your-site.com
Content-Type: application/x-www-form-urlencoded
source=https://my-site.com/my-post&target=https://your-site.com/your-article

你的服务器验证这条提及：根据规范，需要下载source页面，确认其中确实包含指向target的链接。没有这一步验证，任何人都能伪造提及。
验证通过后，你的网站可以自行决定如何处理这条互动。这时microformats就派上用场了：通过解析来源页面的h-entry，可以判断它是回复（u-in-reply-to）、点赞（u-like-of）还是转发（u-repost-of），而作者的h-card则能让你像在普通评论区一样显示其姓名和头像。

如果你觉得这像一个社交网络，那没错！每个网站都是网络中的一个节点，节点间的链接构成社交图谱。

这个系统并非完美，它和所有去中心化网络一样存在问题，因此出现了一些针对其弱点的扩展：

它无法完全避免垃圾信息，也离不开内容审核，但确实是构建分布式评论系统的良好基础。

如果你的网站没有后端怎么办？没关系：webmention.io可以代你接收Webmention。只需在HTML中添加一个指向该服务的<link>标签，它就会提供一个API供你查询和展示收到的互动。这正是Hugo、Jekyll或Eleventy等静态网站生成器用户所需的工具。

IndieAuth：用域名登录

IndieAuth回答了一个问题：如果登录身份不是“谷歌上的你”或“脸书上的你”，而是你的URL，会怎么样？从技术上讲，它基于OAuth 2.0这一身份验证与授权标准。用户和应用都通过URL标识，无需预先注册客户端（“IndieAuth用DNS替代客户端注册”），且强制使用PKCE（一种防止攻击者窃取访问令牌的安全机制）。

流程大致如下：你在登录表单中输入域名，服务端获取你的页面，通过rel="indieauth-metadata"发现你的授权服务器，将你重定向到那里；你通过任意方式完成验证（密码、邮箱、RelMeAuth等），服务端就会收到你控制该域名的确认信息。这是一个成熟的标准，社群认为其已稳定。

Micropub：用任意客户端发布内容

Micropub自2017年5月起成为W3C推荐标准，它将发布界面与网站软件分离：任何应用（网页端、iOS、Android）都能在你的域名下创建、编辑和删除帖子。它取代了旧的MetaWeblog和AtomPub协议——后者需要共享密码，而Micropub使用通过IndieAuth获取的OAuth令牌。

它的精妙之处在于词汇体系：不发明新词汇，而是沿用microformats的序列化格式。创建帖子只需发送一个包含h=entry和h-entry属性的POST请求：

curl https://your-site.com/micropub \
-d h=entry \
-d "content=Hello world" \
-H "Authorization: Bearer XXXXXXX"

如果你习惯使用REST API，会觉得这非常自然。

WebSub：实时信息流

WebSub前身为PubSubHubbub，自2018年1月起成为W3C推荐标准，它消除了信息流轮询：无需上千名读者每半小时向你的服务器询问是否有新内容，你发布新内容时只需通知一个中心节点（hub），该节点就会通过webhooks立即通知所有订阅者。这减轻了服务器负载，且更新能实时送达。

很多阅读器和聚合器都支持WebSub，比如Feedly和NewsBlur。

Microsub：解耦式阅读器

Microsub是最年轻的标准，目前仍处于草案阶段。可以把它看作将所有功能整合为社交阅读应用的基础设施。

它分为两层：服务器层负责底层工作（管理订阅、获取和解析信息流、标准化数据），客户端层仅负责渲染阅读界面。这样一来，客户端可以专注于用户体验竞争，而你的订阅信息可以在不同客户端间迁移。结合Micropub（在阅读器中回复）和Webmention（发送通知），就构成了IndieWeb“社交阅读器”的完整架构。

发布策略：POSSE、PESOS与反向同步

除了原则和协议，IndieWeb还提供了一套思维模式，让你既能使用社交网络，又不放弃对内容的控制权：

POSSE（Publish on your Own Site, Syndicate Elsewhere：先发布到自己的网站，再同步到其他平台）：先在自己的网站发布内容，再将副本推送到各个社交平台，每个副本都附带指向原链接的跳转。这是推荐的做法。你的朋友可以继续在熟悉的平台上关注你，而你保留内容的权威版本；哪怕未来平台关闭或封禁你，你也不会有任何损失。这个术语由Tantek Çelik在2012年提出，从《Pluralistic》的作者科里·多克托罗到2024年重新推广它的莫莉·怀特，很多人都在践行。维基百科里有个有趣的细节：在副本中链接回原文，也是对抗抄袭者的“互联网合气道”——他们抄袭你的文章时，也会一并抄上注明你是作者的链接。

PESOS（Publish Elsewhere, Syndicate to your Own Site：先发布到其他平台，再同步到自己的网站）：与POSSE相反，先在信息孤岛平台发布内容，再将副本归档到自己的网站。维基百科坦诚了它的优势（平台应用体验非常完善，且可以异步发布：即使你的网站宕机，你仍能发布内容），但认为它逊于POSSE：从发布的第一秒起，你就要受平台条款约束，你的副本也不是权威版本，还会受限于平台的各种限制，比如字符数上限或链接被自动转为t.co短链接。

反向同步（Backfeed）：将平台上的互动反向同步回来。你的POSSE副本在社交平台收到的点赞、回复和转发，会以Webmention的形式同步回你的原帖。这样一来，完整的对话都会归档在你的域名下，不会因平台关闭而丢失。代表性服务是Bridgy：它监控你在Mastodon、GitHub、Flickr、Reddit或Bluesky上的副本，每收到一次互动就向你的网站发送一条Webmention。

简言之：先在自己的网站发布内容，再同步到各个平台并附带回链，然后将平台上的互动反向同步回原帖，转为Webmention。

与联邦宇宙、RSS等的关系

可能会让你惊讶的是，IndieWeb并非与联邦宇宙（Fediverse）隔绝。有趣的是：Webmention、Micropub和WebSub等协议都出自同一个组织——W3C社交网络工作组。该工作组还开发了著名的ActivityPub协议，也就是联邦宇宙的基础。它们算是“表亲”，只是遵循不同的理念。

联邦宇宙以服务器为单位进行联邦：你的身份是@用户@服务器实例，如果你不自己运行服务器，就必须依赖他人的实例。维基百科直言不讳：加入Mastodon实例，相当于“从一个信息孤岛，转移到一个可能更开源、更支持开放标准的信息孤岛，但仍依赖另一个中心化组织”，还得承担“管理税”——维护和审核服务器的高昂成本。而IndieWeb以网站为单位进行联邦：你的身份是你的域名，联邦只是众多传播渠道之一。

不过两者并非互斥。Bridgy Fed是一座桥梁，可以将你的h-card、h-entry和Webmention转换为ActivityPub（以及Bluesky的AT协议），反之亦然。这样一来，你的域名就变成了@example.com@example.com形式的联邦宇宙账号，人们可以在Mastodon上找到并关注你，而回复会通过反向同步回到你的原帖。Mastodon能识别你的个人资料和帖子都存储在你的网站上。

而RSS/Atom信息流则是另一回事，IndieWeb认为它们存在结构性问题。核心依据是DRY原则（Don't Repeat Yourself，不要重复造轮子）：内容已经存在于HTML中，维护一份并行的XML副本是“维护税”——需要单独的代码路径，容易出现内容不一致，体积更大（有些Atom文件的大小是对应HTML的4.5倍），且人类点击信息流链接时体验很差。他们的替代方案是h-feed：直接将HTML本身作为信息流。但正如常有的情况，技术上更优并不意味着会被广泛接受。他们也承认，很少有阅读器支持microformats。因此，他们建议在IndieWeb社群内使用h-feed，面向其他用户则仍使用RSS/Atom。

如何入门

入门指南推荐按以下步骤操作：

注册域名，并将其作为你的核心在线身份。他们给出一个具体建议：可以考虑注册商的Whois隐私保护服务，但前提是你完全信任服务商——如果Whois信息中不显示你是合法所有者，未来的域名所有权纠纷会变得很复杂。
搭建主机：新手可以选择托管服务（他们提到了GitHub Pages、Netlify、Neocities等），有经验的用户可以自行托管。
创建页面：可以用静态网站生成器、手写HTML或内容管理系统，都没关系。IndieWeb没有官方指定技术，这是刻意为之（体现多元性原则）。
同步到其他平台（POSSE），并附带回链指向原内容。
添加microformats：在主页添加指向个人资料的rel="me"链接，在帖子中添加h-entry标记。
验证成果：使用IndieWebify.me，它会逐步检查你的rel-me、h-card和h-entry是否正确。
加入社群：分享你搭建的内容，哪怕只是一个单页网站，并在维基百科上记录下来，帮助后来者。

对于希望循序渐进的人，还有IndieMark——一套分级体系，为开发者提供指引。

我实现的功能（以及放弃的功能）

开头我承诺会分享自己实现了哪些功能、放弃了哪些以及原因，以下是具体清单：

✅ Webmention：支持发送和接收。发送功能通过每日任务自动完成，新文章发布24小时后（留出时间修正错别字），会通知文章中链接的外部网站。接收功能用于在每篇文章末尾显示引用列表。不过我将它与评论系统分开，评论仍通过邮件管理。
✅ 所有文章都添加了h-entry标记，主页添加了h-card标记，并通过mf2py验证无误。
✅ 页脚添加了指向Mastodon、GitHub和Org Social的**rel="me"**链接，已获得对应的绿色认证标识。
❌ Micropub和IndieAuth：主动放弃。我的发布流程是编辑器加Git，文章以Markdown格式版本化存储，发布端点对我毫无用处。
❌ WebSub：评估后放弃。我的发布流程刻意延迟24小时，“实时更新”不足以证明引入复杂度的合理性。
❌ h-feed：我的文章卡片会在其他场景复用（比如文章内的推荐内容），添加标记会导致解析器识别出模糊的h-entry。如果我一开始就针对这个结构设计模板，情况会不同。目前RSS已经能很好地满足需求。

不过对我帮助最大的并非技术建议，而是关于理念和网页设计伦理的内容。这些散落在维基百科中的建议价值千金，无论是否加入IndieWeb都值得借鉴。我的精选如下：

纯HTML是最耐用的格式：无需JavaScript就能浏览整个互联网。
可靠的URI永不改变：设计可以永久维护的永久链接。比如，我可以修改文章的slug，但旧链接依然有效。
逐步投入，逐个平台迁移：无需一次性逃离所有平台。每一种先发布到自己网站的内容，都是迈向数据自主的一步。
考虑极端长期存续性：维基百科认真讨论了你去世后网站的处理方案，从“死亡开关”（将控制权交给你信任的人），到彼得·莫尔纳总结的实际问题：“如果你不在了，谁来为你的域名续费？”

还有……享受过程。一个不完美、充满个性的个人网站，比一个你维护得索然无味的完美模板更有价值。