De Marmot Protocol-organisatie opent drie nieuwe repos voor een v2 protocol draft en een native client-lijn: een Rust workspace genaamd darkmatter, een SwiftUI iOS-app darkmatter-ios en een Kotlin/Compose Android-app darkmatter-android. De originele Flutter Whitenoise is gearchiveerd. Chama comprimeert zeventien releases in één week en steekt de standalone-app grens over bij v3.0.0 voordat een volledige trade-room UI-herteken en per-verkoper storefronts landen in v3.1.0, bovenop holder-only Shamir shares, arbiter-substitutie, wereldwijde community-routing en end-to-end trade-notificaties. Coracle lanceert een betaalde hosted-relay service ondersteund door de open-source Caravel en zooid stack, met diepe Flotilla-integratie gepland. Angor schakelt over naar mainnet als standaard in v0.2.30 en landt een 3-user UAT funding test in v0.2.29. Amethyst landt 41 onuitgebrachte PRs die het NIP-32 / NIP-F4 / Tor werk van vorige week voortzetten. NIP-67 (EOSE completeness hint) en NIP-50 autocomplete worden gemerged, waarmee twee langstaande correctheidsgaten in het core relay-protocol worden gesloten. NIP-GART stelt een privacy-behoudend wire format voor voor noodmeldingen, en NIP-46 krijgt een logout-methode.

Belangrijkste verhalen

Marmot v2 (Dark Matter): protocol-herschrijving, native clients, gearchiveerde Flutter-app

Deze week verschenen drie nieuwe repos onder de marmot-protocol GitHub-organisatie, samen vormen ze de vroege vorm van een Marmot v2 protocol draft en een native-client lijn die de Flutter-app-lijn vervangt. darkmatter (Rust, aangemaakt 13 mei, vierendertig commits in de afgelopen zeven dagen) bevat de v2 protocol draft in spec/, een OpenMLS-ondersteunde CGKA-engine in crates/cgka-engine, een conformance-simulator met property tests en een Tamarin formeel model voor convergence proofs. darkmatter-ios (Swift, aangemaakt 25 mei) is een SwiftUI-client ondersteund door een vendored MarmotKit UniFFI xcframework gegenereerd uit de Rust workspace. darkmatter-android (Kotlin/Jetpack Compose, aangemaakt 25 mei) rust op dezelfde Rust bindings. De originele Flutter Whitenoise is gemarkeerd als whitenoise-archive (“ARCHIVED: This was the original White Noise Flutter app”); een nieuwe whitenoise Dart-repo draagt de actieve Flutter-lijn parallel.

Lees dit als vroege voortgang naar een betrouwbaardere Marmot, geen voltooide pivot. De darkmatter README bestempelt zichzelf als “Candidate Marmot v2 protocol draft, CGKA engine, and conformance workspace” en zegt direct: “MDK remains the deployed Rust protocol implementation until this draft and engine are adopted.” Binnen de workspace is de cgka-engine crate getagd 0.1.0, “single internal consumer, not semver-stable.” Elke spec-pagina draagt “Status: draft for internal review”. Drie sterren op de workspace-repo en nul op de iOS- en Android-apps bevestigen dat het werk pre-announce is. Richting, scope en discipline zijn hier het signaal; production readiness is niet de claim.

De protocol-draft maakt de v1-naar-v2 delta’s concreet. MIP-01’s monolithische marmot_group_data MLS-extensie, die sinds het begin van Marmot groepsnaam, beschrijving, admin pubkeys, Nostr group routing id, relay-lijst, groepsafbeelding-data en disappearing-message settings onder één paraplu draagt, wordt gesplitst in versioned app componenten: marmot.group.profile.v1 voor naam en beschrijving, marmot.group.admin-policy.v1 voor admin pubkeys, marmot.transport.nostr.routing.v1 voor de willekeurige nostr_group_id en de canonieke relay-lijst, marmot.group.blossom.image.v1 voor image hash, encryption key, nonce en upload key, en marmot.group.message-retention.v1 voor disappearing-message seconden. Elk component bezit zijn exacte bytes en zijn eigen versiepad, dus een toekomstige feature kan één component reven zonder de rest van de group state te dwingen om MLS-extensie-consensus opnieuw te doorlopen. MIP-00 credentials krijgen ook een nieuw fundamenteel document account-identity-proof-v1.md, aangeduid als “new in v2 and breaking”. Het identiteitsbewijs leeft nu op zijn eigen oppervlak, gescheiden van KeyPackage-constructie.

