Welkom terug bij Nostr Compass, jullie wekelijkse gids voor Nostr.

Deze week: Shopstr houdt geheimen van remote signer en wallet buiten de browseropslag, Routstr SDK verifieert providerontdekking die van relays komt, Postr komt uit als kleine Android-composer, Infans versleutelt gezinsregistratie en synchronisatie tussen ouders, walls.rip vervoert met PGP versleutelde chat over publieke Nostr-relays, en pakstr maakt publicatie naar Zapstore expliciet. nostr-tools bindt gift-wrap-rumors aan hun seals. Releases dekken isolatie van subscriptions, profielstatussen en per relay begrensde vertrekmarkeringen. Het protocolwerk bereikt de uitrol van commentaarthreads, concepten voor een kostenplafond en betalingsopvraging in wallet connect, verzoeken om displays voor napplets, en een experimentele aanmelding vanaf hetzelfde account. Het nummer sluit af met Zes jaar Nostr in augustus.

Topverhalen

Postr komt uit als kleine Android-composer

Postr is een opzettelijk kleine Android-composer voor kind 1-notes. Het beheer van de privésleutel blijft in Amber, een Android-NIP-55- (lokale signer) en NIP-46-signer. Versie 1.0.0 levert een duurzame outbox die verlies van connectiviteit en het afsterven van het proces overleeft, accountspecifieke privéconcepten, en Blossom-bijlagen met geverifieerde hashes en begrensde uploadautorisatie.

Een bericht slaagt pas nadat Postr het identieke ondertekende event terugleest en de signature controleert. Nieuwe pogingen houden hetzelfde event-id. De publicatie gebruikt de schrijfrelays uit de NIP-65-lijst (relaylijst) van de auteur plus versleutelde bootstrap-relays, of een eigen lijst per account. Een ondertekende NIP-34- (git over Nostr) repository-aankondiging en een bijbehorend kind 0-projectprofiel worden gepubliceerd op relay.ngit.dev. Feeds, analytics, advertenties en sleutelopslag blijven buiten de app.

Infans versleutelt gezinsregistratie en synchronisatie tussen ouders over Nostr

Ouders kunnen gegevens over voeding, slaap en groei op hun eigen telefoon houden en delen zonder leverancier van gezinsdata. Infans is een Android-babytracker die een lokale Room-database als bron van waarheid behandelt en versleutelde kind 30078-events van NIP-78 (applicatiespecifieke data) publiceert voor back-up en synchronisatie met de partner. De repository noemt de lokale versleuteling NIP-44 (payloadversleuteling), maar de implementatie gebruikt AES-256-GCM terwijl NIP-44 v2 ChaCha20 met HMAC-SHA256 vereist, dus payloads in lokale modus zouden niet als NIP-44-compatibel gepresenteerd moeten worden.

De partnersynchronisatie gebruikt d-tag baby-tracker-sync, terwijl eigen back-ups baby-tracker-backup gebruiken. Asynchrone notities reizen binnen de payload van de partner. Het gedocumenteerde Amber-NIP-55-pad (lokale signer) delegeert ondertekenen en versleutelen aan de signer, maar de repository levert geen interoperabiliteitstest die aantoont dat elk back-up- en synchronisatiepad NIP-44-v2-ciphertext oplevert. De repository presenteert geen claim als medisch hulpmiddel en geen externe beveiligingsaudit.

Ghost Chat van walls.rip brengt met PGP versleutelde chat naar publieke Nostr-relays

walls.rip is een gereedschapskist voor anonieme communicatie waarvan de Ghost Chat-modus een OpenPGP-identiteit in de browser aanmaakt of importeert. De opensourceclient versleutelt elk bericht met de publieke PGP-sleutel van de ontvanger. Het leesbare gesprek blijft in de lokale sessieopslag op het apparaat; de applicatie heeft geen chataccount en geen centrale berichtendatabase.

Het transport is echt Nostr, maar het is opzettelijk app-specifiek. Ghost Chat publiceert armored ciphertext als kind 1-events naar vijf standaardrelays en labelt elk event met een stabiele kamertag die is afgeleid van de PGP-vingerafdruk van de ontvanger. Dat geeft ontwikkelaars een concreet voorbeeld van relays als censuurresistent berichtentransport, en laat tegelijk zien waarom gedecentraliseerde bezorging alleen geen metadata beschermt en niet interoperabel is met NIP-17-directberichten.

pakstr 0.13.0 tot 0.15.0 maakt publicatie naar Zapstore expliciet

