关于 AstraHub 星链插件的使用文档与一些不得不说的话 —— 数据来源、设计取舍、为什么不是"多此一举"，以及在被频繁质疑之后的一点回应，这是一篇关于AstraHub 星链插件的使用文档，也是一封写给所有关心独立博客生态的朋友的"自我介绍"。它既写给愿意来一起看看的朋友，也写给目前还有一些疑问、暂时不太理解这件事的同学。前半部分主要把概念、数据来源和一些被多次问到的问题讲清楚，后半部分会手把手介绍怎么安装、怎么使用、怎么反馈问题。

一、写在前面：为什么先把"概述"写一写

按惯例，使用文档应该开门见山讲怎么用。这次我决定反过来，先聊一聊背景、数据来源以及最近被问得比较多的几个问题。

原因很朴素 —— 信任比功能更重要。

插件上架到 Halo 应用市场那天还挺顺利，从上传到 GitHub 到通过审核，整个流程不到一个小时。但上线之后没多久，就陆续收到一些朋友的疑问：

  • "你这插件展示的数据怎么和我用的 XX 插件看起来差不多？"

  • "RSS 那一块，你聚合的是不是 XX 插件里的数据？"

  • "Halo 自己已经有'链接管理'了，再做一个友链插件会不会有点重复？"

这些问题都很合理。有的是因为概念相近容易让人产生联想，有的是站位不同看待这件事的角度自然不一样，也有的就是单纯不太需要、觉得没必要 —— 这些感受我都能理解。但如果不在文档里讲清楚，每次都要从头解释一遍，对真心想了解的朋友也是一种打扰。

所以这一节会写得稍微长一点，麻烦你耐心看一下。后面还有完整的使用步骤、安装路径和配置说明等着你。

1.1 做这件事的初衷

很多事情之所以会做，往往不是因为"觉得这玩意儿酷"，而是被生活反复在同一个地方碰到了几次。AstraHub 也是。下面这几件事，是我个人比较有感触的几个点：

  • "自己写的内容，回头自己也不太容易翻到"。早些年我在一些内容站点上认认真真写技术文章，写到后来发现：相当一部分文章被加上了"VIP 才能看 / 充值解锁 / 关注公众号回复关键字"这一类门槛，有时候自己想回头翻一翻自己当年写的那些字，也得先开个会员。这种感受其实挺微妙的，我能理解平台需要变现，但也希望好的内容尽量能不被门槛挡住。

  • "独立博客越来越不容易被搜到"。哪怕你认真写、坚持写、域名也很干净，新站冷启动的曝光仍然非常有限，老站的搜索权重也在持续被稀释。在这种环境里，独立博客如果没有一张"圈内可见的网"，很容易就只剩下偶尔被路过的可能。

  • "换友链太靠人肉"。想加一条友链？得去对方的 about / links 页找格式要求，按规范填好，发邮件 / 留评论 / 提表单，等对方有空、看到了、记得审核，再回信叫你加上他；之后你再回到自己博客把对方加上 —— 一来一回，几天就过去了。这一套流程到 2026 年还在被独立博主每天重复，是不是可以稍微轻松一点？

  • "建站很容易，被发现很难"。Halo / Hexo / Hugo / WordPress 把"建一个独立博客"压缩到了几分钟搞定。但建好之后，新博主写两三篇没什么反馈，很容易就放下了。独立博客圈每年都在因此流失一些"本来可能写得很好的人"，挺可惜的。

AstraHub 就是想顺着这几件事做一点点尝试：

让独立博客的内容尽量不被门槛挡住、让站点之间的友链关系自然浮现出来、让换友链像加好友一样轻松、让一个新博主登舱当天就有机会被同主题的圈子看见。

它不是又一个友链插件，也不是又一个 RSS 聚合器。它想做的是 独立博客生态里的"发现层"和"握手层"。如果它最终能让哪怕几个原本会放下笔的好作者被看见、留下来继续写，那就值了。

二、AstraHub 是什么：先把概念讲明白

AstraHub（中文叫"星链"）做的事情，可以用一句话概括：

把分散在不同独立博客上的"友链关系"和"对外公开的内容动态"组织起来，形成一张全网可见、可检索、可探索的博客关系图谱。

这句话里有两个关键词："全网" 和 "图谱"。

它 不是另一个友链管理插件。

Halo 自带的"链接管理"做的是单站点视角的事：维护我这个站有哪些友链。它的边界天然就在自己这一亩三分地。这套设计本身没有任何问题，绝大多数博客系统都是这样工作的 —— 一个站点关心自己显示什么。

AstraHub 的视角恰好是另一个尺度。它关心的是 当几十个、几百个独立博客站点都接入之后，它们之间的连接结构会长什么样：谁和谁互链了？哪些站点处在网络的中心？哪些圈子是天然抱团的？哪些博主气质相近但还没有发现彼此？

这两件事不是同一个问题，也不在同一个维度上。一个是"我这个站点的内务管理"，另一个是"独立博客作为一个群体的关系网络"。AstraHub 想做的是后者，和前者并不冲突。

2.1 加入网络后，站长能拿到什么

光有一个抽象的"网络层"还不算服务。这里把"接入之后你具体能用上哪些能力"列一下，方便你按需对照、决定要不要加入（这些都是登舱后才会启用的能力，不登舱就不会动用）：

  • 在线交换友链，不再跑场

在 hub 里看到喜欢的博客，点「申请友链」，对方在自己 Halo 后台一键审核，双向友链同步生效。整个过程往往不到 1 分钟，省去了到处找入口、填表单、等回邮件的环节。

  • 全网 RSS 资讯流（深空资讯）

hub 持续聚合所有已登舱节点和部分主动上报的开放 RSS 源，给你一个统一的"全网最近更新"视图。可以按主题、按节点、按时间筛选，不用自己去维护一个 RSS 阅读器、手动加几十个源。

  • 关系图谱可视化

3D / 2D 双视图，把站点之间的友链与圈层关系直观呈现出来。你能一眼看清自己处在网络的哪个位置，哪些博主和你属于同一个圈、哪些节点处在网络枢纽。

  • 圈层归属与同主题发现

系统会根据站点信息和内容标签自动把你归入对应的圈层（星团），同圈层博主彼此可见、相互发现，效率比手动逛友链页轻松很多。

  • 节点详情页 + 影响力分

每个登舱站点都有一个公开的节点详情页，列出它的友链拓扑、最近文章、所属圈层、影响力评分。相当于给你的博客在"独立博客名册"里挂了一个长期可访问的档案页。

  • 迁移无忧（重新登舱）