De library-delta’s ondersteunen de spec-herwerking. cgka-engine is de nieuwe lokale group state machine: het wraps OpenMLS, bezit de Stable, PendingPublish, Merging en Recovering epoch states, vertaalt intents naar MLS commits, retourneert getypeerde IngestOutcome en GroupEvent waarden voor elke inkomende transport-envelop en levert expliciet geen transport en geen persistentie. Een TransportPeeler trait scheidt Nostr van de engine, en een StorageProvider trait scheidt SQLite (via storage-sqlite, SQLCipher-ondersteund) van de engine. De huidige MDK pakt dit allemaal samen; het splitsen van de lagen laat één engine onder een Nostr-relay transport zitten nu en de ook-geleverde QUIC stream en broker transports later, zonder herschrijving van het convergence-model. Convergence zelf is gedocumenteerd als distributed-convergence.md en bewezen in een Tamarin-model dat deterministic branch-selectie, policy-gated eligibility, retained-anchor replay, stale-branch afwijzing, delivery reordering, duplicatie, app-output-invalidering, welcome/commit handoff, proposal-consumptie en outbound gating tijdens synchroniseren dekt. Rust property tests controleren vervolgens of de engine dezelfde regels volgt met echte OpenMLS-objecten en de simulator-harness. Formele-methoden betrouwbaarheidswerk van deze omvang ontbreekt in de huidige Marmot-stack.

Beide native clients laten Flutter vallen voor platform-native UI-toolkits. darkmatter-ios is pure SwiftUI met een Notification Service Extension die MIP-05 push-wakes op het apparaat decodeert, vendort een gegenereerd MarmotKit Swift-pakket gebouwd uit de Rust workspace en registreert onder de dev.ipf.darkmatter bundle-ID en app-group. darkmatter-android is Kotlin en Jetpack Compose, met een just-gedreven build die een signed arm64-v8a APK produceert en telemetry-endpoints leest uit local.properties. De Android README noemt het architecturale principe direct: “Dark Matter owns protocol data and stores it in SQLite. The Android app should render that data, manage Android platform behavior, and keep UI lifecycle state. The Android app should not become a second database for Dark Matter data.” Dat spiegelt de grens-discipline die de cgka-engine README afdwingt in de Rust-laag, toegepast op de UI-laag.

Native clients zijn belangrijk voor Marmot omdat de meest genoemde zwakte van het protocol mobiele betrouwbaarheid onder ongelijke leveringscondities is geweest: gemiste-deadline notificatie-wakes, MLS commit races tijdens netwerk-flaps, background-fetch limieten die epoch-advances laten stranden. SwiftUI en Compose geven de clients directe toegang tot platform background-processing primitieven die Flutter bereikt via een plugin-brug, en het UniFFI binding-pad houdt protocollogica in één Rust workspace geleverd als een statische library op beide platforms. De Flutter Whitenoise-lijn gaat door in de niet-gearchiveerde whitenoise repo, dus de aankondiging is additief: een nieuwe native-client lijn draait naast de Flutter-app terwijl de v2-spec convergeert. Productie-cutover vanaf MDK of de huidige Whitenoise-app wacht op de draft, engine en clients die productie-klare releases bereiken.

Chama v2.0.0 tot en met v3.1.0: standalone P2P escrow in één week

De Nostr-native P2P escrow-client geïntroduceerd in Newsletter #25 op v1.3.0 leverde de afgelopen zeven dagen zeventien getagde releases, eindigend bij v3.1.0 op 9 juni met een trade-room UI-herteken en per-verkoper storefronts. Het versiespoor vertelt het verhaal: v2.0.0 is de BREAKING basis, dan sluiten v2.0.1, v2.0.2 en v2.0.3 Fedi WebView funding-rail gaten; v2.1.0, v2.2.0, v2.3.0 en v2.3.1 verharden de arbiter-laag; v2.4.0, v2.5.0 en v2.6.0 voegen self-custody oppervlakken en wereldwijde community-routing toe; v2.7.0, v2.8.0, v2.9.0 en v2.10.0 leggen simpel-Engelse key-copy, groepsaanmeldingen, dispute-deadline arbitrage en reputatie eroverheen. v3.0.0 bindt het pakket samen met end-to-end trade-notificaties, en v3.1.0 op 9 juni hertekent het trade-scherm rond een Reserved → Locked → Settled voortgangsruggengraat, rol-gekleurde action cards en een per-verkoper storefront-listingsklasse (curated swaps, loanbooks en bills) die worden geleverd.

De architecturale pivot leeft in v2.0.0. Het escrow LOCK-formaat veranderde zodat elke share van een 2-of-3 Shamir-split alleen wordt versleuteld naar zijn houder (sharePolicy holder-only-v1). De bearer ecash van de federatie reconstrueert niet langer vanuit één deelnemer alleen, waarmee een pad wordt gesloten waar een kwaadaardige partij met zowel zijn eigen share als een federatie-gehouden share de trade zonder toestemming kon voltooien. Pre-2.0 clients falen luidruchtig met “can’t find your share”; de trade kan niet voltooid worden op een verouderde client, en er gaan geen fondsen verloren in het proces. Een v2.0 lock vereist dat elke partij op v2.x settled. v2.0.0 voegde ook multi-unit storefronts en een sats-only Market-weergave toe.