Na het pakket- en Amber-werk van 0.3.1 in juli is pakstr een CLI die een map met webbestanden omzet in een ondertekende Android-APK en die met een Nostr-sleutel naar Zapstore publiceert. 0.13.0 voegt automatische releaseversienummering toe. De opvolgers 0.13.1 tot 0.13.3 repareren publicatie naar Blossom: autorisatie gebruikt nu base64url, uploads dragen een Content-Digest, en het Zapstore-applicatie-event wordt gepubliceerd voor de Blossom-upload.

0.14.0 valideert de Zapstore-uitgever voordat een publicatie doorgaat. 0.15.0 schrijft vermeldingsmetadata naar kind 32267-applicatie-events en zet releasenotities in de content van kind 30063-release-events, zodat de Zapstore-vermelding van een verpakte app naam, samenvatting en notities kan dragen zonder een aparte handmatige stap.

Heterodyne specificeert portabele persona’s en versleutelde sociale communicatie

Heterodyne is een specificatiegerichte protocolfamilie voor portabele persona’s, geauthenticeerde communicatie, controle over het eigen apparaat en sociale interactie. De huidige README stelt vier bestaande lagen samen: ondertekende Nostr-events, Radicle (peer-to-peer git) als duurzame opslag, Marmot (MLS-groepsberichten over Nostr) voor versleutelde directe en groepsgesprekken, en KERI-sleutelgebeurtenislogboeken (Key Event Receipt Infrastructure) voor identiteitsrotatie. Een persona wordt beschreven als een Nostr-npub met koude root plus een aanvaard KERI-logboek; routinematig ondertekenen gebruikt roterende epochsleutels, terwijl Radicle-node-identiteiten met dubbel bewijs worden gedelegeerd.

De familie splitst dat werk in vier onafhankelijk geversioneerde 0.x-concepten. Core bezit identiteit, verificatie van sleutelgebeurtenislogboeken, canonieke Nostr-bytes en het Radicle-repositorysubstraat; Comms bezit Nostr-eigen enveloppen, privacyniveaus, publicatie en Marmot-gesprekken; en Social bezit publiek volgen, interacties en lijsten. Control, voor aanmelding en rechten van eigen apparaten, is onvolledig en kan niet worden opgeëist. Deze documenten blijven concepten die voor 1.0 kunnen breken, en dit nummer introduceert de familie voordat er een Heterodyne-clientrelease is verschenen.

Releases

Nostr Java v2.0.8: isolatie van subscriptions en portabele NIP-44

Een gift-wrap-query tegen een relay met vijf events leverde willekeurig nul, twee of zes events op, omdat Nostr Java, een Java-bibliotheek om met relays te praten en Nostr-payloads te versleutelen, elk binnenkomend frame aan elke listener op de verbinding gaf. Versie 2.0.8 routeert EVENT, EOSE en CLOSED naar de subscription die die frames noemen, zodat het einde-van-opgeslagen-events-signaal van de ene query niet langer een andere kan sluiten. Frames op verbindingsniveau zoals NOTICE, OK en AUTH bereiken nog steeds elke listener.

NIP-44 (payloadversleuteling) in dezelfde release heeft geen in het proces geregistreerde JCE-provider meer nodig. Versleuteling werkte pas nadat er een sleutel in die JVM was gegenereerd, wat BouncyCastle als bijeffect registreerde, en het faalde op Android, waar een provider met de naam “BC” toevoegen niets doet. Beide cipherpaden gebruiken nu de lichte ChaCha20-engine van BouncyCastle, en sleutelgeneratie wijzigt niet langer procesbrede JCE-toestand. Wie op de bibliotheek vertrouwde om de provider te registreren, moet dat zelf doen. De afhankelijkheid van NIP-44 van de JCE-provider is de issue die hiermee sluit.

NoorNote v1.3.6: profielstatussen en advertenties

NoorNote is een Nostr-client voor desktop, web en Android. Een week nadat 1.3.4 versleuteld toetreden tot communities toevoegde, toont versie 1.3.6 NIP-38 (gebruikersstatussen) onder de NIP-05-naam (domeingeverifieerd) van een profiel: de optioneel verlopende adresseerbare kind 30315-events die een algemene of muziekstatus van één regel dragen. Op die regel klikken zet de eigen status van de kijker.

Advertenties uit NIP-99 (kind 30402-marktplaatsaanbiedingen) worden nu overal in de app weergegeven, dus de marktplaats-addon is alleen nodig om te kopen en verkopen. Privénotities met roepnamen op profielen verschijnen ook in waarschuwingsoranje, met een gevuld notitiepictogram en een oranje ring om de avatar.