换服务器、换域名也不会丢节点身份。在新站点上重新登舱，原有的友链关系、圈层归属、节点 ID 都会保留，老朋友不会因为你搬家就联系不上你。

  • 主题嵌入小组件（零接入）

自带 galaxy-link-widget 前端组件，由 Halo 主题渲染时自动注入到 <head>，主题作者无需写任何 HTML、不必 import 任何 JS、也不用改主题源码。只要你已登舱并开启「挂件开关」，组件就会在站点右下角浮一个吉祥物 + 圈友卡片。它只读取你已登舱的圈友数据，不会强加额外 UI。

  • 完全免费 + 开源

插件 AGPL-3.0 开源（仓库见文末）。hub 服务端目前由作者本人维护，暂时没有公开仓库。

简单说，你贡献的是已经手动维护好的友链元数据；同时拿到的是一整套独立博客生态的"发现层"能力。这是一种"加入即放大"的协作 —— 越多人加入，每个人的发现效率和被看见概率就越高。

三、关于"数据怎么和我的一样"：把数据来源讲清楚

这是被问得最多的一类问题，我想认真讲一下，毕竟这关系到大家对插件的信任。

3.1 关系图谱的数据从哪里来

AstraHub 关系图谱里展示的"友链"，完全来自每一位站长本人显式同意、主动登舱后由插件上报的友链数据。

具体流程是：

  1. 你在 Halo 站点里安装 AstraHub 插件。仅仅是安装本身不会上传任何数据。

  2. 进入插件设置面板，第一次接入会弹出「数据上报与隐私须知」，需要你亲手勾选同意这份说明（和应用市场常见的 EULA 一样），同意之前所有上报接口都是关闭的。

  3. 同意之后，再去填写站点信息、点击「登舱」按钮 —— 这才是真正"加入网络"的动作。

  4. 登舱时插件会读取你自己手动维护的那一份友链列表，加上签名后上报到 hub。

  5. hub 把这份"你站点的友链"和其他已经登舱站点的友链做交叉匹配。只有当两个站点互相在链接管理里都加了对方时，这条边才会在图谱中建立，单向友链不会自动连出。

也就是说：

  • 没有抓取任何站点的数据库；没有爬友链页面；不会用任何不告而取的方式拿到友链。

  • 图谱里展示的信息，都是经过站长同意、由插件主动上报的。

  • 上报的也仅仅是友链元数据（站点名、URL、头像、可选的 RSS 地址），不会上传你已经订阅的 RSS 数据、文章正文、评论、用户、配置项、密钥等任何私有数据。

如果你看到一条边和你站点上的友链一致 —— 那是因为它的来源就是你自己已经公开的友链数据，对方也把你加为了友链，于是匹配到了，画了一条线。这是 设计上的预期结果，并不是数据泄露。

如果暂时不想参与，也很简单：

  • 完全不想用：不安装这个插件，或者安装后不去同意那份须知，整个上报链路从头到尾都是关闭的，hub 不会知道你存在。

整个链路里没有任何"必须接入 / 不接入就不能用 Halo"的逻辑。同意是显式的，加入也是显式的。

3.2 RSS 聚合的数据从哪里来

第二类问题集中在"深空资讯"。也有同学会问："你聚合的是不是 XX 插件里的数据？"

这里需要先把概念稍微厘清一下。RSS 聚合和友链是两件不同的事：

  • 友链关心的是"谁链向了谁"，是关系结构，是一张"图"。

  • RSS 聚合关心的是"这一群站点最近发了什么"，是内容流，是服务端自己去解析公开 RSS 拿到的，和某个具体的 XX 插件没有直接关系。

AstraHub 的 RSS 聚合，订阅的是 所有已登舱节点 + 部分主动上报的开放 RSS 源 的更新。它的目的不是替你管理你的友链 RSS，而是给整个网络的访问者一个"今天独立博客圈又有什么好文章"的入口。

如果你恰好在 Halo 链接管理里把某个站点加为友链，而那个站点又登舱了网络，那它确实会同时出现在两个地方 —— 你 Halo 自己的友链页（因为你加了它）、AstraHub 的全网资讯流（因为它本身在网络里）。两份数据看起来重叠，但来源、用途、生命周期完全不同。

四、关于"是不是多此一举"这个看法

把上面两件事讲清楚之后，剩下更多就是认知差异的部分了。

有同学会问："Halo 自己有链接管理啊，再做一个友链插件是不是有点重复？"

我的看法是这样：

Halo 关心的是你这一个站点的事，AstraHub 关心的是几百个独立博客作为一个整体会发生什么。这两件事不是相互替代的关系，而是两个不同尺度的问题。

Halo 是工具，AstraHub 是网络。

工具好不好，看它单点效率高不高、能不能让一个站长把自己这一摊事管好。

网络好不好，看接入的人多不多、连接质量高不高、能不能让博主之间互相被看见。

这两类问题需要不同的产品形态去承担。打个比方 —— 一个 GitHub 仓库本身没法直接撑起整个"开源生态"，仓库只是工具，生态还需要 npm、Maven Central、应用市场、issue tracker、CI 等等围着它一起长出来。独立博客生态也是一样：Halo 这样的博客内核解决了"建博客"的问题，但"博客之间如何被发现、被连接、被聚合"这一层，长期是缺位的。

我们看到的现状是：

  • 每个博主自己跑去对方站点找入口、填友链表单、等审核、等回邮件。

  • 找类似主题的博友只能靠"友链的友链的友链"，一个一个翻。

  • 一个独立博客如果不主动跑场，几乎只能靠搜索引擎和零星的转发被偶然遇到。

这并不是 Halo 的问题。Halo 把"站点"这件事做得已经非常出色。但站点和站点之间的连接结构，本来就不应该由一个"站内插件"来承担，它需要一个 跨站点的网络层 来配合。

AstraHub 做的就是这一层。

4.1 站位不同，看法不同

我也完全能理解为什么有人会觉得这件事好像没什么必要。如果你的视角始终是"我自己这一个站怎么用 Halo 用得更顺手"，那你确实不一定需要 AstraHub —— Halo 本身已经够好了。

但如果你的视角是"独立博客这个群体作为一个整体能不能更繁荣，能不能让更多新人不至于发完两篇就因为没人看而放弃"，那这件事或许就有它的价值。

价值不在于多了一个新插件，而在于这张"可见的关系网络"本身。当几百个站点能互相看到、当一个新博主登舱后能立刻被同主题的圈子发现、当一个十年老博主的友链拓扑能被完整呈现 —— 这些都不是单一站点视角能轻松做到的事。