v2.1.0 introduceerde arbiter-substitutie: de arbiter share bij Shamir index 2 wordt nu versleuteld naar een deterministische prioriteitsvolgorde over de community arbiter pool, zodat een afwezige arbiter kan worden vervangen zonder de trade te laten stranden. v2.2.0 bewees dat de substitutie werkte in de praktijk op een ₿121 trade en voegde healing-substitutie back-ups toe. v2.3.0 sloot het laatste arbiter front-running gat door listing-arbiter community-lidmaatschap te controleren op lock-tijd, en v2.3.1 sloot de zuster-race waarbij een auto-toegewezen arbiter-slot een preview was totdat de lock ze plaatste.

De self-custody oppervlakken kwamen in v2.4.0 (BIP-39 recovery phrase voor de Fedimint ecash wallet, versleuteld opgeslagen op Nostr) en v2.5.0 (master nsec back-up die de Nostr-identiteit en de wallet seed bezit). v2.6.0 herwerkte onboarding rond een globale community picker zodat gebruikers in landen zonder een lokale Chama naar de dichtstbijzijnde federatie worden gerouteerd; eerdere builds stuiterden de gebruiker af zonder fallback. v2.7.0 schreef het recovery-key scherm opnieuw in simpel Engels (“the only key to your account and the money in it; Chama never sees it and can’t reset it; if you lose it, no one can get your account back”). v2.8.0 voegde groepsaanmeldingen, dark/light theming toe en voegde twee nieuwe event-kinds toe (38120 roster, 38121 application). v2.9.0 veranderde dispute resolution bij deadline: betwiste trades die hun expiry raken lossen nu op via arbiter-uitspraak; eerder gedrag automatisch-refunded. De release is gemarkeerd COORDINATED zodat alle partijen in een dispuut moeten updaten. v2.10.0 voegde per-trade thumb-up/thumb-down ratings toe als een nieuwe event kind 38123.

v3.0.0 is de mijlpaal waarbij de app een coördinerende community niet meer nodig heeft om te functioneren. End-to-end trade-notificaties pingen de gebruiker alleen bij actionable state-overgangen: tegenpartij locked de sats, uitbetaling klaar om te claimen, dispuut vereist de uitspraak van de gebruiker als arbiter, of trade settled of expired. Één toggle in het Me-scherm zet notificaties aan of uit, en de permission prompt vuurt alleen wanneer de toggle is ingeschakeld. De fire-once dedup houdt een state-herlading tegen om een alert storm te triggeren. Een wrong-chama guardrail bug werd ook gesloten in PR #103, waar eerdere versies een listing met het label van één chama maar de federatie van een andere chama konden stempelen. Windows- en Linux-desktopbundels worden bij de release meegeleverd; de macOS dmg wordt achtergehouden totdat signing en notarisatie landen.

Chama voegt zich nu bij Mostro en Shopstr als een Nostr-native marktplaats, onderscheiden door serverloze architectuur, Fedimint-ondersteunde 2-of-3 Shamir-escrow, holder-only share-versleuteling en de enige van de drie die een zelfstandige desktop- en mobiele client levert zonder coördinerende community.

Coracle Hosting: betaalde relay-service plus open-source Caravel-stack

Op 3 juni kondigde Hodlbod Coracle Hosting aan op hosting.coracle.social, een gehoste community-relay service die terugkerende lightning-betalingen via NWC of kaart accepteert. De service wordt aangedreven door Caravel, Coracle’s billing- en provisioning-frontend, en zooid, een relay-runtime die veel virtuele relays op één machine host. Beide zijn open source op Coracle’s self-hosted gitea. Caravel wordt geleverd met optionele livekit en Blossom integratie die operators per relay kunnen aan-/uitzetten. Een gratis tier met member-count limieten laat operators de service evalueren voordat ze zich verplichten tot betalingsdetails.

Hodlbod is openhartig over het businessmodel: open source monetariseren door een gehoste versie te verkopen van een stack die iedereen anders ook kan draaien. De concurrentiegracht is de Flotilla integratie, die de volgende geplande stap is. Flotilla bezit het gebruikersoppervlak, dus de gehoste optie geserveerd vanuit Flotilla wordt het standaardpad voor elke gebruiker die managed infrastructuur verkiest. Hodlbod bood aan andere Caravel-operators toe te voegen aan Flotilla’s alternative-hosting picker als ze contact opnemen, waarmee de deur open blijft voor een gefedereerde hosting-markt.

Caravel voegt zich bij relay.tools als een publiek Nostr relay-provisioning platform met betaalde member-tiers. relay.tools dateert van vóór Caravel en levert als de dominante relay-creator service vandaag, met zijn eigen directory van community-relays en betaalde-member of moderator join-flows. Caravel’s onderscheidende functie is de gecoördineerde stack: de relay-runtime (zooid), de billing- en provisioning-frontend (Caravel zelf) en de client-side picker (Flotilla-integratie, nog in ontwikkeling) leveren als één ontwerp. De andere onderscheidende functie is zooid’s veel-relays-per-proces dichtheid, waar customer-relays één host-proces delen zodat de operator hosting-kosten amortiseert over veel kleine communities. Dit is hetzelfde dichtheidsargument dat shared web hosting levensvatbaar maakte in het begin van de jaren 2000, toegepast op Nostr’s relay-laag.

Releases

Angor v0.2.29 en v0.2.30: mainnet-standaard en 3-user UAT funding test

Angor v0.2.29 op 4 juni en v0.2.30 op 8 juni zijn de twee releases van deze week voor het gedecentraliseerde Bitcoin-en-Nostr funding-protocol. v0.2.30’s hoofdverandering is PR #893, die de standaardnetwerk overschakelt naar mainnet. Angor wordt nog steeds geleverd als een unstable alpha release, maar de default-mainnet switch signaleert dat het protocol voorbij de testnet-only fase is voor de desktop- en mobiele clients. v0.2.30 landt ook een single-tap mobile create-project flow met image upload en scroll reset (PR #889) en lost een race condition op waarbij de lightning invoice spinner kon blijven hangen (PR #890).

v0.2.29 voegde een end-to-end UAT test toe in PR #881 die 3-user send funds over 10 rondes met onbevestigde uitgaven dekt, de eerste multi-user funding-flow test in de Angor testsuite. De release voegde ook een implementatieplan toe voor een Angor CLI en MCP-server (PR #792), met CLI-verbeteringen voor MCP testing workflow in PR #880. PR #885 door DavidGershony verhielp een Boltz lightning invoice die het verkeerde netwerk gebruikte na een runtime network switch, een bug die zou zijn opgekomen in productie na de v0.2.30 mainnet-standaard. Settings biedt nu een optionele recovery-wallet file purge tijdens data wipe (PR #883).

Sprout v0.3.15: ephemeral channel TTL refresh en ACP slash-commands

Sprout v0.3.15, uitgebracht 10 juni, is de achtste release in een reeks die begon met v0.3.7 op 2 juni. Newsletter #25 behandelde de v0.3.1 tot en met v0.3.6 reeks met de mesh-llm integratie en channel-secties werk; v0.3.7 tot en met v0.3.15 zijn downstream daarvan, gericht op polish en enkele door de gebruiker zichtbare toevoegingen. De meest zichtbare wijziging voor de gebruiker is een TTL-refresh voor ephemeral channels in PR #902: wanneer een gebruiker een ephemeral channel unarchiveert, breidt Sprout de time-to-live van het channel uit zodat de unarchive niet direct opnieuw-archiveert onder de oorspronkelijke expiry-timer. Mobiele custom emojis komen in PR #906 naast een settings redesign, en reactie-tellingen animeren nu bij verandering (PR #904).

PR #905 verhelpt een langstaand gat waarbij multi-word display names braken en NIP-27 nostr:npub mention-extractie stilletjes wegviel. Een directory-ondersteunde team UI voor desktop komt in PR #912 met install, sync en reveal commando’s. Slash-commands worden nu doorgegeven aan ACP connectors in PR #919, waardoor Sprout /help-stijl commando’s direct kan doorsturen naar agent runtimes terwijl de Sprout UI uit het pad blijft.

Wisp v1.1.1: Spark wallet-integratie en nsec paste guard

Wisp v1.1.1, uitgebracht 5 juni, brengt een twee-tier wallet Connect-scherm met Spark sub-scherm in PR #548 en dashboard-pariteit met de iOS wallet UI in PR #549. De release bevat een systeem-brede nsec paste guard die een nsec1-prefixed paste ergens in de app detecteert en het veld blokkeert om het te accepteren, waarmee een van de meest genoemde footguns in Nostr UX wordt gesloten. QR-scan login plus een watch-only modus voor npub en nprofile komt in PR #552, waardoor een gebruiker een profiel alleen-lezen kan browsen. Zap-berichten renderen nu als mini-posts in de engagement drawer (PR #559) zodat zap-notes hun tekst naast het sat-bedrag dragen. Een web-of-trust filter op thread replies komt in PR #583, waardoor gebruikers reply-spam kunnen verbergen van accounts buiten hun follow-graaf.

Nostria v3.1.46 en nospeak 1.1.3: notificatieherwerking en ICE restart

Nostria v3.1.46 op 7 juni beëindigt een drie-release reeks die de notificatieteller herwerkte om alleen nieuwe notificaties sinds de laatste weergave te tellen, waarmee een langstaande inflatie wordt geëlimineerd waarbij het laden van oudere notificaties door scrollen de badge-count verhoogde. Nostria v3.1.45 verhielp een split-payment bug die lightning- en QR-code betalingen raakte en liet een eerder gepland translucent UI vallen als onhaalbaar op Android’s compositor.