nostrord v2.9.0: groepsstatus en media per relay

Een NIP-29-groep verlaten (door relays beheerde groepen) op één host onderdrukte eerder hetzelfde groeps-id op elke andere relay, omdat nostrord, een multiplatformclient voor op relays gehoste communities, zijn vertrek- en verwijdermarkeringen op het kale id indexeerde. Per relay begrensde vertrek- en verwijdermarkeringen houden die onderdrukkingen op de host die ze produceerde, zodat een groep die een id over twee relays deelt niet langer als paar wordt verlaten of weggegooid. Een toetreding die de relay afwijst omdat men al lid is, geldt nu als succes en wist de lokale markering, die een absorberende toestand was geweest: het zelfherstel maakte één slot vrij terwijl de koude start de andere herstelde.

Versie 2.9.0 rendert ook in markdown ingebedde afbeeldingen die andere clients als ![alt](url) schrijven, in plaats van de markdown-interpunctie rond een al gedetecteerde URL te tonen. Directberichten ondersteunen nu NIP-17 (privé-DM’s met gift wrap) en kind 15-bestandsrumors, zodat een versleutelde bijlage die vanuit Jumble is verzonden wordt gedownload, ontsleuteld en getoond, en uitgaande bijlagen voor het uploaden worden versleuteld. Deze tag levert nu het NIP-4e-versleutelingssleutelwerk dat vorige week aan bod kwam. Het voorstel blijft niet samengevoegd, en nostrord zegt dat zijn implementatie het uitgerolde gedrag van Jumble volgt waar dat gedrag van het concept afwijkt.

Niet-uitgebrachte wijzigingen

Shopstr houdt geheimen van remote signer en wallet buiten de browseropslag

Shopstr is een webmarktplaats voor NIP-99-advertenties. Na het werk aan betalingsintegriteit van vorige maand schrijft het geen geserialiseerde bunker-signergeheimen meer naar localStorage. Een NIP-46-bunkerpayload (ondertekenen op afstand) bevatte de actieve bunker://-URL en de gegenereerde privésleutel van de app, zodat elk script in de Shopstr-origin de sessie voor ondertekenen op afstand kon hervatten. Bunkerdata blijft nu in het geheugen voor de huidige sessie, achtergebleven bunkerpayloads worden verwijderd wanneer ze worden gevonden, en signertypes anders dan bunker houden hun eerdere opslaggedrag.

De bijbehorende NWC-wijziging doet hetzelfde voor NIP-47-inloggegevens (wallet connect). Shopstr had de volledige nostr+walletconnect://-string, inclusief het geheim voor walletacties, als gewone browserdata opgeslagen en hergebruikte die bij het afrekenen. Verbindingsstrings en walletmetadata blijven nu in het geheugen, en oudere opgeslagen kopieën worden verwijderd wanneer lokale data wordt gelezen. Scripts die tijdens een actieve sessie al in de Shopstr-origin draaien, kunnen die waarden in het geheugen nog steeds zien.

Routstr verifieert providerontdekking die van relays komt

Eén kwaadwillende relay kon eerder bepalen welke inferentieproviders een Routstr-client vertrouwde. Routstr SDK is de TypeScript-bibliotheek achter Routstr, een marktplaats die AI-providers op Nostr vindt en met Cashu betaalt. De ontdekkingsfix van deze week verifieert elke door een relay geleverde provideraankondiging, modellijst en beoordeling (kinds 38421, 38423 en 38425) voordat een consument ze ziet, zodat een beoordeling die een vertrouwde pubkey noemt maar een ongeldige signature draagt niet meer in de ranking komt.

Tijdstempels ver in de toekomst worden weggegooid voordat de “meest recente beoordeling” wordt gekozen. Events die meer dan vijftien minuten voorlopen op de lokale klok worden verwijderd op het live pad en bij het lezen van de persistente opslag, wat voorkomt dat een vervalste created_at geldig ondertekende beoordelingen over herstarts heen inhaalt. Als vertrouwde beoordelingen niet beschikbaar zijn, faalt de beoordelingspoort gesloten en sluit providers zonder beoordeling uit van de betalingsranking totdat er beoordelingen komen. Operators kunnen een provider nog steeds handmatig inschakelen.

nostr-tools bindt gift-wrap-rumors aan hun seals

Het uitpakken van een NIP-59-event (gift wrap) ontsleutelde eerder de wrap, ontsleutelde de seal en gaf de binnenste rumor terug zonder te controleren van wie de seal kwam. nostr-tools is een JavaScript-bibliotheek met hulpmiddelen voor het Nostr-protocol. De uitpakfix van deze week eist dat de wrap kind 1059 is, de seal kind 13 met een geldige signature, en dat de pubkey van de rumor gelijk is aan de pubkey van de seal. Het ontsleutelen van de seal bewijst al controle over seal.pubkey. Zonder die laatste controle zou iedereen een rumor kunnen sealen die iemand anders als auteur noemt en een client het bericht aan dat slachtoffer laten toeschrijven.

NIP-17 (privé-DM’s met gift wrap) gebruikt hetzelfde uitpakpad, dus de binding geldt voor privé-DM’s. Uitpakken in batch slaat nu een wrap over die die controles niet doorstaat in plaats van een exception te gooien, omdat gift wraps ongevraagd zijn en één vijandig event anders de rest van een relayquery zou weggooien.

Haven voegt ondertekend relaybeheer en een lokale notitiebrowser toe

Haven is een zelfgehoste Nostr-relay en Blossom-mediaserver. De net samengevoegde beheerconsole stelt NIP-86-beheeraanroepen beschikbaar op elk relay-endpoint, waarbij elk verzoek wordt geauthenticeerd door een NIP-98-event van de ingestelde eigenaar. Operators kunnen bans, toelatingslijsten, kindregels, relaynamen en opgeslagen media beheren zonder de relay een ondertekensleutel te geven. Een alleen-lezen notitiebrowser houdt versleutelde kinds ondoorzichtig en laadt externe media alleen na een klik, wat een automatisch verzoek voorkomt dat het IP-adres van de operator aan een externe host zou verraden.

Dezelfde Haven-wijziging voegt persistente verkeersgrafieken toe en verhelpt een standaard-LMDB-storing waarbij het tellen van opgeslagen events eindeloos kon doorlopen, een CPU-kern kon vastzetten en latere statistiekaanroepen kon blokkeren. Haven gebruikt nu de backendteller waar die eindigt en anders een begrensde doorloop van events. Het project voegde zijn eerste 23 tests toe rond eventpaginering, verwijdering, metriekpersistentie, eigenaarscontroles en aan de URL gebonden verzoeksignatures.

Amethyst haalt Blossom-autorisatie van de threads voor het laden van afbeeldingen

Amethyst, een Android-Nostr-client, wacht niet langer op Blossom-leesautorisatie op de OkHttp-dispatcherthreads. De interceptor start het ondertekenen nu buiten de netwerkthread, terwijl de afbeeldingfetcher één gedeelde signature per host afwacht en het verzoek voor de beschermde blob opnieuw doet. Een golf van afgeschermde afbeeldingen bezet daarom niet langer elk verbindingsslot per host terwijl een signer antwoordt.

Dezelfde Amethyst-patch brengt de tokencodering in lijn met BUD-11: Base64url zonder padding, scope server, en geen blob-specifieke x-tag, waardoor één token meerdere blobs op dezelfde host kan dekken. Nieuwe concurrency-tests testen caching, verval, ondertekende nieuwe pogingen en zestien gelijktijdige aanroepers die één signature delen.

Protocol- en specificatiewerk

NIPs

Snort en Ditto gebruiken nu NIP-22 (commentaarthreads) voor gewone tekstantwoorden en komen samen op kind 1111 terwijl ze compatibiliteitspaden behouden; dit vestigt geen protocolbreed enkelvoudig antwoordkind. Nadat de wijziging van juni het verbod ophief om NIP-22 tegen kind 1-notes te gebruiken, noemt een samengevoegde toevoeging aan NIP-30 (eigen emoji) kind 1111 onder de events die emoji-tags mogen dragen, waarbij een shortcode in content via die tag wordt opgelost. Snort, een web-Nostr-client, schrijft nu elk antwoord als kind 1111, laadt die commentaren via E/A-roottags in hoofdletters, en accepteert nog steeds een optioneel NIP-10-pad (kind 1-antwoordtags) voor oudere notes. Ditto, een gecombineerde Mastodon-server en Nostr-relay, publiceert elk antwoord als NIP-22-commentaar, kind 1111 voor tekst en kind 1244 voor spraak, terwijl het bestaande kind 1-antwoorden blijft weergeven. Clients die alleen NIP-10 begrijpen zien de nieuwe vorm niet. Berichten op het hoogste niveau blijven kind 1.

