NIP-11 definieert hoe relays een machineleesbare beschrijving van zichzelf publiceren, inclusief geclaimde feature support, limieten en metadata van de beheerder.

Hoe Het Werkt

Clients halen relay-informatie op door een HTTP GET-request te doen naar de WebSocket-URL van de relay met een Accept: application/nostr+json-header. De relay retourneert dan een JSON-document dat zijn mogelijkheden beschrijft.

Useful Fields

  • name - Menselijk leesbare relay-naam
  • description - Waar de relay voor bedoeld is
  • supported_nips - Lijst met geclaimde NIP-support
  • limitation - Beperkingen zoals maximale berichtgrootte, vereiste authenticatie, enzovoort
  • pubkey - Public key van de relay-operator, als die is opgegeven
  • contact - Contactadres van de operator

Trust Model

NIP-11 is zelfgerapporteerde metadata. Het vertelt je wat een relay over zichzelf zegt, niet wat die in live verkeer heeft bewezen. Dat is nog steeds nuttig voor discovery en UX, maar clients moeten supported_nips niet als grondwaarheid behandelen zonder gedrag te testen.

Dit onderscheid is belangrijk voor relayselectie. Een relay kan NIP-50 search, authentication requirements of een grote message limit adverteren, maar het echte antwoord zie je pas wanneer een client daadwerkelijk verbinding maakt en die codepaden gebruikt.

Waarom Het Belangrijk Is

  • Clients kunnen controleren of een relay vereiste features ondersteunt voordat ze verbinding maken
  • Discovery-services kunnen relay-capaciteiten indexeren
  • Gebruikers kunnen relay-beleid bekijken voordat ze publiceren

Recent Spec Direction

De specificatie is in de loop van de tijd teruggesnoeid. Oudere optionele velden zoals software, version, details van privacybeleid en retention metadata zijn verwijderd na jaren van zwakke adoptie. Daardoor zijn huidige NIP-11-documenten kleiner en realistischer, maar het betekent ook dat clients geen rijke beleidsmetadata van relays moeten verwachten.

PR #2318 stelt voor een optioneel access_control-object toe te voegen aan het relay information document, met daarin de gating mode van de relay (open, invite, payment, allowlist) en elk endpoint dat een client kan gebruiken om toegang aan te vragen. Het veld is alleen adviserend bedoeld, zodat clients en directories gated relays uit publieke discoverylijsten kunnen filteren en gebruikers vooraf kunnen tonen waarom een relay writes weigert.

Implementaties

Primaire bronnen:

Vermeld in:

Zie ook: