Het Nostr-protocol, uitgelegd in eenvoudig Nederlands

Een protocol is een reeks regels voor hoe programma's met elkaar communiceren. Een platform is een bedrijf dat die programma's namens je uitvoert. Twitter is een platform. E-mail is een protocol. Nostr is een protocol.

Het onderscheid is belangrijk omdat protocollen en platforms verschillende foutmodi, verschillende kostenstructuren en verschillende toekomsten hebben. Deze gids legt uit wat Nostr specifiek tot een protocol maakt, wat dat in de praktijk betekent, en waarom het ontwerp opzettelijk klein blijft.

TL;DR. Nostr is een pub/sub-berichtprotocol met cryptografische handtekeningen. Het definieert een klein event-formaat en een eenvoudige manier voor clients om die events via relays te verzenden en ontvangen. Geen bedrijf bezit het. Iedereen kan een client schrijven, een relay uitvoeren of extensies voorstellen. De kernspec past op een paar pagina's.

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

Wat een protocol werkelijk is

E-mail is een goed vergelijkingspunt. Wanneer je een e-mail van Gmail naar Outlook stuurt, heeft Gmail geen toestemming van Outlook nodig. Beide services spreken SMTP (het e-mailprotocol), en SMTP definieert alles wat nodig is om één mailserver een bericht aan een ander over te handigen. De servers zijn van verschillende bedrijven. Het protocol is een neutraal akkoord.

Nostr werkt op dezelfde manier. Een Nostr event (een post, een like, een volgen) is een JSON-object met een specifieke vorm die in het protocol is gedefinieerd. Een relay is elke server die akkoord gaat met het accepteren, opslaan en doorsturen van events die conform die vorm zijn. Twee clients die Nostr spreken kunnen via elke relay die Nostr spreekt met elkaar interageren, ongeacht wie een van de drie heeft gemaakt.

Het protocol is een neutraal akkoord. De implementaties kunnen van alles zijn.

De Nostr-spec in de minste zinnen

Drie regels dekken bijna alles.

1. Een event is een JSON-object met id, pubkey, created_at, kind, tags, content, sig. De id is een hash van de andere velden; de sig is een Schnorr-handtekening over de id met behulp van de private tegenhanger van de pubkey.
2. Een relay accepteert geldige events via WebSocket en serveerde abonnementen die events filteren op auteur, kind, tag of tijd.
3. Een client ondertekent events en publiceert ze naar relays; leest events door zich aan relays met filters in te schrijven.