Een pay_invoice-verzoek van NIP-47 (Nostr Wallet Connect) heeft momenteel geen standaardmanier waarop de client een plafond voor routeringskosten kan opgeven. Een open voorstel voor een kostenplafond voegt een optionele parameter max_fee in millisatoshi toe aan pay_invoice. Wallets die het budget respecteren MOETEN geen betaling verzenden waarvan de routeringskosten amount + max_fee overschrijden en MOETEN FEE_LIMIT_EXCEEDED teruggeven, gedefinieerd als geen afschrijving en geen poging tot betaling. Ondersteunende implementaties MOETEN fees_paid in het antwoord opnemen zodat de client kan afstemmen. Implementaties zonder ondersteuning voor een kostenlimiet negeren de onbekende parameter, en clients zouden een ontbrekend veld fees_paid moeten opvatten als teken dat het plafond mogelijk niet is gehandhaafd. De wijziging voegt geen eventkinds toe en blijft een voorstel tot het wordt samengevoegd.

Een open NIP-32-voorstel voor taallabels zou ["l", "<BCP-47>", "lang"] standaardiseren voor de door de auteur opgegeven taal van de tekst. Omdat de l-tag van één letter al door relays indexeerbaar is, zouden clients een Japanse feed kunnen opvragen met {"#l":["ja"]} zonder relay-upgrade of onbetrouwbare taaldetectie na het downloaden. Het concept verplaatst ook de taalvoorbeelden in NIP-66-relayrapporten, NIP-68-afbeeldingsmetadata en NIP-71-audiotracks naar dezelfde namespace. Labels blijven ongeverifieerde beweringen van de auteur, en de wijziging is niet samengevoegd.

Nostr Wallet Connect

Na een time-out, een herverbinding of een gemiste melding heeft een wallet-connect-client een manier nodig om één betalingsrecord op te vragen zonder te weten welk Bitcoin-betalingsprotocol het aanmaakte. Een open concept voor betalingsopvraging in de NWC-uitbreidingsrepository definieert het optionele NWC-09 lookup_payment naast de NIP-47-kern. Het verzoek gebruikt precies één selector: een stabiele, aan de wallet gebonden transaction_id, de met BOLT11 compatibele velden payment_hash en/of invoice die lookup_invoice al gebruikt, of een payment_type plus een getypeerd lookup-object dat door een andere uitbreiding is gedefinieerd. Een geslaagd resultaat geeft een gemeenschappelijke envelop terug (transaction_id, type, state, payment_type, amount in msats, tijdstempels, optionele fees_paid en metadata, en een gediscrimineerd details-object) en MOET oplossen naar precies één record dat voor die verbinding zichtbaar is. De wallet MOET NIET onthullen of een ontoegankelijk record bestaat, en een selector die op meerdere zichtbare records past geeft MULTIPLE_MATCHES terug. De toestanden zijn pending, accepted, settled, failed, expired en canceled. Hetzelfde voorstel voegt NWC-12-BOLT12-aanbod- en betalingsdetails toe die die envelop hergebruiken. Beide documenten zijn nog concepten.

NAPs

Een open NAP-DISPLAY-concept zou een napplet laten vragen aan zijn host welke pixeldisplays het mag gebruiken. Het bouwt voort op het apart behandelde, niet-samengevoegde NIP-5D-voorstel voor web applets, dat Newsletter #17 introduceerde en dat buiten de samengevoegde NIP-set blijft. Het concept definieert display.list, dat ondoorzichtige stabiele identificatoren zou teruggeven met logische breedte, hoogte en een tijdens runtime gekozen type (lcd, eink, led-matrix of other), en display.push, dat een niet-lege batch van op coördinaten geadresseerde sRGB-pixels van drie bytes zou aanleveren. Runtime-ontdekking zou logische RGB afbeelden op de eigen kleurdiepte, oriëntatie en verversing en MAG updates roteren, herordenen, quantiseren, ditheren of samenvoegen. Het shellbeleid zou bepalen welke displays een napplet mag opvragen of beschrijven en MAG batches afwijzen, in snelheid beperken of aftoppen. Voordat een pixel wordt toegepast, zou de runtime de hele batch valideren, zodat een mislukte push niets op het apparaat zou wijzigen. Succes zou betekenen dat de batch is aanvaard, niet dat de hardwareverversing klaar is.

Marmot

