Nostr NIPs uitgelegd: de specificatiedocumenten van het protocol

Nostr's evolutie gebeurt via NIPs, korte specificatiedocumenten die iedereen kan voorstellen. Als je wilt begrijpen hoe nieuwe features zoals zaps of versleutelde DM's in het protocol komen, dan zijn NIPs het antwoord.

Deze gids behandelt wat NIPs zijn, hoe ze als governance-mechanisme werken, en welke je moet lezen als je technisch wordt.

NIPs zijn korte markdown-documenten op GitHub die voorstellen hoe je Nostr-features implementeert. Client-ontwikkelaars kiezen welke zij ondersteunen. Een NIP wordt "echt" wanneer genoeg implementeerders het aannemen. De kernset van veelgebruikte NIPs is ongeveer 30; de volledige lijst loopt dichter naar 100.

Als je er klaar voor bent, claim je @nostr.blog-adres →

Wat een NIP eigenlijk is

Een NIP is een markdown-bestand in de github.com/nostr-protocol/nips-repository. Elk bestand beschrijft een specifieke feature, format of conventie: hoe je events ondertekent, hoe een profileermetadata-event eruitziet, hoe je een direct bericht verzendt, welk format Lightning zap-verzoeken gebruiken.

De omvang varieert. De kortste NIPs zijn minder dan een pagina; de langste zijn enkele duizenden woorden. De meeste zitten rond de 500 tot 2000 woorden. Ze worden geschreven om vanuit de spec alleen implementeerbaar te zijn, dus ze bevatten berichtformaten, verplichte velden en voorbeeld-events.

De naamconventie is NIP-XX waarbij XX een getal is. Getallen worden toegewezen wanneer de NIP wordt samengevoegd; ze weerspiegelen niet prioriteit of belang. NIP-05 gaat over geverifieerde identificatie; NIP-04 is de oudere DM-standaard; NIP-01 is het kernprotocol. De nummers volgen de volgorde van voorstellen, niet het belang van features.

Waarom "Implementation Possibilities"

De naam is een bewuste keuze. Vergelijk met andere specificatietradities.

• RFC's (Requests for Comments) in internetprotocollen worden vaak verplicht voor interoperabiliteit.
• EIP's (Ethereum Improvement Proposals) worden vaak verplicht via netwerkupgrades.
• NIPs zijn permanent optioneel. Een client die 40 NIPs implementeert en een client die 10 NIPs implementeert zijn beide geldige Nostr-clients; ze doen alleen verschillende deelverzamelingen van dingen.

Dit betekent dat NIPs nooit bestaande implementaties "breken". Een nieuwe NIP voor een feature dwingt niet af dat oudere clients veranderen. Het protocol groeit aan de randen terwijl de kern stabiel blijft.

De NIP-levenscyclus

Hoe een nieuwe NIP tot stand komt:

1. Iemand merkt een gat of behoefte op. "We hebben geen standaardmanier om X te doen." Zou een client-ontwikkelaar, relay-operator of gebruiker kunnen zijn die gefrustreerd is over een specifiek probleem.
2. Ze schrijven een concept. Het format volgt bestaande NIPs: titel, doel, specificatie, voorbeelden.
3. Ze dienen een pull request in bij de NIPs-repository.
4. Community review. Ontwikkelaars, relay-operators en geïnteresseerde gebruikers reageren. Het concept wordt herzien op basis van feedback.
5. Samenvoegen of verlaten. Samengevoegde NIPs krijgen een nummer en worden onderdeel van de repository. Verlaten concepten staan in de pull request-geschiedenis.
6. Implementatie volgt (of niet). Sommige NIPs worden binnen weken geïmplementeerd. Sommige wachten jaren. Sommige worden nooit veel geïmplementeerd.

Het proces is licht. Geen commissievotingen, geen formale goedkeuring. Als de pull request breed positieve feedback krijgt en aan een duidelijke behoefte voldoet, wordt het samengevoegd.

NIPs die belangrijk zijn als je gebruiker bent

De meeste NIPs zijn onzichtbaar voor gebruikers. Een handvol beïnvloedt je dagelijkse ervaring:

• NIP-01: Kernprotocol. Hoe events zijn gestructureerd en ondertekend. Je ziet het nooit, maar alles hangt ervan af.
• NIP-05: Geverifieerde identificatie. Geeft je jij@domein.nl leesbare namen. Onze NIP-05 gids behandelt het.
• NIP-07: Browserextensie ondertekening. Laat webclients ondertekenen zonder je privésleutel te zien.
• NIP-19: Bech32-codering. Waarom je openbare sleutel eruitziet als npub1... in plaats van raw hex.
• NIP-23: Langformaartigelen. Maakt blogstijlberichten op Nostr mogelijk.
• NIP-44: Versleutelde DM's. De moderne directe berichtstandaard (beter dan de oudere NIP-04).
• NIP-57: Zaps. Lightning-tips met openbare ontvangstbewijzen.
• NIP-98: HTTP-authentificatie. Laat Nostr-identiteiten zich authentificeren bij normale websites.

Als gebruiker profiteer je van al deze zonder ermee te interageren. Clients verwerken de protocoldetails.

NIPs die belangrijk zijn als je ontwikkelaar bent

Als je een Nostr-client schrijft of onderhoudt, groeien de NIPs die je moet lezen naar tientallen:

