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
-
[good first issue, hacktoberfest] 🏯 Hacktoberfest Task - Add new Japan Fact 898 (good-first-issue)未關閉community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
難度 1/5 1 小時以內 新手友好度 86/100
lingdojo/kana-dojo#33145 · 1 則留言 · 5 個 reaction ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 76/100
code-yeongyu/senpi#4278 ·
維護者通常 1 天內回覆
-
[Bug] Activity | The activity list ignores taskIds and returns the activities of every task可能已有人在做 @NdekoCode 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 78/100
ever-co/ever-gauzy#11469 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 75/100
griffinwork40/agent-afk#4408 ·
維護者通常 1 天內回覆