nospeak v1.1.3 op 4 juni voegt ICE restart toe op FAILED state voor 1-op-1 voice calls. Standaard WebRTC-gedrag laat een call vallen wanneer ICE-kandidaten aflopen zonder alternatief pad; het ICE-restart pad herhandelt kandidaten zodat de call herstelt van transiënte NAT- of netwerkveranderingen. Android calls houden het scherm nu aan tijdens video calls.

Onuitgebrachte wijzigingen

Amethyst: 41 PRs die de NIP-32 / NIP-F4 / Tor track voortzetten

Amethyst mergde deze week 41 PRs zonder een release tag te knippen, bovenop de 52 PRs van vorige week en het NIP-32 hashtag labeling en NIP-F4 podcast werk behandeld in Newsletter #25. De actieve branch blijft features accumuleren voor de volgende getagde release, met polish op de hoofdtoevoegingen van vorige week: hashtag labeler discovery, podcastscherm, muziektracks en playlists, Tor self-heal watchdog, ephemeral signers voor anonieme uploads en onchain zaps met NIP-05 filtering. Amethyst’s PR throughput blijft de hoogste van elke Nostr-client, en de onuitgebrachte queue is de de facto roadmap voor wat andere Android Nostr-clients moeten matchen.

Damus: relay tracking uit OK messages en v1.17 changelog

Damus PR #3786, gemerged 3 juni, voegt succesvolle OK berichten van een relay toe aan de post-relay lijst. Eerdere Damus-builds vulden de seen-relays lijst alleen bij het ontvangen van een generiek bericht van de relay, wat betekende dat een relay die de post erkende maar geen events terug leverde onzichtbaar was voor de gebruiker. De verandering is belangrijk voor gebruikers die willen bevestigen dat hun post op hun geprefereerde outbox-relay is geland. PR #3796 verhelpt een AttributeGraph cyclus op Profile View, en PR #3725 landt de v1.17 changelog vooruitlopend op de volgende getagde release.

Shopstr: NIP-34 dual-publishing

Shopstr’s shopstr repo op ngit werd deze week op Nostr aangekondigd als een NIP-34 git-repo, en voegt zich bij ngit’s tracked repos. De GitHub-repo van de shop-client blijft het primaire ontwikkelingsoppervlak; de NIP-34-aankondiging maakt een parallel git-over-Nostr collaboratiepad beschikbaar. Dit is het tweede grote Nostr-marktplaatsproject dat dual-publisht naar NIP-34 na Mostro, en zet de geleidelijke migratie van project-metadata naar Nostr’s git-transport voort.

Hermes-Marmot: AI-agent gateway over MLS

hermes-marmot, een plugin voor de Hermes Agent, verbindt het berichten-oppervlak van een AI-agent met Marmot (MLS-over-Nostr) groepen met behulp van mdk-python, de Python bindings aan de Rust Marmot Development Kit. De plugin laat een gebruiker een AI-agent DM’en vanuit elke Nostr-client die kind 445 MLS-berichten spreekt, inclusief Whitenoise. Inkomende DMs gebruiken NIP-59 gift-wrap unwrapping via nostr-sdk Python bindings, en inkomende welcomes stromen door UnwrappedGift.from_gift_wrap naar mdk.process_welcome en mdk.accept_welcome. Toegangscontrole loopt via MARMOT_ALLOWED_USERS (een komma-gescheiden npub allowlist) of MARMOT_ALLOW_ALL_USERS=true voor open dev-toegang.

De repo is nieuw (laatst bijgewerkt 27 mei) en klein. De betekenis is architecturaal: het is de eerste publieke brug tussen een LLM agent-runtime en een MLS-versleuteld Nostr messaging-kanaal, en het eerste productiegebruik van mdk-python buiten Whitenoise zelf. Het patroon wijst naar agent-tot-agent communicatie waarbij beide endpoints MLS-sleutels hebben en de relay alleen ciphertext ziet.

NIP-updates en protocol-spec werk

