我构建了一个在终端运行的约会应用，它是无后端的
I’m happy to translate the article for you, but I’ll need the actual text of the post. The message you provided only contains the source link, and I don’t have the ability to retrieve external webpages. Could you please paste the article’s content here (excluding any code blocks or URLs you’d like to keep unchanged)? Once I have the text, I’ll translate it into Simplified Chinese while preserving the original formatting and markdown.
Overview
我认识的每位开发者都喜欢在终端工作，他们也是最友善的人之一。
在越南，新闻不断报道人口下降的问题，而大多数人想到的解决方案是 Tinder、Bumble 或 Facebook Dating——前两者会收取费用，让你成为它们的产品。
CLI（命令行界面）趋势显而易见——它让集成 LLM/AI 变得轻而易举。我喜欢 CLI 工具：它们轻量、流畅且外观时尚。
那么，为什么不把以上所有想法结合起来，为我们亲爱的软件开发者打造一个在终端运行的正式约会应用呢？
它会有什么成果吗？我不知道。但工程师的精神是没有什么是确定的——我们只能去尝试。
第一个约束：几乎为零的预算
- 没有 VPS，没有托管数据库，没有月度账单。
- 匹配平台仍然需要后端和数据库——用于存储个人资料、进行验证、处理匹配。
- 开支应尽可能低；战争在外，油价仍在飙升。
我花了一段时间思考市场上哪些服务可以填补这些角色，最终灵光一现：GitHub 免费提供了全部功能。
| GitHub 原语 | 可替代的功能 |
|---|---|
| Repository | 存储 |
| GitHub Actions | 事件驱动计算（如 AWS Lambda） |
| Issues（带标签） | API 端点 / 路由 |
| Releases（资产） | CDN / 静态资产 |
当我将架构映射到 GitHub 的原语时，看起来既荒唐又可行：
- 注册 → 一个 Issue 或 PR
- 个人资料验证与加密 → 一个 GitHub Action
- 发现索引 → 一个 Release 资产
由于约会/匹配应用不是实时的，亚毫秒级的延迟并非必需。
去中心化发现
约会应用最根本的功能是 Discovery（发现）。通常这需要一个集中式数据库和后端。
如果我们让每个用户将数据库下载到自己的机器上，并在本地进行排序/匹配会怎样？
两难境地
- 隐私 – 个人资料不能随意公开。
- 发现 不能在加密数据上进行。
- 如果数据库可以下载，任何人都能在几秒钟内抓取完整数据。
传统应用依赖私有服务器、私有数据库、私有排序引擎以及 API 速率限制来防止批量提取。我们希望彻底摆脱集中式服务器——这才是有趣的部分。
链式加密（可验证延迟函数）
我研究了可验证延迟函数和工作量证明方案，最终确定了一种我称之为 链式加密 的设计：
- 想象一串上锁的盒子，每个盒子里都有一个个人资料以及打开下一个盒子的提示。
- 打开一个盒子需要进行几秒钟的暴力计算，没有捷径。
- 合法用户每隔几秒才能看到一个个人资料——符合人类的速度。
- 攻击者也只能以完全相同的速度进行；不存在可以绕过限制的“高级会员”，因为成本已经嵌入了数学模型中。
通过缓存机制可以让重复访问几乎瞬间完成，奖励正常使用，惩罚大规模提取。
工作原理
- 锁的组合 = AES 加密。
- 每个用户会获得三个独立的哈希，用于注册、发现和聊天，这三个哈希通过仅存放在仓库 GitHub Actions secrets 中的秘密盐相连。
- 没有盐的情况下，这些命名空间完全不可关联——浏览个人资料时不会泄露 GitHub 用户名，聊天伙伴也找不到彼此的索引。
id_hash = sha256(pool:provider:user_id) # 64 hex chars
bin_hash = sha256(salt:id_hash)[:16] # 16 hex chars → .bin filename
match_hash = sha256(salt:bin_hash)[:16] # 16 hex chars → chat handle端到端加密聊天中继
- 消息在 离开您的机器之前 进行加密。
- 认证采用 无状态基于时间的签名 加上类似 Merkle 的验证。
- 中继仅转发它无法读取的密文。
- 若服务器被攻破 → 您只能得到加密的二进制块；没有可窃取的内容。
Source: …
工具与技术栈
单个二进制文件，无需应用商店，也不需要网页托管，只需两个命令：
brew install vutran1710/tap/op
opTUI（终端用户界面）负责引导、发现以及使用配有深色主题的聊天界面。
- 语言：Go
- UI 框架：Bubble Tea + Lip Gloss（值得获得比现在更多的关注）
架构图
┌──────────┐ ┌──────────────────┐ ┌─────────────┐
│ CLI/TUI │──────▶│ Pool Repo │ │ Registry │
│ (Go) │ │ (GitHub) │◀─────▶│ (GitHub) │
│ │ │ pool.yaml │ └─────────────┘
│ │ │ users/{h}.bin │
│ │ │ matches/ │
│ │ └──────────────────┘
│ │ ▲
│ │──────▶┌───────┴───────────┐
│ │ │ Relay Server │
└──────────┘ │ (per‑pool) │
└──────────────────┘中继服务器 – 唯一的后端成本
最终不可避免地需要使用中继，这意味着系统在传统意义上并非 100 % 无后端。然而，它仍然 极小：
- GitHub 充当数据库。
- GitHub Actions 充当主要后端（验证、加密、索引）。
- 中继服务器 是唯一需要付费的组件——它是一个愚蠢的、无状态的消息路由服务。
由于 Go 的特性，中继可以非常小、托管成本低，并且在需要时可以水平扩展。
结束语
工程师的精神是敢于尝试，即使前景不明。通过利用免费的 GitHub 原语、可验证延迟链加密方案以及一个最小的基于 Go 的中继，我们可以构建一个以终端为首的约会应用，尊重隐私，几乎零成本，并为开发者提供一种有趣、以 CLI 为中心的相互认识方式。
试一试，动手改造，让社区决定这个荒诞的想法是否能成为有用的工具。祝编码愉快！
Overview
它可以相当好且低成本地处理负载——直到池子运营者意识到他实际上可以将自己的池子变现。
在发现过程中的“磨合”延迟实际上让浏览变得更有目的性；当每个个人资料都需要几秒钟时，你无法盲目滑动。
最后，匹配引擎意外地成为通用的：模式仅是 YAML，所以任何人都可以分叉此模板，运行招聘板、学习小组查找器或自由职业者市场，而无需任何代码更改。
配置
name: "标签
#go #golang #opensource #cli #terminal #cryptography #decentralized #privacy #sideproject