将隐私视为严格约束条件来设计仅限Tor的服务
你好，HN，
我正在开发OnionLab，这是一个围绕严格约束构建的实验性服务生态系统：
所有面向用户的服务仅通过Tor（.onion）访问。清网仅用于发布静态的官方信息。
这样做并不是因为Tor是一种“特性”，而是因为将隐私视为一个硬性约束可以简化某些设计决策，同时使其他决策变得明确。
通过承诺仅限Tor访问，我们有意避免：
- 基于IP的假设
- 用户追踪或画像
- 通过账户或社交图谱绑定身份
相反，我们专注于：
- 最小化和明确的状态
- 仅在严格必要时使用短暂的会话状态
- 使用加密验证（PGP）而不是身份声明
- 采用仅附加记录而非可变历史
一个例子是OnionLab Trust，它记录PGP密钥持有者声明的引用（例如，URL、洋葱服务、外部账户标识符）。
Trust并不验证所有权、合法性或真实性。它仅保证某个引用是由特定PGP私钥的持有者注册或更新的。
我们的目标不是创造权威，而是让其他人能够观察到随着时间推移的连续性和意图，而不削弱匿名性。
我在这里分享这些，不是作为产品发布，而是作为一个具体的探索，展示当隐私被视为不可妥协的要求时，服务设计的样子。
我很想听听那些构建了仅限Tor系统的人，或者那些考虑过这种方法但最终决定放弃的人。
感谢阅读。
查看原文
Hi HN,<p>I’m working on OnionLab, an experimental ecosystem of services built around a strict constraint:<p>All user-facing services are accessible exclusively via Tor (.onion).
Clearnet is used only to publish static, official information.<p>This is not because Tor is a “feature”, but because treating privacy as a hard constraint
simplifies some design decisions while making others explicit.<p>By committing to Tor-only access, we intentionally avoid:
- IP-based assumptions
- user tracking or profiling
- identity binding through accounts or social graphs<p>Instead, we focus on:
- minimal and explicit state
- short-lived session state only where strictly required
- cryptographic verification (PGP) rather than identity claims
- append-only records instead of mutable histories<p>One example is OnionLab Trust, which records references
(e.g. URLs, onion services, external account identifiers)
declared by PGP key holders.<p>Trust does not verify ownership, legitimacy, or truth.
It only guarantees that a reference was registered or updated
by the holder of a specific PGP private key.<p>The goal is not to create authority, but to allow others to observe
continuity and intent over time without weakening anonymity.<p>I’m sharing this here not as a product launch,
but as a concrete exploration of what service design looks like
when privacy is treated as a non-negotiable requirement.<p>I’d be interested in hearing from people who have built Tor-only systems,
or who considered this approach and decided against it.<p>Thanks for reading.