← #803

Show HN：受够了每个 HN 链接都要开两个标签页，于是写了个用户脚本

文章摘要

作者 twalichiewicz 的自述非常直白：HN 的价值一半在人们分享的链接，另一半在围绕它的讨论，而他发现自己总是一个标签页开文章、另一个标签页开评论，来回切换。于是他写了个用户脚本把两者合并。

脚本做两件事。第一，从 HN 点开一个链接时，文章会带着一个侧边讨论面板一起打开；面板不需要你的登录凭据，宽度可调，想改也很容易。第二，如果你落在任何一个曾经被提交到 HN 的页面上，脚本会自动找到那条已存在的讨论，并在右上角加一个按钮供你唤出面板。

这个项目在 HN 上拿到 433 分之后迭代得非常快，几天内连发多个版本，并且已经改名为 Backchannel——因为它不再只关于一个站点。现在它支持多个来源，每个来源都是一个可勾选的开关：Hacker News、Reddit、Bluesky（经由独立索引 Constellation）、Lobsters、Wikipedia（找到链接该页面的 Talk 页和项目页）、Mastodon（经由 opt-in 索引 Tootfinder）、Lemmy。所有你打开的来源会被合并成一条对话，每条评论悄悄标注它来自哪里。

它还长出了几个更有野心的功能：注释（Annotations）——评论里引用的原文片段会被匹配回文章并高亮，点击高亮就能把讨论过滤成只看讨论那一段的人（目前是 beta，需要在设置里开启）；自定义首页——把你启用的所有来源混合成一个属于你自己的「互联网首页」；以及在支持的来源上直接投票、回复甚至提交——它复用你已有的会话，在 news.ycombinator.com 的弹窗里完成，脚本本身从不接触你的密码。

隐私方面作者写得相当详细：没有后端、没有分析、没有遥测，但因为它在每个页面上运行，README 逐个来源说明了会联系哪些主机、以什么身份（比如 Reddit 会以你的账号身份收到你访问的页面，Lobsters 只发送域名，Bluesky 和 Mastodon 走的是第三方索引而非平台本身），Webmail、网银、认证流程和云控制台一律被硬性排除。整个项目是单文件、无构建步骤、无依赖，作者的说法是：你看到的就是用户装的。

HN 评论精华

「这不该是脚本，该是浏览器功能」

ahachete 的高票开场：我也是，每次都中键点两下，一次开文章一次开评论。这不该是个脚本（无意冒犯，做得很好），这该内建在浏览器里！
大量评论指出各浏览器其实已经有分屏：pluc 说 Firefox 新加了 Split View，但你仍得右键选「在分屏中打开」；dagurp 说 Vivaldi 多年前就有（叫 tiles），还能右键「在跟随标签页中打开」，让某一格里点的所有链接都在另一格打开，他就是这么刷 HN 的；vdfs 补充 Edge 早有、Chrome 现在也有了，但 Chrome 没有「链接在另一格打开」。powvans 一针见血地说明了本项目的独特之处：它的酷点在于即使你只是偶然逛到某篇文章，它也能把 HN 讨论捞出来。
kccqzy 给出了最有分量的功能拆解：功能 2 非常有用，因为看到技术文章时你就知道 HN 上大概率有讨论，有时甚至会直接推翻文章论点；功能 1 在他看来价值低得多——它只说明人们不擅长窗口管理。我们不喜欢重叠窗口和找窗口，于是发明了窗口里的标签页；然后又想同时看两样东西，于是发明了标签页里的分屏。有个好的窗口管理器，这两样都不需要；可惜社区更愿意在应用层而不是桌面层解决问题。这条引发了一场关于标签页归属的长辩：TeMPOraL 回忆微软当年真的让 IE 把标签页暴露给窗口管理器，结果标签页全都进了 Alt+Tab 环，作为标签页囤积者他恨死了这个设计，Alt+Tab 本身也变得极慢；更根本的问题是，让窗口管理器接管应用内标签页，意味着 WM 得支持每个应用开发者对「标签页是什么」的每一个异想天开的定义。ta8903 则从实用角度反对：他随时开着几百个标签页，用 Sidebery 的树形标签和分组来组织任务和文档，很难想象窗口管理器能提供等价体验。

隐私是第二大主题