它不打算替代 Halo，也不打算替代任何已有的友链页或友链插件。它只是想做一个 独立博客生态级别的发现层。喜欢就用，暂时不需要也完全没问题。

4.2 也有一些做得不够好的地方

我想坦诚说一下，这件事在做的过程中确实有几个地方不够细致：

  • 早期文档没把数据来源写得足够清楚，让有些朋友第一次在图谱里看到自己站的友链时会愣一下，这是我们的问题。

  • "全网图谱"这个词的表述，对一些只想安静运营自己博客的朋友来说，确实容易让人误以为是某种入侵感，这种感受也是真实存在的，我们会继续打磨表述。

这些地方我们能改的会一直改。至于"做这件事本身有没有意义" —— 我的答案是：还是值得试一试。

独立博客生态这十几年里，我个人感觉最大的瓶颈从来不是工具不够好，而是人和人之间的连接不够通畅。Halo、Hexo、WordPress、Hugo、Typecho 这些工具都把建站做到了几分钟搞定的程度，但建好之后，大多数博主还是孤岛。RSS 聚合器、个人导航、博客圈手动维护的列表，每一代都有人在这个方向上做尝试。

我不敢说 AstraHub 一定能成。但既然现在还有人愿意写、愿意读，这件事就还值得试。

五、和 Halo 官方插件的关系

为了把这件事讲得更具体，我对照了几个 Halo 官方应用市场里和"友链"或"内容聚合"相关的插件，做了一个简单的位置对比。

插件

解决的问题

数据范围

和 AstraHub 的关系

官方 链接管理

维护本站点的友链列表

单站点

AstraHub 读取它作为登舱依据和友链数据来源

友链鱼塘 / 友链朋友圈类插件

聚合本站友链的最近文章

单站点的友链范围

视角不同，AstraHub 是全网范围的 RSS 数据聚合且数据也不来源它，一切为AstraHub自动解析

评论插件、文章订阅类插件

站点内部互动

单站点

没有直接关系

AstraHub 星链

让独立博客作为一个群体被看见、被连接、被发现

全网（已登舱节点）

网络层，依赖前面这些工具但不替代它们

简而言之：AstraHub 是站在 Halo 之上的网络层，不是站在 Halo 之内和它的功能竞争。 没有 Halo 这样的优秀博客内核，就不会有今天这么多独立博主可以被聚合；同样地，如果没有一个跨站点的发现层，再好的博客内核也会让博主停留在自己的孤岛里。

这是一种合作关系，不是替代关系。希望未来有更多的同类项目出现，无论是基于 Halo、还是其他博客系统。生态从来不是靠一个项目撑起来的。

六、使用文档：从 0 到 1 的完整路径

讲完了价值观的部分，下面回到实用层面。这一节是给已经决定试一试的朋友看的。

6.1 系统要求

  • Halo>= 2.23.0

  • 网络：能正常访问外部 HTTPS 接口（与 hub 通信）

  • 空间：插件本身体积很小，不到 5MB

6.2 安装

方式一：Halo 应用市场（推荐）

  1. 进入 Halo 控制台 → 插件 → 应用市场。

  2. 在搜索框输入「AstraHub」或「星链」。

  3. 点击「安装」，等待应用市场把插件下载到你的 Halo。

  4. 安装完成后回到「已安装」列表，找到 AstraHub，点击「启用」。

方式二：手动上传 jar