Dat is het kernprotocol. Elke geavanceerde functie (langdurige artikelen, zaps, DM's, gemeenschappen, lijsten) is een extensie die in dit kader past zonder het te veranderen.

Waarom het protocol klein blijft

De meeste protocollen groeien door accumulatie. Elk use-case voegt aan de spec toe; elk decennium is de spec groter dan het decennium daarvoor. HTTP is nu honderdtallen pagina's. E-mail groeide van een handvol RFC's naar een wirwar. Nostr heeft dit bij voorbaat vermeden.

Het mechanisme zijn NIPs (Nostr Implementation Possibilities). Nieuwe functies worden niet aan de kernspec toegevoegd; ze worden voorgesteld als optionele NIPs. Clients implementeren de NIPs waar ze om geven. Andere clients negeren ze. Een populaire NIP wordt onderdeel van het praktische protocol omdat genoeg implementaties het spreken; een onpopulaire NIP verdwijnt zonder veel ophef.

Dit betekent dat de kern voor altijd klein is (de belangrijke invarianten: ondertekende events, open relays, draagbare identiteit) en de randen voor altijd flexibel zijn (nieuwe functies evolueren zonder bestaande clients te breken). Een Nostr-client uit 2022 werkt nog steeds in 2026 omdat de kern niet is veranderd; hij doet alleen minder dingen dan nieuwere clients.

Protocol versus platform, concreet

Vijf praktische verschillen die je als gebruiker voelt.

Identiteit. Op een platform is je account eigendom van het bedrijf. Op een protocol is je account een cryptografische identiteit die je bezit. Niemand kan het je afnemen.

Gegevens. Op een platform zijn je posts aanwezig in hun database. Op een protocol zijn je posts aanwezig op meerdere onafhankelijke relays. Als er één verdwijnt, hebben de anderen ze nog steeds.

Feature-snelheid. Op een platform worden functies uitgebracht wanneer het bedrijf dat besluit. Op een protocol worden functies uitgebracht wanneer een implementeerder ze schrijft. Dit is in sommige opzichten langzamer (geen centraal stappenplan) en in andere opzichten sneller (veel experimenten parallel).

Geldverdienmodel. Op een platform vangt het bedrijf alle inkomsten. Op een protocol is geldverdienmodel wat gebruikers en implementeerders overeenkomen. Nostr heeft zaps (peer-to-peer tips via Lightning) omdat dat in de cultuur paste; een ander protocolcommunity zou tot andere normen kunnen komen.

Foutmodus. Een platform kan helemaal verdwijnen. Een protocol kan niet; zolang één implementeerder actief blijft, leeft het protocol. Nostr is ontworpen zodat zelfs als fiatjaf (de oorspronkelijke auteur) morgen zou verdwijnen, het netwerk zonder verandering zou doorgaan.

Wat het protocol opzettelijk niet doet

Vijf dingen die opzettelijk uit de spec zijn gelaten.

Moderatie. Het protocol bepaalt niet welke inhoud acceptabel is. Elke relay heeft zijn eigen regels; elke client heeft zijn eigen filters; elke gebruiker heeft zijn eigen muteerbankje. Moderatie vindt plaats aan de randen, niet in de kern.

Zoeken. Er is geen protocol-gedefinieerd zoeken. Sommige relays indexeren tekst; anderen niet. Clients die zoeken willen vertrouwen ofwel op zoekbare relays ofwel voeren hun eigen indexering uit. De afwezigheid is opzettelijk; het houdt het protocol neutraal over wat wordt gevonden.

Rangschikking. Geen "Voor jou"-feed. Geen betrokkenheidsweging. Clients geven events standaard op timestamp weer; elke andere ordening is een client-level-beslissing, geen protocol-level.

Ontdekking. Geen aanbevelingsmotor. Nieuwe accounts om te volgen vinden is een client-functie, geen protocol-functie. Sommige clients investeren zwaar hierin (Primal); anderen laten het aan gebruikers over (Damus).

Herstel. Geen account-reset. Verlies de private sleutel, verlies het account. Het protocol zou sleutelrotatie kunnen bevatten maar doet het niet, omdat de afwegingen reëel zijn en de gemeenschap nog niet op een specifiek mechanisme is overeengekomen. Dit is een lopend gebied (NIP-26, NIP-41-concepten).

Elke omissie is een keuze. Protocollen blijven klein door elke mogelijke uitdaging niet op protocolniveau op te lossen.

Wie bepaalt wat Nostr wordt

Niemand en iedereen.

Er is geen Nostr Foundation. Geen bedrijfsgroep. Geen stuurcomité. De meest geconcentreerde autoriteit ergens in het ecosysteem is fiatjaf's GitHub-repo waar NIPs worden voorgesteld, en zelfs dat is slechts een coördinatieplaats, geen poortwachter.

Voorgestelde NIPs worden gelezen door clientontwikkelaars. Populaire krijgen geïmplementeerd. Een NIP die drie grote clients implementeren is in feite onderdeel van het protocol; een NIP die één ontwikkelaar schreef maar waar niemand anders om geeft, is gewoon een document op GitHub.

Dit proces is rommelig. Er zijn coördinatiproblemen, dubbele voorstellen en occasionele politiek. Het is ook op een specifieke manier veerkrachtig: geen enkele partij kan het verpesten door een slecht besluit te nemen, omdat slechte besluiten gewoon niet worden aangenomen. Het protocol ontwikkelt zich in grove richtingen door het gewicht van ontwikkelaarskeuzes, niet door bevel.

Wanneer het protocolmodel wint

Protocollen verslaan platforms in specifieke omstandigheden:

• Wanneer eigendom meer uitmaakt dan glans. Protocollen zijn meestal minder glanzend dan platforms. Ze winnen wanneer je voordeel haalt uit wat de glans niet kan geven je (permanente identiteit, censuurbestendigheid, open interoperabiliteit).
• Wanneer het netwerkeffect de feature is. De waarde van een protocol groeit met adoptie door implementeerders, niet alleen gebruikers. Meer clients en relays maken het netwerk op manieren sterker die een platform niet kan nabootsen.
• Wanneer de lange termijn uitmaakt. Platforms worden gekocht, verkocht, gesloten of draaiing veranderd. Protocollen overleven elke implementeerder. E-mail is ouder dan de meeste bedrijven; Nostr zet in op dezelfde dynamiek.

Als je use-case niet aan een van deze criteria voldoet, is een platform meestal sneller en gemakkelijker. Dit is eerlijk. Nostr is niet universeel beter dan Twitter voor elk mogelijk gebruik. Het is beter op de specifieke manieren waarop een protocol een platform verslaat.

De echte spec lezen

Als deze gids je in de zin kreeg om het protocol direct te lezen, heeft de NIPs repository de volledige lijst. NIP-01 is de kern; de genummerde NIPs erna zijn extensies. Je hoeft er geen van te begrijpen om Nostr te gebruiken, maar het lezen van NIP-01 duurt ongeveer tien minuten en verduidelijkt veel.