HackerPapers

HN 二十年,最值得读的论文。

从 Hacker News 2006 年以来的全部投稿里,挑出链接本身就是论文的帖子:arXiv、期刊、会议论文、技术报告。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从必读开始
  • 8,000+篇被 HN 讨论过的论文

Essential

必读 30 篇

在论文库里看全部精选

编辑精选里 HN 讨论最热的 30 篇,每篇都有中文导读。不知道从哪读起,就从这里开始。

  1. 正在载入论文…

Archive

论文库

点柱子按年份筛选。注:源数据里 2023 年的帖子分数记录不全,2026 年尚未过完,这两年收录偏少。

难度
排序

    About

    这些论文是怎么挑出来的

    1. 01

      全量扫一遍

      读取 Hacker News 自 2006 年以来的全部 446 万条链接投稿,找出指向 arXiv、期刊、会议、技术报告和学术 PDF 的帖子。

    2. 02

      只留论文本身

      由 AI 逐条判断,剔除介绍论文的新闻、博客和幻灯片,同一篇论文的多次投稿合并计算,并统计它在评论区被引用的次数。

    3. 03

      写导读、译评论

      讨论最热的 1,500 篇配上中文导读,并精选、翻译 HN 高赞评论。导读由 AI 生成,可能有误,请以原文为准。

    网络与分布式2024arxiv.org

    Bluesky 与 AT Protocol:可用的去中心化社交媒体

    Bluesky and the AT Protocol: Usable decentralized social media

    进阶 · 约 50 分钟读完前置知识:联邦式社交网络基础(如 ActivityPub/Mastodon)、分布式系统基础

    读论文 HN 讨论
    245HN 得分
    276条评论
    6次被评论区引用

    导读

    这篇论文介绍了 Bluesky 及其背后的 AT Protocol(ATP),一种去中心化社交媒体协议,重点探讨如何在去中心化的同时保持简单易用的用户体验。论文认为可用性是去中心化社交网络成败的关键因素。

    HN 关注点:去中心化社交网络的可行性,讨论焦点集中在 Bluesky 的易用性策略、内容审核机制以及邀请制 Beta 的发布策略是否明智。

    关键词 BlueskyAT Protocol去中心化社交网络Fediverse

    HN 评论精选

    这几条评论里:支持 2 质疑 1 补充 1

    支持易用性而非去中心化才是 Bluesky 成功的关键,Fediverse 正败在这一点上

    「提供不给用户带来去中心化复杂性负担的简单用户体验」——我认为这是 Fediverse(和 Mastodon)做错的最重要的一点。我的预测是 Bluesky 会因为易用性而成功,而不是因为分布式特性。大多数用户根本不在乎是否分布式。

    kissgyorgy查看英文原文

    > to provide a simple user experience that does not burden users with complexity arising from the system's decentralized nature. I think this is the most important factor that Fediverse (and Mastodon) got wrong. My prediction is that Bluesky will be successful because of ease of use, not because of the distributed nature. Most users don't care about being distributed at all.

    补充希望更多社交网络采用 HN 式的社区投票审核机制

    为什么没有社交网络尝试 HN 式的帖子排名和审核方式——烂帖通过用户投票和版主标记逐渐沉没直至 [dead]?HN 基于活跃度赋予用户权限并保证内容质量的方式太棒了,它以极小的团队毫不费力地激励了所有正确的行为并防止滥用,我真心希望所有社交网络都像它一样。

    dartharva查看英文原文

    Why does no social network try to take the HN route towards post ranking and moderation where bad posts simply get faded and eventually [dead] by user votes and moderator flagging? HN's way of bestowing user privileges based on engagement and ensuring high quality of content is so awesome I earnestly wish all other social networks were like it. It incentivizes all the right things and prevents abuse so effortlessly with such a tiny team that it's remarkable.

    支持看好 AT 协议:产品优先、技术其次的策略是对的

    我仍然非常看好 AT 协议和 Bluesky。我认为 AT 解决了很多一直困扰联邦制系统的问题,而且 Bluesky 优先关注产品问题、其次才是技术问题,同时还能把技术做好,这是正确的路线。

    steveklabnik查看英文原文

    I am still tremendously bullish on AT, as well as BlueSky. I think AT solves a lot of problems that have plagued federated systems, and I think BlueSky’s focus on product concerns first and technical concerns second, while somehow still nailing the tech, is the right way to go.

    质疑一年封闭 Beta 是战略失误,错失了用户涌入的最佳窗口

    好奇他们长达一年的封闭 Beta(2023年2月至今)是帮了还是害了他们。Facebook 和 Gmail 那种「稀缺性」发布策略现在已经过时了,它只会在新社交网络最需要用户涌入的时候扼杀大众兴趣。Bluesky 本应做一个不超过 3 个月的半开放 Beta 作为最后的 bug 和扩展性测试,然后向公众开放——邀请制但大量发放邀请。当时兴趣更高,其他替代品还在开发早期,每延迟一个月就给人们一个月去寻找其他选择,而他们延迟了一年。

    SkyMarshal查看英文原文

    I'm curious whether their long closed Beta helped them or harmed them. Their invite-only beta lasted 1yr, from feb 2023 to today. My sense is that the "exclusivity" style launch that Facebook and Gmail used successfully is pretty much played out and ineffective now. All it does is kill broad interest in your platform right when a deluge of users into your new social network is most needed and valuable. My sense was Bluesky should have done a quick semi-open beta of no more than 3-months just as a last bug and scalability test, and then opened to the public. Make it invite-only, but distribute invites liberally, make sure anyone who wants one has one. Interest then was higher, other options were still in development or early stages. Every month of delay was a month people could find other alternatives, and they delayed a year. Then again I haven't been following it that closely. Any HN'ers that have been following it closely since last year have an opinion on this?

    相关资源

    从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。

    代码

    历次讨论

    同领域还值得读

    1. Paxos vs. Raft:分布式共识是否已达成共识?

      Paxos vs. Raft: Have we reached consensus on distributed consensus?

      重新审视了 Paxos 与 Raft 两种分布式共识算法之间的差异,试图在一个统一的框架下比较它们,并论证二者的相似程度远高于通常的认知,许多所谓的差别只是表述层面的。

      网络与分布式2020 · 343 分 · 65 评 · 引用 10进阶 · 约 28 分钟编辑精选
    2. Stellar 协议:互联网级共识的联邦模型

      Stellar Protocol: A Federated Model for Internet-Level Consensus (2016)

      提出 Stellar Consensus Protocol(SCP),一种面向互联网级共识的联邦拜占庭协议模型。

      网络与分布式2018 · 301 分 · 61 评专业 · 约 90 分钟编辑精选
    3. 拜占庭将军问题(1982)

      The Byzantine Generals Problem (1982)

      这篇 1982 年论文提出并形式化了拜占庭将军问题:在分布式系统中,部分节点可能叛变或故障、通信不可完全信任时,忠诚节点如何达成一致行动。

      网络与分布式2018 · 290 分 · 77 评进阶 · 约 75 分钟编辑精选
    4. Google 变差了吗?对搜索引擎中 SEO 垃圾的纵向调查

      Is Google Getting Worse? A Longitudinal Investigation of SEO Spam in Search

      对搜索引擎结果中的 SEO 垃圾内容做了纵向追踪:作者团队在一段时间内持续采集 Google、Bing、DuckDuckGo 等引擎针对商品评测类查询的结果,用分类器识别联盟营销…

      网络与分布式2024 · 276 分 · 274 评入门 · 约 45 分钟编辑精选
    5. 使 CRDT 能够容忍拜占庭故障

      Making CRDTs Byzantine Fault Tolerant

      Martin Kleppmann 等人的论文研究如何让 CRDT(无冲突复制数据类型)抵御拜占庭故障节点,即部分参与者恶意篡改数据时仍能保证一致性。

      网络与分布式2022 · 266 分 · 40 评进阶 · 约 90 分钟编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。