abudooboo 提出了最实质的安全问题：脚本会在你访问的每一个页面上向 hn.algolia.com 发查询，从而泄露完整 URL、query string 和 fragment；至少应该把查询清洗成只保留 origin 加 path。作者当场承认并开了 issue 跟进。
jstrieb 顺势介绍了自己的对照方案——一个 Firefox 扩展 hackernews-button，用布隆过滤器来判断某个链接是否被提交过，因此在你主动按按钮之前不会有任何外部请求。danbruc 替他解释了原理：与其去问「这个 URL 提交到 HN 了吗」，不如反过来问「哪些 URL 提交到过 HN」，把结果存进布隆过滤器，然后在本地回答「这个 URL 很可能被提交过吗」。avadodin 想到了一个有意思的对抗场景：如果过滤器由外部提供，理论上可以刻意让「高关注度」的提交不进过滤器，这样客户端就会在那些特定 URL 上发出请求，反而暴露了最想被知道的信息。

为什么是用户脚本而不是扩展

swyx 问这是否不如做成 Chrome 扩展，毕竟用户还得先装 Tampermonkey。作者 twalichiewicz 的回答是透明度：因为脚本会跨页面运行，他希望完整源码就摆在那里、安装前一眼可查；用户脚本也让他可以快速迭代，不必处理扩展打包和权限。
dewey 从用户角度补充：他更喜欢用户脚本，因为只需装一个能加载许多脚本的扩展，而不是每个小改动都装一个扩展；而且扫一眼用户脚本在做什么，远比解包扩展、在层层封装里找业务逻辑容易。noncovalence 说用户脚本比 Chrome 扩展更耐久、更省事，他为自用写过扩展，光是让浏览器允许运行自己写的代码就得跳过一堆火圈，manifest v3 的烂摊子还没算。moritzwarhier 提出了反面理由：扩展能访问一批用户脚本拿不到的 API（跨源标签页通信、列举所有标签页等）；他也承认最大的问题在于大多数人安装扩展时，只要觉得来源可信就几乎不会犹豫一秒。

「同一个想法」的集体涌现

这条帖子最有趣的社会学现象是，大量人跳出来说自己早就做过或想做类似的东西：kwar13 在同一串里贴了三次自己的扩展，并自嘲「目前拥有惊人的 6 个用户」；latchkey 维护的 Orange Juice 扩展有 666 个用户，他给「选中的」故事加了左右方向键分别打开评论和文章；jitbit 很久前做过一个 Chrome 扩展，当前 URL 在 HN 上出现过就显示出来并带上分数；FWxqQ 走了完全不同的路——做了个自定义 RSS，每一条同时包含文章链接、评论链接和最高票评论的正文，还能按分数过滤，用 GitHub Actions 每五小时更新，所以完全免费（他说自己就是这样发现这篇帖子的）；txhwind 写过把 PDF 内嵌进 arXiv 摘要页的脚本，并借此发问：agent 时代软件生产力爆炸了，但我们对日常体验中的每一个摩擦点是否足够认真？我们是主动识别并消除这些痛点（往往很容易），还是无限期地忍受它们？

关于「元讨论层」的愿景

parpfish 提出了一个更大的构想：他希望网络上的一切之上有不同「图层」的元讨论——每个博客和网站都有数不清的社群在讨论它，而你可以自由选择看不看；你不再是跨站浏览，而是跨社群浏览同一个站点。作者回复说他正在朝这个方向做：注释功能是第一步，最新版本已经可以加入 Reddit 作为来源，访问某个 URL 时会跨所有子版块查找，给你一份混合讨论。
jedberg（Reddit 早期员工）讲了个有意思的往事：早在 2008 年他就想做完全一样的事——把 Reddit 评论注入任意页面，可惜当时的 JS 生态还不足以安全地让用户在页面上登录 Reddit。Disqus 之所以能成，是因为每个页面都完全独立，讨论只存在于嵌入在那个页面上的实例里。est 则一句话概括：这才是 Reddit 本该有的样子——一个 del.icio.us 的通用评论框。

几条自嘲

f3408fh：现在再写个用户脚本，屏蔽掉所有标题是「我受够了 X，于是我……」的帖子。frollogaston 接梗：指令不明确，我把这个脚本用 Rust 重写了一遍，然后又用 Zig 重写了一遍。
rf15 和 croisillon 都在打同一个经典梗：其实有更省事的办法——打开评论页、选中输入框、仅凭标题判断内容然后准备发言；毕竟按惯例，没人应该真的点开原文。
LoveMortuus 半认真地说自己确实经常只读讨论不开链接，标题就够他知道内容，剩下的从讨论里得到，还附赠纠错、怀疑和提问。作者回复说自己感受类似——这正是他开始折腾「HN 评论动态注释原文」功能的原因：你可以边读文章边看到大家具体在评论哪一处，有点像 Google Docs 的批注。

作者在讨论中全程高强度响应，几天内修掉了移动端默认展开、按钮可拖动、ChatGPT 和 Claude 首页误触发、侧边栏无法投票等一系列反馈，并在最后提醒：最初发布的版本没有指定 @updateURL 和 @downloadURL，早期安装的用户可能收不到自动更新。