结束“邀请垃圾邮件”的时代？Bluesky的Find Friends有何不同

「寻找朋友」——这个功能在SNS中已经成为理所当然的存在，但多年来实际上也是一个“麻烦制造者”。通过读取智能手机的联系人，找出谁也在使用同样的SNS，并顺便向未注册的对象发送邀请信息。对于用户来说，这是重聚的捷径，但对于接收方来说，往往变成了突然收到的“应用程序邀请短信”，而且由于涉及到电话号码这一强烈的个人信息，泄露和滥用的风险始终伴随左右。Bluesky在12月推出“Find Friends”时强调“重视隐私”，这一背景显示出其不愿简单沿袭旧有成功模式的强烈意图。 TechCrunch

不发送“邀请垃圾邮件”的宣言

TechCrunch传达的此次要点非常明确。Bluesky即使上传了联系人，应用程序也不会自动发送邀请短信。即便要发送，也仅限于“用户自行决定向朋友发送短信”的手动操作。考虑到许多SNS过去将联系人匹配作为增长黑客（病毒式传播的导线）使用，半强制性地发送邀请，这一立场声明显得相当具有挑战性。 TechCrunch

然而，这里存在权衡。由于Bluesky设计为“不保存或追踪个人电话号码”，无法事先判断对方是否已经在Bluesky上。因此，即使朋友善意地发送了邀请短信，接收方可能已经“已加入”但仍然会收到。9to5Mac将此视为“缺点”，但认为作为隐私保护的代价，这个问题相对较小。 9to5Mac

机制：双重同意（双重选择加入）＋号码确认

Bluesky的Find Friends功能，只有在满足以下条件时才会匹配。

• 双方启用了Find Friends功能

• 互相将对方注册为联系人（单方面的联系人注册无效）

• 通过短信确认自己的号码后上传联系人

根据TechCrunch的解释，使用时通过短信收到6位代码输入以验证号码，旨在防止通过随机输入大量号码进行“这个号码在Bluesky上吗？”的“钓鱼”滥用。此外，如果不使用该功能，也不会成为“通过电话号码被发现的一方”——不希望被职场熟人发现的人可以选择不使用该功能。 TechCrunch

提供地区也是分阶段的，初期仅限于部分国家（包括日本）的移动应用程序。 TechCrunch

“哈希对”＋“独立的硬件密钥”—以泄露为前提的防御

此次最有趣的是，Bluesky正面处理“联系人匹配”作为安全设计问题。根据TechCrunch和Bluesky的官方博客，上传的电话号码不是简单的哈希化，而是以“自己的号码×对方的号码”组合为“hashed pairs（哈希对）”保存。通过这种方式，即使数据泄露也难以逆向工程。此外，加密与数据库分开保存在硬件安全密钥中。用户可以在之后删除数据或选择退出。 TechCrunch

TechCrunch还报道了这一技术细节在事前作为RFC与安全社区共享并征求反馈。这也反映出Bluesky自身承认“联系人匹配存在许多危险实现”，而不是直接投入生产，而是公开设计以进行讨论。 TechCrunch

为何如此努力：“冷启动”和“现实中的朋友”

Bluesky在博客中提出，SNS本应是“与实际认识的人连接的场所”，但由于算法和参与度竞争的噪音，这一功能被削弱。如果现在重新以“可以见到熟人的SNS”为目标，寻找朋友是无法回避的。此外，在RFC的背景下，Bluesky提到了“社交图密度启动的冷启动问题”，并提及了用户规模。 Bluesky

总之，Find Friends不仅仅是便利功能的添加，更是“分散型（志向）SNS如何建立人际关系初期”的核心主题。

SNS（社区）上的反应：欢迎与怀疑并存

此次设计立即引发了讨论。这里将以“Hacker News”和“GitHub Discussions”上的声音为中心，整理出趋势。

1) “类似于Private Set Intersection的想法”—建议更偏向加密的解决方案

在Hacker News上，相关技术领域的Private Set Intersection（仅在保密状态下求集合的公共部分的想法）被提及，并讨论了“通过不以明文共享电话号码来避免整个攻击类别”的方向。然而，也有评论认为“在规模上可能过于过度”。 Hacker News

2) “虽然写了安全性，但最终不还是要信任服务器吗？”的指摘

同样在Hacker News上，尽管RFC涉及“安全性”，但也有怀疑的观点认为“最终仍然是信任服务器/实例的结构”。这是一种基于实际情况的评论，认为号码验证（防止欺骗）和不将号码交给服务器的设计难以共存。 Hacker News

3) “电话号码即使是哈希化也很危险”—号码空间过小的问题

另一条评论指出“电话号码的唯一性不足，哈希可能通过查找表被破解”，即所谓的“号码空间狭小”问题。Bluesky通过“哈希‘对’”提高逆向工程难度的意图在此，但用户方面的不安依然存在。 Hacker News

4) 在GitHub上，“需要更明确的规范”，“联系人本身不等于社交”

在GitHub的讨论中，深入设计细节的反馈尤为显著。例如，有人指出**电话号码回收（号码重新分配）**的说明不够清晰，建议尽早展示伪代码。 GitHub

另一个评论则表示“我的电话簿并不等同于社交图谱，所以不会使用此功能”，同时只要保持选择加入/不保存多余的“合并用附加信息”就不会担心，这种距离感被表现出来。 GitHub

总结：Find Friends更像是“承诺”而非“功能”

Bluesky的Find Friends表面上看是“终于来了朋友搜索”的更新。然而，其实质是，(1) 切断通过自动邀请增长的诱惑，(2) 通过双重同意保留“被发现一方”的选择权，(3) 以泄露为前提进行设计，(4) 事先公开RFC接受外部审查———这似乎是对隐私和增长平衡的“承诺”的实现。 TechCrunch

当然，由于电话号码这一素材本身过于强大，争议不可能完全消失。正如Hacker News和GitHub的反应所示，服务器信任和号码空间问题，以及“联系人不等于朋友”的根本论点依然存在。 Hacker News

即便如此，将联系人匹配视为“安全设计的课题”而非“增长装置”的态度，可能会成为未来同类功能实施的SNS的一个基准点。 Bluesky

由Froala Editor提供