Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#940 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend, networking, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
829
Forks
234
Merge medio
17 h 40 min
PR fusionados (30 d)
90

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de cameri/nostream

Todos los issues de cameri/nostream

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.