Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#940 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
typescript
Domaine
backend, networking, security

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
TypeScript
Étoiles
829
Forks
234
Merge moyen
16 h 57 min
PR mergées (30 j)
76

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cameri/nostream

Toutes les issues de cameri/nostream

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.