Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Peering: owner-attested peering requests — the operator co-signs, staking their reputation

Aberta
  • Algo errado?
#940 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
typescript
Domínio
backend, networking, security

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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 self identity), 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.
Linguagem predominante
TypeScript
Estrelas
829
Forks
234
Merge médio
17h 40min
PRs com merge (30d)
90

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de cameri/nostream

Todas as issues de cameri/nostream

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.