Peering: owner-attested peering requests — the operator co-signs, staking their reputation
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 功能
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- typescript
- 领域
- backend, networking, security
调研方向
This is part of the peering work in #931 and builds on peer identity in #933; the issue does not name implementation files or tests. Read those issues and the relay's existing peering and NIP-42 AUTH entry points first. Done means implementing and verifying owner-signed requests, matching the request identity to the AUTH identity, acceptance records, receiver policy and PoW behavior, while keeping operational flows relay-key actions.
由索引模型根据 Issue 内容生成。
描述
Part of the relay peering work in #931. Builds on the peer identity work in #933.
Idea
A relay keypair is free to mint and carries no history: a relay that abuses a feed can burn its key and return under a fresh one at zero cost. The relay owner's personal key is the opposite — it carries the operator's public reputation and web of trust. So a peering request should be co-signed by the owner: the relay asks, and a person with something to lose guarantees the asking. The budget (see #938) caps what a bad peer can cost financially; the owner's attestation is the social collateral for behavior.
Scope
- Peering request event. Define an event, signed by the relay owner's key, that requests peering and names: the relay's own pubkey (its
selfidentity), the relay URL, the requested scope, and the terms being accepted (the advertised terms, or a hash/snapshot of them — so the agreement can't drift silently when the NIP-11 document changes later). - Two-part verification at establishment. The receiving relay verifies (a) the request event: valid owner signature, and (b) live proof: the relay key named in the request is the one that authenticates the connection via NIP-42 AUTH (#933). Attestation is the long-lived record; AUTH is the session proof. Both are required for the attested path.
- Acceptance record. The receiving relay may answer with its own signed acceptance referencing the request, so both sides hold a non-repudiable record of who agreed to what, on which terms.
- Establishment only. The owner's signature covers the initial request and material changes (scope, terms). It is never required for operations — invoices, renewals, event requests stay relay-key actions under the budget — or auto-pay would require the operator to hand-sign routine traffic.
- Proof-of-work on the request. The request event carries NIP-13 proof-of-work meeting the minimum the receiving relay advertises in its peering section (see #932) — receiver-set, and waivable for pre-configured peers. Roles stay clean: the relay grinds the nonce (the event must be assembled before signing, and compute is the relay's to spend), the owner signs the result — each party pays in their own currency. PoW's job is narrow: triage and costly signaling for unsolicited requests, where the scarce resource is the receiving operator's attention. It is not an anti-spam mechanism for operations (budgets and peer rate limits do that), never a substitute for the owner's attestation (a GPU out-grinds an honest small relay), and it is never required on operational messages.
- Policy knob, not a mandate. The receiving relay configures whether owner attestation is required, preferred, or waived. Manually configured peers (the v1 trust path in #931) keep working without it; pseudonymous operators are not excluded by the base design, and reputation-based peering can grow where operators choose to demand it.
Acceptance
- A peering request can be produced and verified end-to-end: owner signature valid, relay pubkey in the request matches the AUTH identity on the connection, terms snapshot matches what was advertised at request time.
- A relay configured to require attestation does not establish peering from an unattested or mismatched request; a relay configured to waive it still can.
- A request whose PoW is below the receiver's advertised minimum is deprioritized/rejected per the receiver's policy; a request from a pre-configured peer is accepted without PoW when the receiver waives it.
- No operational flow (invoice payment, renewal, event request) ever requires the owner's key.
- 主要语言
- TypeScript
- 星标
- 829
- 派生
- 234
- 平均合并
- 17 小时 6 分钟
- 30 天内合并 PR
- 92
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
cameri/nostream 的其他 Issue
-
factory rewrite rust
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
factory rewrite rust
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
test: user-subscription specs fail outside UTC, so the pre-commit hook cannot pass可能已有人在做 @tejasvasingh2004 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
bug factory rewrite rust
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
bug factory rewrite rust
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
相似的 Issue
-
a10y a10y-audit ai-driven-qa claude
难度 2/5 1-3 小时 新手友好度 86/100
linagora/twake-directory-manager#219 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
type: bug
难度 2/5 1-3 小时 新手友好度 79/100
维护者通常 1 天内回复
-
0️⃣ phase/new
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
Pulse v7: buildPreferencesFromTelos() bypasses telosSectionOrFile(), renders empty on unified-TELOS installs可能已有人在做 @zephyr91 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
danielmiessler/LifeOS#2393 ·
维护者通常 4 天内回复