如果你的 Halo 暂时无法访问应用市场，可以手动安装：

  1. 到 [GitHub Releases](https://github.com/atangccc/Astrahub/releases) 下载最新版本的 .jar 文件。

  2. 进入 Halo 控制台 → 插件 → 右上角「上传插件」。

  3. 选择刚才下载的 jar，等上传完成。

  4. 启用插件。

6.3 第一次登舱

启用插件后，进入 设置 → 星链接入配置。

第 1 步：先填写站点信息

按界面填写以下字段（注意：此时还没有任何数据上报，只是把信息暂存到本地配置）：

  • 站点名称：建议如实填写，会作为星球的名称。

  • 站点简介：建议如实填写，会作为关系图谱里你星系的描述。

  • 星链节点名：建议如实填写，会作为关系图谱里你星系的名称。

  • RSS 地址：建议如实填写，作为你的文章解析地址。

  • 联系邮箱：用于接收签发码、系统通知和「重新登舱」时的身份验证（必填）。

第 2 步：点击「接入星链」按钮，弹出说明 + 同意

填写好之后点击页面上的「接入星链」按钮。这一步还没有真正接入，会先弹出一个「接入星链」对话框，里面强制展示一份《星链接入与数据同步说明》。

这份说明的原文如下，请认真阅读：

一、接入后您将获得的能力

接入主星后，您的站点将加入"博客星球"创作者网络，与全网独立博主互联互通。本插件会把您站点已公开的内容定时同步至主星，帮助您：

  • 扩大曝光：站点与博文将出现在主星首页的"探索"与"信号流"中，被更多读者发现

  • 拓宽圈子：自动加入主题星系（按标签 / 分类 / 节点聚类），与同好建立连接

  • 互通友链：通过签发码邀请协议与其它接入站点一键建立友链，免去手工填写

  • 聚合发现：您的友链关系会被纳入图谱可视化，访客能从一个节点跳转探索整片星系

  • 实时播报：当您发布新文章或与其它节点产生互动时，主星会通过吉祥物气泡实时播报到您和好友的前台

二、同步至主星的数据范围

A. 站点公开内容（来自您已对外发布、公众可直接访问的内容）：

  • 站点元信息：站点名称、访问地址（URL）、节点标识与头像、RSS 订阅地址

  • 友情链接：友链分组配置、友链条目列表

  • 博文公开元数据：文章标题、永久链接、标签、分类、发布时间、内容摘要、正文内容

B. 联系邮箱（用于身份识别与系统通知）：

  • 您填写的联系邮箱会随接入凭据一并上传至主星，用于接收签发码、友链邀请、互动通知等系统消息

三、隐私与边界声明

A 类数据均来源于本站点已对外发布、可被公众直接访问的公开内容，不涉及任何非公开、受限或私密信息。

四、用途承诺

上述数据用于内容聚合发现、友链协议互通、关系图谱构建、消息通知投递等社区聚合服务，严格遵循公开、透明、合规的数据交互原则。

五、身份与控制权

接入凭据（站点 ID / 密钥）由主星签发并存储在本站点本地配置中，您可随时通过"重新登舱"恢复接入身份。

读完之后，勾选最下面那行：

我已阅读并同意《星链接入与数据同步说明》，授权本插件按上述范围将我的站点公开数据与联系邮箱同步至主星。

勾选之前，"发送签发码"和"确认"两个按钮都是禁用的，发不出任何请求。 这是设计层面的硬约束，不是文案承诺。

第 3 步：发送签发码 → 填入 → 确认接入

勾选同意后：

  1. 点击「发送签发码」，主星会把一张一次性签发码发到你刚才填的联系邮箱。

  2. 在你的邮箱里找到这封信，复制签发码（形如 bphub-A3F7B2C1）。

  3. 把签发码填回对话框里的输入框。

  4. 点击「确认」按钮。

主星接收并校验签发码后，会做以下几件事：

  1. 给你的站点生成一个唯一节点 ID 和接入密钥（密钥只保存在你本站点的本地配置中）。

  2. 按上面《说明》的范围把你的站点元信息、友链列表、博文公开元数据同步到主星。

  3. 你的节点会出现在网络的关系图谱里，加入对应圈层。

整个过程一般几十秒完成。只有走完这一步，才算真正"加入网络"。

6.4 日常使用

6.4.1 在网络里发现新博友

进入 hub 提供的探索页（默认入口在登舱后会显示在插件控制台里），你可以：

  • 看到所有已登舱站点的列表和它们的圈层归属。

  • 浏览 3D 关系图谱，直观看到谁和谁连得紧、谁站在中心位置。

  • 按标签、按内容主题筛选，找到与你气质相近的博主。

6.4.2 发起友链申请

看到喜欢的博客，点击它的卡片：

  1. 进入对方的节点详情页。

  2. 点击「申请友链」，写一段话介绍你自己（建议真诚一点）。

  3. 申请会被推送到对方的 Halo 控制台，对方在「友链互动」里看到你的申请。

  4. 对方点击「通过」后，hub 会自动建立双向友链关系，两边的链接管理都会同步更新（只要插件保持启用状态）。

整个换链过程，从你看到对方到双向友链生效，正常情况下不超过 1 分钟。

6.4.3 重新登舱（搬家场景）

  1. 如果你换了服务器、换了域名，但希望保留原来的节点身份和友链关系：

  2. 在新的 Halo 上安装并启用 AstraHub 插件。

  3. 进入 设置 → 星链接入配置 → 重新登舱。

  4. 输入你之前注册时使用的邮箱，hub 会发一封带验证码的邮件。

  5. 验证通过后，新站点会继承原有的节点 ID 和所有关系。

注意：重新登舱和首次登舱是两个独立入口。如果你只是想新建一个新博客，请走首次登舱。

6.4.4 主题嵌入：在博客侧边栏展示圈友（零接入）

插件附带一个轻量级前端组件 galaxy-link-widget，由插件在 Halo 主题渲染时自动注入到 <head>。只要满足两个条件，组件就会自动出现在你站点上：

  1. 你已经走完登舱流程linked = true）；

  2. 设置面板里的「挂件开关（widget.enabled）」是开启状态（默认开启）。

注入后，访客会在你站点右下角看到一个吉祥物 + 圈友卡片浮窗。主题作者完全不需要写任何 HTML、不需要 import 任何 JS、也不需要改主题源码，换主题也照常工作。

如果不想要这个浮窗，去后台关掉「挂件开关」即可，或者如 Q24 所说，用公开 API 自己拼一个挂在博客侧边栏。

6.5 常见问题

Q：我安装后没有接入会不会上报数据？

A：分两种情况：

  • 如果你从未勾过那份「数据上报与隐私须知」，插件根本没有发过任何上报，hub 那边压根没有你的记录，直接卸载即可。

  • 如果你已经登舱过，停用或卸载插件之后心跳会停掉，节点会逐步降级、不再出现在公开图谱中。如需主动从 hub 端清空你的节点和关联记录，目前请直接到仓库提 issue 申请删除（注销节点的可视化入口还在做，预计随下一版上线）。

Q：上报数据是否走 HTTPS？凭据怎么签名？

A：所有上报通信走 HTTPS，使用基于 HMAC-SHA256 的请求签名。每次上报会带 X-BP-Site-Id / X-BP-Timestamp / X-BP-Nonce / X-BP-Signature 四个请求头，签名串组合是 METHOD\nPATH\nTIMESTAMP\nNONCE\nBODY_HASH。服务端做时间戳偏移校验 + nonce 防重放（默认 nonce 缓存窗口 900 秒、时钟偏差容忍 5 分钟）。本地接入凭据以 AES-GCM 加密保存，明文不会落盘。

七、提 PR / 反馈问题

这部分是给愿意一起把事情做得更好的朋友看的。只讲怎么报问题、怎么贡献。

7.1 报 Bug 或提建议

到仓库提 issue：[atangccc/Astrahub/issues](https://github.com/atangccc/Astrahub/issues)。

提 issue 时麻烦带上：

  • 你的 Halo 版本（在 Halo 控制台 → 关于）。

  • 插件版本（在插件列表能看到）。

  • 复现步骤（哪一步触发的、看到了什么、期望看到什么）。

  • 必要的话附浏览器控制台的报错截图，或者插件后台的「系统日志」截图。

7.2 贡献文档或翻译

如果你发现文档里有错别字、表述不清、或者想加一段使用心得或者加入项目，请你：

  1. 在 GitHub 仓库点 「Fork」复制一份到你自己的账号。

  2. 在你 Fork 的仓库里直接编辑 README.md 等仓库内文档。

  3. 提交修改后，回到原仓库点 「Pull Request」。

在 PR 里简单写明这次改了什么。

如果不熟悉 Git 操作，也可以直接在 issue 里贴出你想改的内容，我或其他维护者来代为提交。

7.3 报告非技术问题

包括但不限于：

  • 你觉得某句文案表达得不合适。

  • 你认为某个功能的默认行为应该改一改。

  • 你觉得 hub 的某个交互流程让人不舒服。

这些都欢迎在 issue 里直接提，标签选 discussion 或 feedback 即可。不会有任何"这种问题不该提"的回应。

八、其他 一次把脑子里那些"为什么"都讲一讲

下面这些问题来自这段时间被问得最多、最容易引起认知偏差的几个方向。我按八个维度整理：理念、科普、扩展、开源、规划、使用场景、常见误区、数据可视化。每个维度三问，每问尽量给到能落地、不绕弯的回答。

一、理念（传达思想，树立三观）

Q1：星链有个设计是"一颗星球可以被多个星系收录"，这和传统友链"我链你你链我"的单向关系很不一样。为什么要做成多星系收录？不怕友链关系变乱吗？

传统友链是 1:1 的边："我把你加到我的友链页 + 你把我加到你的友链页"。这套模型在 10 个朋友的圈子里很顺，但放到几百站点就崩了 —— 一个站长不可能同时属于"摄影圈"和"前端圈"和"读书圈"，他只能选一个友链页主题。

星链把"圈子归属"和"友链关系"拆成了两层：

  • 友链层：还是双向匹配，互链才有边，不会"乱"。这层是关系。

  • 圈层（星系）层：一个站点可以同时属于多个圈层。这层是兴趣标签，不是关系。

举个例子：你站点既写前端又拍照片，可以同时挂在「前端开发」和「街拍胶片」两个星系里，互不冲突；而你跟某位摄影博主有互链，这条友链边只在你们两人之间，跟星系无关。所以多星系是"放在哪些书架上"，友链是"和谁握过手"，两者并行不悖。

Q2：星空旅人这个星系的存在很有意思 —— 那些没有归属的流浪星球被放在这里，而不是直接筛掉。这个设计背后是怎么考虑的？是不是意味着星链更看重"内容有价值"而不是"关系够不够近"？

正是。星空旅人是 hub 端的一类特殊圈层，专门承接"通过站点投稿但还没正式登舱"的友链候选。

设计逻辑是：

  • 关系网络永远滞后于内容产出：一个新博主第一次发文章的时候，他在网络里一个朋友都没有。如果只看关系，他永远进不了图谱。

  • 流浪不等于无价值：很多优质独立博客就是只闷头写、不主动社交，他们值得被发现，只是还没建立关系。

  • 流量入口的最低成本兜底：星空旅人就是这些站点的临时栖息地，等有人和他们互链了，他们会被自动归入对应的圈层。

Q3：星链的轨道页面做得挺炫的，但加载速度会不会受影响？在"好看"和"好用"之间你们怎么取舍的？

实话讲：取舍过程是真的痛苦。轨道关系图的渲染主要靠 WebGL 做 3D 场景，节点数量上去之后性能确实会扛不住。我们做了几件能落地的事：

  • 后端预聚合：服务端在每次同步时就把"节点 + 圈层 + 友链"按一致的投影格式算好，前端拿到的是已经去重、排过序、计算过权重的数据，不用在浏览器里跑全量边匹配。

  • 按需加载：节点详情、关系、时间线分别走独立接口，第一屏只拉概览，关系点开后才请求；具体接口列表见后面 Q8。

  • 缓存槽位预留：服务端为推荐快照与热点节点缓存预留了运行时缓存接口，后续接 Redis 时业务代码不用改。

  • 轨道页分页：星系成员列表前端按页加载，不会一次性把几百颗砸到 DOM 里。

需要诚实承认的是：

  • 目前没有"3D 自动降级到 2D"的开关。轨道图就是 WebGL 场景，3D 跑不动只能靠减少节点数量来缓解。

  • 首屏 JS bundle 偏大。3d-force-graph 这个依赖目前主要在插件控制台里用，hub 前端走的是自研的 WebGL 场景，但 bundle 仍然不小。

  • 3D 场景在低端 Android 设备上仍然有压力，长期方向是"轻量优先 + 重交互可选"。

"好看"我自己列在中间偏上 —— 不能丑，但更不能挡住用。

二、科普（特殊的使用技巧）

Q4：插件装好之后，除了提交友链和 RSS，还有没有什么"藏得比较深"的设置值得调一调？比如更新频率、缓存时间、或者显示样式上的自定义选项？

有几个不在显眼位置但很实用的（在插件控制台 → 设置 → 星链接入配置 / 同步设置里都能找到）：

  • 同步间隔（sync.intervalMinutes）：定时同步的频率，默认 60 分钟，最小 1 分钟。如果你发文很勤、希望尽快出现在主星上，可以调低；如果你站点几乎不更新，调高一些更省资源。

  • 失败退避（sync.retryBackoffSeconds）：上传失败后多久重试，默认 30 秒，最小不会低于内置兜底值。

  • 挂件开关（widget.enabled）：默认开启。关闭后前台不再渲染 galaxy-link-widget 浮窗。

  • 实时播报（realtimeBroadcast.enabled）：默认开启。开启后主星推送的接入、同步、文章推荐消息会通过吉祥物气泡展示在你前台访客面前。如果你不希望访客看到这种弹气泡，去后台关掉即可。

  • 联系邮箱：除了接收签发码外，「重新登舱」时也用它做身份验证。如果博客站点崩溃或者凭据丢失，凭这个邮箱重新登舱即可找回原节点 ID 与所有友链关系。建议填一个长期可用的邮箱。

Q5：如果我的博客有好几个分类，我只想让星链抓取其中某一个分类的文章，不抓其他的，能做到吗？RSS 源要怎么配？

可以，关键在 RSS 地址你自己决定指向哪个范围。星链拿到的内容范围完全由你填的 RSS 地址决定。

  • 全站参与：直接填你站点的全站 RSS 地址，最省事。

  • 只想分享某一分类：很多 Halo 主题为分类 / 标签提供了独立的 RSS 输出，你把那个独立 RSS 的地址填到「RSS 地址」字段即可，星链拿到的就只是该范围内的内容。具体路径请以你当前主题的实际输出为准（不同主题命名可能不同），可以直接在浏览器里打开试一下哪条返回的是 XML feed。

  • 主题不带分类 RSS：可以借助 RSSHub 等转换服务把你想要的范围过滤后输出成新源，再填进来。

底线一条：你的 RSS 给什么，星链拿什么，绝不会越界爬你 RSS 里没有的内容。

三、扩展（衍生玩法）

Q6：星链现在主要是博客友链网络，那它有没有可能和别的平台打通？比如把我的 Twitter、Mastodon 或者 Telegram 频道也作为一个"星球"挂进来？还是说必须是有 RSS 的独立博客才行？

短期内（半年内）只支持有 RSS 的独立博客作为节点，原因：

  • RSS 是开放标准，签名、订阅、抓取都有成熟工具链。

  • "独立博客"的定义比较硬：你拥有自己的域名、自己的内容存储、可以离开任何平台。Twitter/Mastodon/TG 都依附平台，理念上和星链的"去中心化连接"有冲突。

但中长期会做"外部内容源"概念：

  • Mastodon：因为它本身有 RSS/@user.rss），后续大概率支持，但归类会单独标记。

  • Twitter/X：API 关闭了，需要走第三方桥接，优先级不高。

  • Telegram 频道：可以靠 RSSHub 接出 RSS 后挂进来，但仅作为"内容流"，不作为"图谱节点"。

Q7：我看到有些星系的星球数特别多，有些则只有几颗。如果一个星系下面挂满了，比如超过 100 颗，会有什么玩法变化吗？还是说就是列表变长而已？

实事求是地说，目前没有专门为"星系挂满"做特殊玩法切换。能明确告诉的是：

  • 排序是有的：星系内的成员会按"活跃分 + 影响分"的综合分排序，活跃 + 影响力高的会靠前，新人不会因为加入晚就永远沉底。具体打分维度见后面 Q14。

  • 分页是有的：成员列表走标准的分页接口，节点列表前端按页加载，不会一次性把几百颗砸到 DOM 里。

  • 关联线权重会增长：当一个星系成员变多时，它跟其他星系之间的"同星系关联"边权重SaturatingCount(SharedLinkCount, 12)）会按饱和函数累加，不是线性堆，避免大星系把图谱压扁。

后期针对这些当前还没有将进行深度优化：

  • "超过 N 颗就触发二级聚类"的硬阈值；

  • "核心 / 中间 / 边缘"这种成员分阶展示；

  • 3D 视图的远近 LOD 简化逻辑（性能上是靠按需展开邻居 + 节点总数控制顶住的）。

这些都在后续路线图里讨论过，但目前还没动手："挂满"目前主要是 排序权重 + 关联线权重 上的影响，不会触发新的 UI 玩法。如果你期望某种特定的"满员行为"，欢迎在 issue 里提，我会按真实需求来排优先级。

Q8：星链的数据 —— 比如我星系的星球列表、关联图谱 —— 有没有 API 可以调？我想在自己的博客首页放一个"我在星链里的邻居"展示模块，能不能自己写代码拉数据？

可以。hub 暴露了一组图谱相关的公开接口，路径前缀都是 /v1/（不带 /api/ 前缀），常用的有：

  • 节点详情GET /v1/graph/nodes/{nodeId} —— 节点完整资料、所属圈层、关联摘要。

  • 节点关系GET /v1/graph/nodes/{nodeId}/relations —— 一阶 / 同圈层 / 共享分组等关系条目。

  • 节点时间线GET /v1/graph/nodes/{nodeId}/timeline —— 接入历史、同步事件、互动事件。

  • 节点列表GET /v1/graph/nodes —— 全网节点的轻量索引（支持分页 / 排序）。

  • 图谱概览GET /v1/graph/overview —— 主页用的概览数据。

  • 站点详情 / 关系GET /v1/graph/sites/{siteId}GET /v1/graph/sites/{siteId}/relations。

  • 主题（话题/星系）详情 / 趋势GET /v1/graph/topics/{topicId}GET /v1/graph/topics/{topicId}/trends。

需要诚实说明的：目前没有一个独立的 /v1/clusters 接口直接列出"所有圈层"，圈层信息是通过 topics 系列接口或站点详情里的归属字段拿到的。如果你需要我增加一个独立的圈层列表端点，欢迎在仓库提 issue。

接口请求需要走签名认证（HMAC-SHA256），具体协议见后面 6.5 节。如果只是简单看看，前面提到的"零接入挂件"已经够用，无需自己拼。

四、开源

Q9：星链插件现在是开源的吗？如果我想自己改点什么，比如换个配色、加个自定义字段，是直接改插件代码就行，还是需要等官方更新？

完全开源。仓库地址：

  • 插件端：<https://github.com/atangccc/Astrahub>（AGPL-3.0）

如果你只是改外观、加自定义字段：

  • 改外观：fork 仓库 → 在 console/src 下改样式（控制台用的是 Vue 3 + UnoCSS，不是 SCSS / Tailwind） → pnpm build 构建出新的产物 → 自己上传到 Halo 替换插件。

  • 加字段：要同时改插件 + 服务端，因为字段最终要存到 hub 那边。如果你用我们的官方 hub，新字段需要走 PR 流程让我们 review 后合入；如果你自建 hub，自己说了算。

Q10：如果我想给星链插件提 PR，代码风格和提交规范是什么样的？有没有贡献指南或者开发者文档可以参考？

技术栈和基础规范：

  • 代码风格：插件后端用 Java（Halo 官方插件的 Java 风格），console 部分用 Vue 3 + TypeScript + UnoCSS（不是 Tailwind，也不是 SCSS）。后端 hub 服务用 Go，遵循 gofmt 标准格式化。

  • commit 规范：建议按 [Conventional Commits](https://www.conventionalcommits.org/) 写，例如 feat: add wandering planet timelinefix: prevent duplicate friend link push。

  • PR 范围：一个 PR 只做一件事，避免 UI、协议、构建脚本同 PR 杂糅。

诚实说明：仓库目前还没有正式的 CONTRIBUTING.md，开发流程主要靠 issue 沟通。如果你愿意帮我们写一份贡献指南，是非常欢迎的 PR。开干之前最好先开 issue 同步一下方向，避免你写完发现思路不对。

Q11：星链的后端也是开源的还是只有插件部分开源？如果我想自己搭一套类似的友链网络，能不能直接用星链的代码改？

插件端开源（AGPL-3.0），hub 后端目前没有公开仓库，由作者自己维护、自己跑。

所以"直接拿星链后端代码自己搭一套"短期内做不到。如果你对这件事感兴趣，目前更现实的两条路是：

  1. 提建议 / 提需求：在插件仓库的 issue 区告诉我们你想干什么、需要什么能力，会被认真评估。

  2. 亲自参与：插件端是 AGPL-3.0 完全开源的，欢迎 PR；hub 端如果你有想合作的具体方向，可以直接邮件 / issue 联系。

五、规划（未来方向）

Q12：星链现在主要还是靠站长主动提交友链来加入，未来有没有计划做成自动发现？比如检测到某个新博客经常被现有星球引用，就自动推荐它入驻？

有，已经在做的雏形是「站点投稿 / 流浪星球」机制：

  • 当 A 站点同步上来的友链或 RSS 关联里出现一个还没登舱的 B 站点，hub 会把这条信号留作"流浪关系"。

  • B 站点会以"流浪星球"的身份出现在主星首页和轨道页，挂在「星空旅人」这个特殊节点下，让访客也能看见它。

  • 一旦 B 自己安装插件登舱，原来指向它的所有流浪关系会自动激活、合并成正式的双向友链关系，不需要重建。

需要诚实说明的："完全自动推荐入驻"不会做 —— 那违背星链"主动同意 + 显式登舱"的原则。流浪星球只是让 B 被看见，不会替 B 同意任何上报；具体的"累计阈值 / 自动推荐打分"目前还在迭代，没有写死的硬阈值可以贴。

Q13：轨道页面现在展示的是星系和星球的关系图谱，未来会不会增加时间线功能？比如按时间轴展示一颗星球从加入、被收录、到慢慢被多个星系关联的完整历程？

已经做了一部分。每个节点在 hub 端都有一份"时间线"数据（接口见 Q8 列表里的 GET /v1/graph/nodes/{nodeId}/timeline），现在能看到：

  • 节点接入时间。

  • 历次同步事件、影响力变化。

  • 友链关系建立的时间点。

UI 上目前只在节点详情页底部以"时间线列表"形式展示，还没做成可视化的"星球成长史"。下一阶段会做成横向时间轴 + 关键事件标记。也欢迎你提建议在时间轴上标记哪些事件最有价值。

Q14：有没有考虑过做"星球活跃度排行榜"或者"本周热文推荐"之类的功能？让那些更新勤快、内容优质的小站点有更多被看见的机会？

正在做。hub 端已经在算多组分数（站点维度 / 节点维度 / 内容维度 / 主题维度都有），站点维度的真实因子是这样组合的：

  • ActivityScore（活跃分）：最近 7 天活跃 0.40 + 最近 30 天活跃 0.22 + 推送可靠性 0.20 + 新鲜度 0.18。

  • TrustScore（可信分）：元信息完整度 0.30 + 直接证据率 0.26 + 推送可靠性 0.22 + 新鲜度 0.12，减去 无效内容率 0.22 + 失效关系率 0.18。

  • InfluenceScore（影响分）：跨站引用命中 0.45 + 直接证据率 0.35 + 最近 30 天活跃 0.20。

  • FreshnessScore（新鲜度）：新鲜度 0.70 + 最近 7 天活跃 0.30。

  • 节点维度还另外有"热度分 / 成长分 / 质量分"，主题维度有"热度分 / 成长分 / 多样性分"。

所有打分都被裁剪到 0 ~ 100 之间。这些分目前主要在后端排序、推荐、关联线权重里使用，前台还没专门暴露成公开排行榜。本周热文推荐我们也在设计 —— 难点是怎么避免变成"流量游戏"，让小博主也有露出机会。我们倾向于按"圈层内排行"而不是"全网排行"，让每个圈子都有自己的明星。

六、使用场景（不同人群的玩法）

Q15：我是一个刚开博客没多久的新手，友链还没几个。这种情况下加入星链会不会很尴尬 —— 星系里只有我自己一颗星球？还是说正好可以借助星链来结识其他博主？

正好相反 —— 新手才是星链最受益的群体。原因：

  • 老博主已经有自己的圈子和流量入口，星链对他们是"加分项"。

  • 新博主最大的痛点是 第一波读者从哪来。星链刚好直接把你扔进同主题圈层，让你跟一批潜在读者照面。

  • 新人节点会出现在"最近接入"流里，被老博主看到的概率反而比埋头写半年还高。

  • 星空旅人机制兜底，就算暂时没人跟你互链，也不会被踢出网络。

唯一要做的：填好站点简介 + 选好你内容主要的分类 RSS。让人一眼看出"这是写什么的"。

Q16：如果我是一个已经有很多友链的老博主，把我的友链列表导入星链之后，我的那些朋友们会收到通知吗？还是说需要我一个个去告诉他们？

不会自动发通知。星链同步友链元数据，但不会主动给你的朋友发邮件或推送。原因：

  • 你朋友不一定也用 Halo，更不一定装了星链。

  • 自动发通知很容易被当成垃圾邮件。

但是有几种自然扩散方式：

  • 你的朋友如果也装了插件，他们登舱后会自然匹配到你（因为他们的友链里有你）。

  • 友链关系会出现在公开图谱里，他们的访客如果点进图谱可能发现你已经在网络里。

  • 你可以在自己博客发一篇"我加入了星链，欢迎一起来"的文章，附上邀请链接，这是最自然的扩散方式。

主动告诉朋友 + 让网络自己拉拢人，是健康的增长路径。

Q17：星链适不适合用来做"专题收录"？比如我想把散落在各个独立博客里关于"博客美化"的文章收集到一起，能不能以我的星系作为这个专题的容器？

目前没有。 现有站点已存在标签属性，后期可按标签进行拓展；

七、常见误区（帮用户避坑）

Q18：我提交了友链和 RSS，但是轨道页面上看不到我的星球，一般是什么原因？是审核没通过，还是数据同步有延迟，还是我哪里填错了？

按概率从高到低排：

  1. 同步还没跑到：默认 60 分钟同步一次，登舱后第一次同步可能要等几分钟。可以在插件控制台手动点一次「同步」加速。

  2. RSS 地址不可访问：填了一个 hub 那边访问不到的地址（比如内网地址、HTTP 而非 HTTPS、403 等）。可以在浏览器试着打开 RSS 地址看是否正常。

  3. 没勾同意 / 没接入完成：第二节讲过的硬约束。如果没走完"勾同意 → 发签发码 → 填码 → 确认"全流程，节点不会真正建立。

  4. 审核未通过：极少数情况下，如果你的投稿站点出现了 hub 的黑名单关键词，会被人工拦下。这种情况会有审核驳回邮件。

  5. 缓存延迟：前台轨道页可能有几分钟的浏览器缓存，强刷一次（Ctrl + F5）。

90% 的"看不到自己"是 1 或 2，3 也很常见。先看插件控制台的「系统日志」，那里会写得很清楚，同时为了规范后期将加入AI审核。

Q19：我改了我的博客域名或者 RSS 地址，星链那边会自动跟着更新吗？还是需要我手动去后台重新提交？

要分两种情况：

  • 只改 Halo 系统设置里的站点名 / 简介 / RSS 地址、域名不变：编辑完成点击更新信息按钮即可。

  • 域名变了（比如从 .com 换到 .cn）：编辑完成点击更新信息按钮即可。

强调一下：重新登舱是搬家场景的官方解法。直接把新域名当新站点登舱会丢失你之前所有的圈层归属和友链关系。

Q20：如果我的博客暂时关闭了，或者 RSS 挂了几天，星链会直接把我从星系里移除吗？还是说有一个"宽限期"？

无宽限期的说法（后期新增状态检测）。

八、数据可视化（让文章更好看）

Q21：星链后台有没有统计数据可以看？比如我的星球被多少个星系收录、我的文章被阅读了多少次、我的星系在星链里的影响力排名？还是说这些数据只有你们内部能看到？

你能看到的：

  • 接入信息：节点 ID、登舱时间、最近同步状态。

  • 影响力分：影响分、可信分、活跃分都会显示在你的节点详情页。

  • 被收录的星系数：你的节点详情页直接列出所有归属圈层。

  • 友链拓扑：你的双向友链对象列表 + 一阶友链网络图。

  • 同步历史：每次同步的时间、状态、变化的字段。

我们内部不能看到的（也不会做）：

  • 你单篇文章的阅读量（因为 hub 不爬你正文，没数据）。

  • 你的访客信息（hub 完全不接触访客层）。

简单说：你的"对外公开档案 + 同步行为日志"你都能看；你内部的访客行为我们碰不到。

Q22：我看到轨道页面上星系之间有关联线，这些关联是怎么产生的？是手动建立的，还是根据星球的重合度自动生成的？

完全自动生成，没有手动入口。但我得把"具体规则"讲准 —— 真实算法是多信号加权而不是单一阈值，hub 端用下面这套权重打分：

  • 直接互链（DirectMention）权重 0.34

  • 直接引用（DirectReference）权重 0.24

  • 同圈层共现（SameCluster）权重 0.10

  • 共享友链（SharedLinks）权重 0.18

  • 共享分组（SharedGroup）权重 0.12

  • 共享主题（SharedTopic）权重 0.04

多信号同时命中还会有额外加成，最终算出一个 RecommendationScore（推荐分），再用一个饱和函数SaturatingCount(SharedLinkCount, 12)）把"共同友链数"折算成边权重 —— 饱和的意思是共同友链数从 1 到 12 是大幅增长，超过 12 之后边继续变粗的速度急剧放缓，避免少数大节点把整张图压扁。

所以你看到的关联线不是一个"≥N 颗就连线"的硬阈值，而是上面这些信号的综合分超过一定权重后才显形。互链型关联会被加重，纯单向粉丝型关联会被弱化（DirectMention 权重最大且要求双向匹配）。没有"包含关系"这种特殊标记，所有关联都是同一类边、只是权重不同。

整个过程没有人工干预，跟着数据自然变化。

Q23：星链后台能看到我的"影响力分"，这个分是怎么算出来的？我能不能干预它？比如多发文章、多换友链就能涨？

简单回答：能涨，但不是靠刷量。前面 Q14 已经把分数体系讲过一遍了，这里只补三句结论：

  • 影响分主要看"跨站引用命中 + 直接证据率 + 最近 30 天活跃"三件事。换句话说，别人的友链里出现你 + 别人的文章里引用你 + 你自己保持更新，这三个都涨它就涨。

  • 它和可信分是分开算的，可信分会加上"元信息完整度 / 推送可靠性"等基础项，并扣减"无效内容率 / 失效关系率"。所以站点信息填全、RSS 别经常 404，比单纯发文更重要。

  • 我们不会做任何"花钱买分 / 充值加权"的入口。打分逻辑全部写在代码里，未来如果要调整也会在 changelog 里写明白。

Q24：如果我想在自己的博客里嵌入一个"我的星链关系图"小部件，展示我的星球挂在哪些星系下、关联了哪些邻居，有没有现成的方案？

有，而且比你想的还简单 —— 不需要在主题里写任何引用代码。

插件实现了一个 Halo 主题 <head> 的注入逻辑：只要满足以下两个条件，组件就会自动渲染到你站点上：

  1. 插件的"挂件开关（widget.enabled）"是开启状态；

  2. 你的站点已经走完登舱流程linked = true）。

满足条件之后，Halo 会自动在每个页面 <head> 注入：

  • 一段 id="astrahub-galaxy-widget-style" 的内联样式（CSS 命名空间是 .ah-gxw-*）；

  • 一段 id="astrahub-galaxy-widget-data" 的 JSON 数据（节点信息、创作者头像、健康状态等）；

  • 一段 id="astrahub-galaxy-widget-script" 的初始化脚本，启动后会在页面右下角 position: fixed 浮一个吉祥物 + 卡片面板。

也就是说 —— 你不需要在主题里加 <div>、不需要 import 任何 JS、也不需要改主题源码。换主题也照常工作，因为它挂在 Halo 的主题 <head> 渲染钩子上，只要主题正常渲染 <head>，组件就跟着进。

如果你不想要这个浮窗、想自己拼一个"关系图谱"挂在博客侧边栏：

  • 在插件控制台关掉"挂件开关"；

  • 走前面 Q8 提到的公开 API/v1/graph/nodes/{nodeId} 节点详情/v1/graph/nodes/{nodeId}/relations 关系/v1/graph/nodes/{nodeId}/timeline 时间线/v1/graph/topics/{topicId} 主题等），自己写代码 fetch 出来按你想要的样式渲染。

样式自定义这块，因为整套样式是插件自动注入的内联样式，不是分发文件，没有专门暴露 CSS 变量供主题层覆盖。你想改观感的话，更可控的做法是关掉自动挂件，用 API 自己拼一个。这部分如果有需求，后续可以考虑把样式拆出来加几个 CSS 变量入口。

下面进入收尾部分，谢谢能看到这里。

九、最后想说的话

这半年我做这个项目，被问过、被质疑过、也被冷嘲热讽过。我能体会每一种态度背后的来源：有的来自不了解，有的来自路径依赖，有的来自对"又一个新东西"的本能警惕。

但独立博客这件事，是值得做的。一直被搜索引擎压着、被算法平台挤压、被流量入口边缘化的小博客们，配得上一个让彼此被看见的机会。

我做不到完美，AstraHub 也未必是最终答案。但只要还有人愿意写博客、愿意读博客、愿意在自己角落里安静地表达，做一个把这些角落连接起来的尝试就不是无意义的。

如果你看到这里，无论是决定试一试，还是觉得"这玩意我不需要"，我都谢谢你认真读完。文档之后会持续更新，仓库永远开放。

最后，借用一句不知道该归功于谁的话：

很多事情之所以没有发生，不是因为它不该发生，只是因为还没有人去发起。

我先发起一个，剩下的，看时间。

项目仓库

  • Halo 插件：https://github.com/atangccc/Astrahub

作者主页：https://www.aobp.cn/

许可：插件采用 AGPL-3.0，hub 服务端目前没有公开仓库。

如果你愿意，把这篇文档分享给身边还在写独立博客的朋友。每一个新节点的加入，对这个网络都是真实的扩展。