NIP-67 EOSE completeness hint (PR #2317) gemerged

PR #2317 door mattn werd gemerged op 6 juni, waarmee NIP-67 aan het protocol werd toegevoegd. De NIP breidt het EOSE relaybericht uit met een optioneel derde element: ["EOSE", <subscription_id>, "finish"] signaleert dat elke opgeslagen event die aan het filter voldoet is afgeleverd, terwijl een kale ["EOSE", <subscription_id>] geen completeness-claim draagt. Een relay die de hint weglaat vertelt de client dat er meer kan zijn; een relay die de NIP-67 advertentie in NIP-11 weglaat houdt het huidige gedrag onder de bestaande legacy-heuristiek. De verandering is backward compatible in beide richtingen: legacy clients negeren het trailing array-element, en legacy relays laten het weg.

De motivatie in de gemergde spec is tweeledig. Ten eerste: silent data loss. Een client vraagt om de laatste 500 notes tegen een relay met een 300-event interne cap, de relay retourneert 300 events, en de client (met de standaard received < limit heuristiek) concludeert dat het resultaat compleet is. De 201e tot en met de Nde oudste matching notes blijven op de relay ongelezen, met de client blind voor dat feit. Ten tweede: verplichte verspilde round trips. Wanneer een relay responses capt op 300 events, vereist elk abonnement dat de cap uitput een tweede REQ met until=<oldest_created_at> puur om voltooiing te bevestigen, zelfs wanneer het filter precies 300 events matcht. Beide faalmodi worden betaald door elke client op elk cap-uitgeputte abonnement. De "finish" hint is één optionele string op één bestaand bericht en elimineert beide kosten.

NIP-50 autocomplete-uitbreiding (PR #2357) gemerged

PR #2357 door Alex Gleason werd gemerged op 6 juni, waarmee een autocomplete:true/false token wordt toegevoegd aan NIP-50 search. De uitbreiding laat een client een query markeren als een typeahead lookup zodat de relay prefix matching gebruikt, met full-text search als standaard voor queries zonder de token. Ditto’s relay implementeert het voor follow packs, lijsten en elke event met een title tag, en retourneert matches tegen de title prefix; het standaard search-pad draait full-text scoring. Zonder deze token hadden autocomplete-stijl UIs geen manier om de prefix-search intentie te communiceren en moesten relays gokken uit de vorm van de query. De token is een per-search hint, geen relay-brede capability, dus een relay kan het implementeren voor één event-klasse (titles) zonder algemene autocomplete-ondersteuning te claimen.

NIP-GART noodmeldingen en locatiebroadcasts (PR #2374)

PR #2374 door disinqa, geopend 9 juni, definieert een privacy-behoudend wire format op Nostr voor noodmeldingen en locatiebroadcasts geadresseerd aan een groep vertrouwde ontvangers. Het genoemde ontwerpdoel is het verbergen van afzenderidentiteit, groepslidmaatschap en payload voor relay-operators terwijl de events replay-veilig en handtekening-verifieerbaar end to end blijven. NIP-nummer is nog TBD, voorstel is early-draft. Use case is het standaard noodmelding-patroon: een gebruiker onder dreiging broadcast een locatieping die alleen een vooraf gedeelde groep vertrouwde contacten kan decoderen, met de relay blind voor afzender, ontvangersset en payload. Wire-format details leven in de PR en zullen waarschijnlijk evolueren naarmate maintainers reviewen.

NIP-46 logout-methode (PR #2373)

PR #2373 door hzrd149, geopend 8 juni, voegt een logout methode toe aan NIP-46 zodat een client een bunker expliciet kan vertellen dat de sessie is beëindigd. Tot nu toe was de enige manier om een bunker-sessie te beëindigen wachten op de sessie-timeout of stoppen met het gebruik van de verbinding, die beide de bunker sessiestatus laten vasthouden voor een client die weg is. Het voorstel is kort (één nieuwe methode) en is het soort huishoudelijke wijziging dat langlevende bunker-integraties schoner maakt.

NIP-95 hybride relay-P2P voorstel gecirculeerd als long-form

Een long-form NIP-95 specificatie werd gecirculeerd als een kind:30023 post van npub 91bea5cd9361504c409aaf459516988f68a2fcd482762fd969a7cdc71df4451c op 4 juni onder de titel Protocolo Híbrido Relay-P2P via WebRTC. Het Portugeestalige document definieert een hybride peer-to-peer relay-protocol waar Nostr-clients rechtstreeks met elkaar verbinden via WebRTC voor live berichten terwijl ze relays blijven gebruiken voor stored-event retrieval en offline levering. De auteur formuleerde de spec expliciet als “LLM-ready” en bood bericht-definities, logische flows, dataschema’s en state-regels op een detailniveau dat een AI-model werkende client- of server-code laat genereren. Het voorstel is nog niet geland als een NIP PR; circulatie via kind:30023 is de gebruikelijke voorloper op een formele nostr-protocol/nips pull request.

NIP-44 v3 krijgt een tweede signer: Clave port de spec

Amber’s v6.2.0 NIP-44 v3 uitrol van vorige week werd geleverd vooruitlopend op enige gemergde NIPs PR, waardoor v3 als een Amber-specifieke uitbreiding overbleef die andere clients moesten spiegelen om te interop. Dat single-implementation framing veranderde deze week. Clave, de push-gebaseerde iOS NIP-46 remote signer, landde een onafhankelijke NIP-44 v3 port op 3 en 4 juni over acht commits. Cryptografische primitieven leveren in drie commits: HKDF + ECDH keys laag, het v3 padding-algoritme en een top-level publieke API plus encryption Context. Bovenop die volgt het NIP-46 oppervlak in RPC dispatch-bedrading binnen LightSigner en een PendingRequest schema dat de v3-context draagt (kind plus scope), zodat de signer kan vastleggen voor welke event-kind en use case de v3-payload is goedgekeurd.

Clave wijkt af van Amber op het gebruikersgerichte oppervlak. Een permission grant schema met sensitivity tiers laat gebruikers v3-versleuteling verlenen voor een bepaalde event-kind en scope op een gekozen sensitivity-niveau. Bij eerste ontmoeting introduceren v3-context-aware approval prompts met een one-time explainer card v3 aan gebruikers. Het werk zit in main en is aangesloten op het Xcode project maar is onuitgebracht; de meest recente getagde build is v0.2.0-build79 van 12 mei.

Twee onafhankelijke implementaties landen NIP-44 v3 in productiepaden voordat de NIPs PR merged, wat de zaak versterkt voor het onderliggende wire format dat de protocol-PR zal formaliseren. Cross-implementation interop-testing wordt nu het pad naar spec-convergentie, met Amber’s Android approval-oppervlak en Clave’s iOS sensitivity-tier model als de twee referentiepunten. Andere remote signers die v3 aansluiten (nsec.app’s noauth is sluimerend sinds mei 2025, en andere bunkers hebben geen v3-werk aangekondigd) zouden de consensus verder aanscherpen.

NIP-34 activiteit: Iris adopteert de stack met een nieuwe hashtree-transport

Iris publiceerde NIP-34 repo-announcements voor hashtree op 8 juni en iris-apps, iris-drive en iris-chat-rs op 9 juni, met clone-URLs onder een nieuw htree:// schema geserveerd vanaf wss://temp.iris.to. De hashtree-transport is een content-addressed alternatief voor GRASP-gerouteerde clones, en deze vier announcements zijn de eerste publieke uses. De repos dragen lege beschrijvingen en de architecturale details ontstaan nog, maar de keuze om via NIP-34 announcement te publiceren (in plaats van via een aangepast Iris-intern manifest) signaleert dat Iris zich committeert aan de bredere NIP-34 git-over-Nostr stack.

NIP deep dive: NIP-67 (EOSE Completeness Hint)

NIP-67 sluit een van de langststaande correctheidsgaten in NIP-01. De oorspronkelijke spec definieert EOSE als de grens tussen opgeslagen events en live subscription-events voor een REQ, maar heeft nooit gespecificeerd of de relay alle opgeslagen matches had geleverd of halverwege was gestopt vanwege een interne cap. Elke relay handhaaft een per-subscription cap (vaak 300 tot 1000 events) onafhankelijk van de limit van de client, en clients hebben geen manier gehad om die cap waar te nemen.

De standaard workaround was het vergelijken van de received count tegen de gevraagde limit. Als received < limit, behandel het resultaat dan als compleet; anders pagineer met until=<oldest_created_at>. Beide takken zijn kapot. De received < limit tak trunceert stil: een client die 500 notes vraagt tegen een relay gecapt op 300 ziet 300 events, concludeert dat het resultaat compleet is omdat 300 < 500 en haalt de rest nooit op. Gehouden events op de relay kunnen “more available” niet signaleren via enig bestaand bericht. Paginering als de tweede tak is verspillend: een filter dat precies de cap matcht vereist een tweede REQ om voltooiing te bevestigen, en retourneert nul events terwijl een volledige filter-scan op de relay wordt verbruikt.

De fix van NIP-67 is één optionele string op het EOSE bericht:

["EOSE", "<sub_id>", "finish"]   // expliciet: alle opgeslagen events geleverd
["EOSE", "<sub_id>"]              // geen completeness claim

Een relay die NIP-67 adverteert in NIP-11 supported_nips en een kale EOSE uitzendt vertelt de client dat er meer is. Een relay die de advertentie weglaat houdt het huidige gedrag en de client valt terug op de bestaande heuristiek. Legacy clients negeren het trailing array-element. Backward compatibility geldt in beide richtingen, zonder nieuwe verbs of event-kinds.

Wat NIP-67 het bekijken waard maakt is de scope die het bewust beperkt. De spec definieert geen cursor of paginatietoken, dus until-gebaseerde paginering blijft het mechanisme. Relay-caps blijven waar ze zijn, en de NIP vereist geen blootstelling ervan. NIP-67 behoudt de betekenis van EOSE als de opgeslagen-naar-live grens en voegt alleen een ja-of-nee signaal toe op de grens: “Ik heb meer voor je” versus “dat is alles.” Dit minimale oppervlak is waarom de PR merged na een relatief korte reviewperiode voor een NIP-01 uitbreiding, en waarom mattn in de PR expliciet opmerkt dat AI-vertaling werd gebruikt voor de Engelse tekst. De verandering is klein genoeg dat de vertaalonzekerheid er niet toe doet.

Voorbeeld van een NIP-67-bewuste uitwisseling tussen een client en een cap-afdwingende relay. NIP-11 advertentie van de relay:

{
  "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
  "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
  "created_at": 1781136000,
  "kind": 11,
  "tags": [],
  "content": "{\"supported_nips\":[1,11,50,67]}",
  "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

De wire-level uitwisseling die volgt:

→ ["REQ", "abc", {"kinds":[1],"limit":500}]
← [...300 EVENT messages...]
← ["EOSE", "abc"]               // no "finish": cap hit, more available
→ ["REQ", "def", {"kinds":[1],"limit":300,"until":1780900000}]
← [...178 EVENT messages...]
← ["EOSE", "def", "finish"]     // explicit complete

De 178-event response zou eerder een derde REQ hebben getriggerd om voltooiing te bevestigen. Met NIP-67 stopt de client daar.

NIP-67 is ook opmerkelijk als een NIP-01 amendement dat landt met zeldzame consensus. De meeste NIP-01 wijzigingen trekken lange debat-threads aan omdat het minuscule oppervlak van het protocol dragend is voor elke implementatie. NIP-67 merged na een uitgebreide reviewperiode (ongeveer zeven weken van open tot merge), wat suggereert dat wanneer een NIP-01 wijziging klein genoeg is en de faalmodus concreet genoeg (silent data loss, verplichte verspilde round trip), de maintainers van het protocol bereid zijn de core message-vocabulaire uit te breiden.

NIP-50 definieert het search filterveld in REQ berichten, waardoor clients een relay kunnen vragen events te filteren op full-text match tegen een query-string. De gemergde basisspec is bewust minimaal: het search veld is een string, elke relay bepaalt zijn eigen search-semantiek (welke velden geïndexeerd zijn, hoe scoring werkt, of stemming toepast) en relays adverteren NIP-50 ondersteuning in hun NIP-11 document. Clients besturen het search-algoritme alleen via de query-string zelf.

Dit minimalisme is zowel NIP-50’s kracht als zijn beperking. De kracht is dat elke relay search op elk kwaliteitsniveau kan implementeren: een basis-substring scan voldoet aan de spec, en een relay die Elasticsearch of Meilisearch draait voldoet er gelijkwaardig aan. De beperking is dat clients geen manier hebben om search-intentie uit te drukken. Een profile-mention typeahead UI wil prefix-matching tegen display names; een full-text content search wil getokeniseerde full-text scoring over de note-body. Hetzelfde search veld draagt beide, en de relay moet gokken uit de query-vorm.

PR #2357 voegt de eerste NIP-50 uitbreidings-token toe: autocomplete:true of autocomplete:false ingebed in de search-query signaleert welke modus de client wil. Ditto’s relay implementeert de token voor follow packs, lijsten en elke event met een title tag, waarbij wordt overgeschakeld naar prefix matching wanneer autocomplete:true aanwezig is. De token leeft inline in de query (aparte filtervelden blijven onaangeroerd), dus het reist met de search-string en vereist geen wire-protocol bump:

search: "fiat autocomplete:true"

Token-shaped hints zoals deze zijn hoe NIP-50 altijd relay-specifieke dialecten heeft afgehandeld. Relays ondersteunden al tokens zoals language:en en domain:example.com. Elk blijft relay-specifiek, waarbij elke relay zijn eigen dialect documenteert. NIP-50’s PR #2357 verheft autocomplete van een relay-privé token naar een spec-gezegend token, waardoor de weg wordt geëffend voor typeahead-bewuste search over relays heen.

Voorbeeld NIP-50 REQ met de autocomplete-token, gericht op een relay die kind 0 profieltitels indexeert:

{
  "id": "b7c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5",
  "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
  "created_at": 1781136000,
  "kind": 1,
  "tags": [
    ["client", "example-mention-picker"]
  ],
  "content": "Sent search: kinds=[0], search=\"fiat autocomplete:true\", limit=10",
  "sig": "12d3e4f5061728394a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5e6f7081a2b3c4d5e6f708192"
}

De daadwerkelijke wire-level REQ:

["REQ", "mention-picker", {"kinds":[0],"search":"fiat autocomplete:true","limit":10}]

Een relay die de token niet herkent behandelt autocomplete:true als onderdeel van de literale search-string en valt terug op full-text matching, waarbij correcte (zij het anders gerangschikte) resultaten worden geretourneerd. De graceful degradation maakt de token veilig om onvoorwaardelijk op te nemen voor clients die prefix-matching verkiezen wanneer beschikbaar.

De volgende waarschijnlijke NIP-50 uitbreiding is per-kind ranking-controle: een hint die zegt “rangschik op created_at aflopend” versus de standaard relevantie-score. Verschillende relays accepteren al sort:newest als een relay-privé token, en hetzelfde verheffingspad dat autocomplete in de spec bracht is van toepassing. Search blijft een van de weinige Nostr-primitieven waarin relays concurreren op resultaatkwaliteit; betrouwbaarheid van levering is hetzelfde over alle conforme relays. Incrementele tokens laten clients die kwaliteitsconcurrentie exploiteren zonder relays te dwingen een zware nieuwe spec te leveren.