Een open Marmot-experiment zou het ingetrokken External Commit-concept voor aanmelding vanaf hetzelfde account vervangen door een begrensde Commit-vorm. Marmot, het MLS-groepsberichtenprotocol op Nostr, wijst in dat concept de dataloze component 0x800d (marmot.same-account-membership.v1) aan als onderhandelde gedragsmarkering. Zolang die vereist is, mag een huidig blad óf precies één inline Add van hetzelfde account óf één tot vier inline Removes van broers of zussen opstellen, elk met een normaal UpdatePath en gewone convergentieprioriteit, en elke Commit MOET ten hoogste vijf huidige bladen per account overlaten. Het koppelen gebruikt een kortlevende, door de sponsor getoonde QR (marmot-pairing-v1:) waarvan het geheim HKDF-SHA256 en ChaCha20-Poly1305 voedt over een dragoneafhankelijk kanaal. Uitsluitend lokale kind 453-bewijzen binden de sessie aan de gedeelde accountsleutel en worden nooit via relays verzonden. Na een passende Welcome is de eerste applicatiepayload van de toetreder een niet-weergegeven kind 452-bevestiging die is gebonden aan de Welcome- en GroupInfo-digests, zodat een byte-identieke Welcome kan worden hersteld zonder het KeyPackage opnieuw te verbruiken. De gekoppelde sponsor is de vertrouwenswortel van de toetreder voor die tak en bewijst geen globale finaliteit. Een begeleidend document over accountsynchronisatie blijft verkennend en niet-interoperabel. Het experiment maakt geen deel uit van het aangenomen basisprofiel.

Zes jaar Nostr in augustus

De augustusmaanden volgen één interoperabiliteitsprobleem: hoe een client een doel benoemt en er terugkoppeling aan hangt. De oorspronkelijke protocolrepository legde geen commits vast in augustus 2021, dus de kern van ondertekende events stond stil. NIP-25 (reacties) verliet daarna in 2022 het hokje van alleen kind 1. Gewone vervangbare records kregen in 2023 naddr- en a-coördinaten met een leeg identificatorveld; in 2024 werd de aparte geparametriseerd-vervangbare klasse omgedoopt tot adresseerbare events zonder wijziging van het wire-formaat. Reacties verhuisden in 2025 naar externe media. Kind 1111 van NIP-22 (commentaarthreads) bereikte in 2026 clients in productie. De voortgang loopt van een stilstaand protocoldocument naar een gedeeld vocabulaire voor antwoorden en reacties dat werkt over notes, vervangbare records en objecten buiten het netwerk.

Augustus 2021

Het commitvenster van augustus 2021 in de oorspronkelijke protocolrepository is leeg. De laatste wijziging voor die inactieve maand was het NIP-05-concept van 18 juni, dat DNS-domeinidentificatoren toevoegde als voor mensen leesbare verwijzing naar een publieke sleutel. NIP-05 (domeinidentificatoren) ging later over op een well-known JSON-bestand, maar halverwege 2021 was het nog een DNS-TXT-opvraging. Augustus breidde dat identificatorwerk niet uit en voegde geen nieuw eventkind of relaybericht toe.

Hetzelfde lege venster verschijnt in de gereedschappen die al naast de specificatie bestonden. noscl, een commandoregelclient uit januari 2021, legde geen commits vast in augustus; go-nostr en nostr-tools evenmin. De protocolactiviteit hervatte pas aan het eind van het jaar, toen de repository NIP-09 (verzoeken tot eventverwijdering) toewees en het DNS-schema verving door een well-known JSON-identificatorbestand. Augustus 2021 is de inactieve fase tussen het identificatorconcept van juni en het verwijder- en well-known-JSON-werk van december, terwijl het model van ondertekende events en relays hield zoals het was opgeschreven.

Augustus 2022

Op 19 augustus breidde een NIP-25-wijziging de doelen van kind 7-reacties uit van kind 1-tekstnotes naar andere notes. Het kind 7-event en de +/--conventie stonden al in het concept. Die interoperabiliteitswijziging liet een like, dislike of emoji zich hangen aan een profiel, een volglijst of elk later eventkind dat dezelfde e- en p-tags hergebruikte.

De huidige NIP-25-specificatie houdt die generalisatie: een reactie geeft gebruikersreacties op andere events aan, en een adresseerbaar doel krijgt ook een a-tag met kind:pubkey:d-tag-coördinaten. Amethyst, een Android-client, implementeert dat contract in zijn reactiebouwer. Die bouwer accepteert elk event, schrijft e-, p- en k-tags, en voegt een a-tag toe wanneer het doel een adresseerbaar event is. Dit maakte reactiedoelen algemener dan kind 1; latere augustuswijzigingen voegden stabiele coördinaten en contexttags voor commentaren toe.