• NIP-01 tot NIP-10 (kernmechanismen).
• NIP-11 (informatiedocumenten voor relays).
• NIP-13 (proof of work, voor spamverzet).
• NIP-17 (cadeauverpakte DM's voor metadataverhulling).
• NIP-22 (event-verloopdatum).
• NIP-27 (verwijzingen naar tekstnota's).
• NIP-30 (aangepaste emoji).
• NIP-31 (event-soorten).
• NIP-33 (geparametriseerde vervangingsbare events).
• NIP-42 (authenticatie van verbindingen met relays).
• NIP-47 (Nostr Wallet Connect).
• NIP-50 (zoekcapaciteit).
• NIP-65 (metagegevens van relaylijst).
• NIP-78 (willekeurige aangepaste app-gegevens).

Dit zijn de meest implementeren door mainstream clients. Een client die deze set plus de hierboven genoemde op gebruikers gerichte NIPs ondersteunt, dekt 95% van typisch gebruik.

Een NIP lezen

Als je er direct een wilt lezen, de repository staat op github.com/nostr-protocol/nips. De structuur van de meeste NIPs:

• Titel en beschrijving. Wat de NIP voorstelt.
• Motivatie. Waarom de feature nodig is.
• Specificatie. Exact berichtformat, verplichte velden, validatieregels.
• Voorbeeld-events. Concrete JSON die toont hoe een voldoend event eruitziet.
• Client/relay-gedrag. Hoe implementaties de events moeten verwerken.

NIPs worden geschreven om leesbaar te zijn voor ontwikkelaars die ze implementeren. De specificatiesectie is de belangrijke; dit is waar het echte protocol leeft.

NIPs met gedeeltelijke acceptatie

Sommige NIPs bestaan maar worden inconsistent over clients geïmplementeerd. Dit creëert edge-cases waarbij je ervaring per client verschilt.

NIP-44 (versleutelde DM's). Aangenomen door Damus, Primal, Amethyst en de meeste grote clients in 2024-2025. Sommige oudere clients ondersteunen alleen NIP-04. Als je iemand een bericht stuurt wiens client alleen NIP-04 ondersteunt, falen je NIP-44-berichten stilzwijgend. Het praktische antwoord: gebruik een moderne client en hoop dat je correspondent hetzelfde doet.

NIP-17 (cadeauverpakte DM's). Metadataverhullende DM's. De acceptatie in 2026 groeit maar is niet universeel. De feature is geweldig waar beide partijen' clients het ondersteunen; anders valt het stilzwijgend terug naar minder privacybescherming DM's.

NIP-46 (remote signers). Laat een hardwaresigner of bunker-app events namens een client ondertekenen. Ondersteund in Amethyst, partieel elders.

NIP-65 (relaylijst van gebruiker). Laat gebruikers hun voorkeur relays publiceren zodat clients automatisch naar de juiste plaatsen kunnen routeren. De acceptatie verbetert; oudere clients negeren het.

NIP-50 (zoeken). Laat clients relays opvragen voor tekstovereenkomsten. Sommige relays ondersteunen het; veel niet. De zoekingskwaliteit is inconsistent.

Controleren welke NIPs een bepaalde client ondersteunt is een nuttig diagnostisch hulpmiddel wanneer iets niet werkt zoals verwacht. De meeste clients publiceren hun NIP-ondersteuningsmatrix in hun documentatie.

Hoe het NIP-process het protocol coherent houdt

Geen centrale autoriteit, dus coherentie komt van sociale dynamica. Een paar opmerkingen:

Slechte NIPs verspreiden zich niet. Een voorstel dat een bestaande NIP dupliceert of het verkeerde probleem oplost, krijgt minimale acceptatie en verdwijnt stil. De community is niet formeel maar wel stellig.

Goede NIPs worden onafhankelijk geïmplementeerd. Meerdere client-ontwikkelaars lezen voorstellen en beslissen onafhankelijk. Goede ideeën accumuleren aannemers; slechte ideeën niet.

Concurrerende NIPs kunnen soms ontstaan. Twee verschillende voorstellen voor dezelfde feature kunnen voor een tijd naast elkaar bestaan. Meestal wint er één in praktijk omdat meer clients het implementeren; soms fuseren ze.

Fork-compatibele evolutie. Omdat NIPs optioneel zijn, kan een client NIP-X-v1 implementeren en later upgraden naar NIP-X-v2 zonder iedereen die alleen v1 ondersteunt te breken. Het protocol splitst niet.

Dit is rommelig maar functioneel. Het protocol is in vijf jaar aanzienlijk geëvolueerd zonder een centrale governance-instantie omdat het sociale mechanisme van "implementeerders lezen, implementeerders beslissen, implementeerders coderen" genoeg afstemming heeft om coherentie voort te brengen.

Je eigen NIP voorstellen

Als je een idee hebt voor een nieuwe Nostr-feature:

1. Controleer eerst de NIPs-repository. Iemand kan het al hebben voorgesteld.
2. Indien niet, open een GitHub-issue waarin je het probleem beschrijft dat je oplost.
3. Op basis van feedback, schrijf je een volledige NIP volgens het bestaande format.
4. Dien een pull request in.
5. Neem deel aan discussie. Wees bereid om te herzien.
6. Als het wordt samengevoegd, geweldig. Zo niet, het probleem kan een beter oplossing hebben; overweeg waarom.

Niet elk goed idee wordt een NIP. Niet elk NIP wordt een feature. Het ecosysteem heeft meer voorstellen dan elke enkele ontwikkelaar zou kunnen volgen, en het filter is "implementeert genoeg van de community het." Dat filter is de kern van hoe Nostr coherent blijft zonder top-down te zijn.