Ook relaysoftware zette tagregels om in opslaggedrag. Op 17 augustus behandelde nostr-rs-relay niet langer elke hexadecimaal uitziende tagwaarde als binaire indexsleutel. Het beperkte die optimalisatie tot tags van één letter en hexadecimale waarden in kleine letters, waardoor gewone teksttags bewaard bleven in plaats van gedecodeerd te worden naar een vorm die filters niet konden matchen. Diezelfde maand voegde zo twee kanten van interoperabiliteit samen: specificaties verbreedden waar een interactie op kon mikken, terwijl een relay corrigeerde hoe die doeltags werden geïndexeerd en opgehaald.

Augustus 2023

Op 24 augustus definieerde NIP-19 (bech32-identificatoren) hoe een niet-geparametriseerd vervangbaar event als naddr wordt gecodeerd. Het identificatorveld, de d-tag, werd een lege string voor kinds die alleen op pubkey en kind vervangen, zoals metadata en contactlijsten. Vijf dagen later voegde NIP-01 (het basisevent- en relayprotocol) het bijbehorende a-tagformaat toe: kind:pubkey: met een afsluitende dubbele punt en zonder identificator. Clients konden nu naar een vervangbaar record wijzen zonder te wachten op een specifiek event-id dat de volgende vervanging ongeldig zou maken.

De huidige NIP-19-tekst zegt implementeerders nog steeds een lege string te gebruiken voor die vervangbare events. nostr-tools, de JavaScript-identificatorbibliotheek, codeert dat veld via naddrEncode, zodat een aanroeper een lege identificator kan doorgeven en een deelbare coördinaat kan produceren. Het werk van augustus 2023 maakte vervangbare toestand tot iets dat een commentaar, een reactie of een deellink kon benoemen nadat het onderliggende event was vervangen. De augustus daarop standaardiseerde de terminologie voor de verwante geparametriseerd-vervangbare klasse, terwijl latere commentaartags de coördinaatgrammatica hergebruikten als A en a.

Privépayloads werden in dezelfde periode portabel. Op 24 augustus voegde rust-nostr NIP-44-versleutel- en ontsleutelfuncties toe aan zijn JavaScript-bindings, waarmee het geversioneerde conversatiesleutelschema naast native Rust-aanroepers ook aan webapplicaties werd blootgesteld. Op 22 augustus scheidde Amethyst NIP-44-versleuteling van het formaat van het berichtevent, wat de protocolscheiding weerspiegelde tussen hoe content wordt versleuteld en hoe een applicatie die vervoert. Stabiele coördinaten maakten publieke objecten makkelijker te refereren; herbruikbare versleutelings-API’s maakten privécontent makkelijker te verplaatsen tussen implementaties zonder die aan één berichtkind te koppelen.

Diezelfde maand bracht ook financiering voor aangrenzend werk aan sleutelisolatie, interface en educatie. Een OpenSats-subsidieronde van 17 augustus wees de subsidies uit het Nostr Fund toe aan Amber, aan gedeeld Nostr-interfaceontwerp en aan educatie over Nostr-toepassingen. De subsidie voor Amber richtte zich op het houden van ondertekensleutels in een aparte Android-applicatie via NIP-46, terwijl de ontwerp- en educatiesubsidies onboarding en herbruikbare applicatiepatronen aanpakten. Het bredere Nostr-systeem vorderde via specificatiecommits, sleutelisolatie, interfacewerk en gefinancierde ontwikkelaarseducatie als gedeelde infrastructuur.

Augustus 2024

Op 20 augustus doopten de specificaties “geparametriseerd vervangbaar event” om tot “adresseerbaar event” in NIP-01 en zestien andere documenten, waaronder longform-artikelen, live-activiteiten, lijsten, agenda’s en advertenties. Het wire-formaat veranderde niet. kind:pubkey:d-tag bleef de coördinaat. Wat veranderde is dat elke specificatie die die coördinaten al gebruikte er nu hetzelfde woord voor gebruikte.

Dat vocabulaire is wat huidige implementaties uitleveren. NIP-01 slaat adresseerbare events op als het nieuwste record per kind, pubkey en d-tag. NIP-19 noemt een naddr “a nostr addressable event coordinate”. Het reactiepad van Amethyst, hierboven aangehaald, typeert het doel als AddressableEvent voordat het de a-tag schrijft. De coördinaatuitbreiding van 2023 en de terminologiewijziging van 2024 gebruiken beide de coördinaatgrammatica kind:pubkey:d-tag, terwijl NIP-01 gewone vervangbare events blijft onderscheiden van adresseerbare events. Een later commentaar kan daardoor een adresseerbare discussie ophalen via een hoofdletter A zonder zich te bekommeren om welk event-id dat adres nu bezet.

Opslagprotocollen pasten dezelfde voorkeur voor expliciete identificatoren toe. Op 27 augustus liet BUD-04 van Blossom één autorisatie-event meerdere blob-hash-x-tags dragen, zodat een client een begrensde batch uploads, mirrors of verwijderingen kon autoriseren zonder te doen alsof de hashes één object beschreven. Vier dagen later verduidelijkte het project zijn blob-descriptor en voegde een voorbeeld toe. Nostr-events coördineerden bewerkingen op content-geadresseerde media terwijl de bytes op mediaservers bleven, wat ondertekende autorisatie scheidde van opslagtransport.

Op 29 augustus werd ondertekenen op afstand toleranter voor onvolmaakte relaysets. go-nostr wijzigde zijn NIP-46-client zodat één defecte relay een verzoek dat via andere ingestelde relays wordt verzonden niet kon blokkeren: relayverbindingen en publicatiepogingen lopen onafhankelijk, en de aanroep gaat verder zodra een willekeurige verbinding lukt. Op 19 augustus kondigde OpenSats ook langdurige steun aan voor Amethyst-maker Vitor Pamplona, waaronder werk aan NIP-17-privéberichten, multiplatformbibliotheken en het outboxmodel. Protocolvocabulaire, robuust transport, privacywerk en volgehouden onderhoudsfinanciering kwamen samen rond hetzelfde doel: clients die konden blijven werken over apparaten en ongelijke relayomstandigheden heen.

Augustus 2025

Op 22 augustus kreeg NIP-25 reacties op externe content. Een reactie op iets dat geen native Nostr-event is, moet kind 17 zijn en moet k- en i-tags van NIP-73 (identificatoren voor externe content) dragen, ter vervanging van de oudere website-r-tag. De voorbeelden in de samengevoegde tekst zijn een web-URL (k=web) en een podcastaflevering die wordt geïdentificeerd door show-GUID en item-GUID, met Fountain-URL’s als hints. Reacties hadden kind 1 in 2022 verlaten. Nu verlieten ze de Nostr-eventset.

Fountain 1.3, uitgebracht op 15 augustus 2025, leverde die likes voor de specificatie werd samengevoegd en zei dat ze op Nostr werken zodat andere podcastapps ze kunnen lezen. Het NIP-25-document van vandaag gebruikt nog steeds het podcast-GUID-voorbeeld van Fountain. In augustus 2025 kon een reactiecoördinaat een podcastaflevering of een webpagina benoemen met dezelfde identificatorgrammatica die een commentaar later voor een externe root gebruikt.

Augustus 2026

Deze augustus bracht commentaarthreads in de clients die gewone antwoorden schrijven. De wijziging van juni, later samengevoegd, verwijderde de regel die clients had verteld NIP-22-commentaren niet op korte notes te gebruiken. NIP-30 (eigen emoji) voegde vervolgens kind 1111 toe naast notes, reacties en gebruikersstatussen, zodat een commentaar dezelfde emoji-tags kan dragen die die andere kinds al gebruikten. Het specificatiewerk is de toestemming. Het clientwerk is de uitrol.

Snort, een webclient, publiceert nu standaard NIP-22-commentaren voor kind 1-doelen, abonneert op threads via E/A-roottags in hoofdletters, en accepteert kind 1111 in meldingen. Ditto, een community-webclient, publiceert elk antwoord als NIP-22-commentaar, kind 1111 voor tekst en 1244 voor spraak, inclusief antwoorden op kind 1-notes, terwijl het NIP-10-antwoorden (note-threading) blijft lezen. De verschuiving over zes jaar is te zien in die standaardinstellingen: 2022 maakte de reactie algemener, 2023 en 2024 benoemden de coördinaat, 2025 richtte reacties buiten het netwerk, en 2026 maakte het commentaar tot het gedeelde antwoordevent over diezelfde doelen.

Infrastructuur voor privégroepen definieerde herstel als interoperabiliteitseis. Marmots duurzaamheids- en herstartcontract van 13 augustus specificeert welke lokale MLS- en publicatietoestand een herstart moet overleven, en vereist dat clients de opgeslagen toestand afstemmen voordat ze groepsbewerkingen voortzetten. Dat verbreedt de augustusvoortgang voorbij het benoemen van een doel: een volgroeide client moet ook genoeg cryptografische en bezorgtoestand bewaren om na een onderbreking veilig te hervatten. Gedeelde eventvormen helpen alleen wanneer implementaties de toestand kunnen herstellen die nodig is om ze te gebruiken.

Stuur een NIP-17-DM om een project of nieuwsbericht te delen via het Nostr Compass-project.