Nostr Compass #25 — Magyar Összefoglaló¶

Dátum: 2026. június 3. Forrás: https://nostrcompass.org/en/newsletters/2026-06-03-newsletter/

Releases¶

ngit v2.5.0: GRASP fallback és lusta git fetch-ek¶

Az ngit v2.5.0 megváltoztatja a git push pr/<branch> és ngit send alapértelmezett viselkedését: PR kind eventet produkál új proposalokhoz, ha a repóban van legalább egy regisztrált GRASP szerver. Korábban ez csak 60 KB feletti commitoknál vagy submodule-okat tartalmazó commitoknál triggerelődött. Ha a PR-t nem lehet a repo GRASP szervereire pusholni, az ngit most GRASP-06 routingra esik vissza a deklarált szervereken át. Az ngit send --git-server flag vagy git push -o git-server=<url> explicit egyedi git URL-t vagy GRASP szervert céloz.

ngit init republish megőrzi az ismeretlen tag-eket a meglévő announcement-ökből, szóval a jövőbeli ngit verzió vagy third-party tool által hozzáadott tag-ek túlélik a republish-t. Sárga warning listázza a carried-over tag-eket, és --clean kérésre eltávolítja őket. ngit pr apply, ngit pr checkout, ngit pr list lustán konzultálják a git szervereket és osztoznak egy fetch helper-en, szóval a checkout nem fetchel feltétlenül, ha a commit már lokális. A checkout a submitter-supplied clone URL-eket is megpróbálja fallbackként, ha a repo deklarált git szerverei nem hordozzák a PR tippet. Az ngit a referenciaként szolgáló NIP-34 implementáció git collaboration-höz Nostr felett, és a v2.5.0 a GRASP-ot teszi első osztályú úttá új contributorok számára.

Jumble v26.5.7: EXIF stripping és validált zap count-ok¶

A Jumble v26.5.7 két, közvetlenül a user privacy-t és data integrity-t érintő változást hoz. Az EXIF location és camera azonosítók mostantól törlődnek a kép feltöltésekből, mielőtt elhagyják a klienst — ez egy régóta fennálló metadata-szivárgási felület volt, ami minden Jumble-ból posztolt képet érintett. A zap count-ok mostantól csak kriptográfiailag validált receipt-ekből számítódnak, kijavítva a felfújt count-okat a malformed zap eventekből, amikkel támadók túlbecsülhették a note-ok zap összegét. A release sender-identity verifikációt is hozzáad a NIP-17 DM-ekhez, bezárva egy spoofing felületet, ahol a sender hamisíthatta a pubkey-jét a seal-ben.

nostr-calendar v1.6.0: RSVP és duplikált participant kezelés¶

A nostr-calendar v1.6.0 landolja a Formstr RSVP flow-t (PR #169) és megakadályozza a duplikált participant-okat event invite-okban (PR #168). A waitForAll opció a publish függvényben mostantól default false, szóval a UI nem blockol lassú relay-eken (PR #170). A PR #157 szállította a Formstr két NIP proposal draftját appointment scheduling-hez és reservations-höz.

Sprout 0.3.6: Sprout × mesh-llm és channel sections¶

A Sprout v0.3.6 egy hat kiadásból álló sor (v0.3.1–v0.3.6) főcíme ezen a héten. Az in-process Sprout × mesh-llm integráció a PR #798-ban landol, lehetővé téve, hogy a Sprout mesh-llm node-okat szolgáljon és fogyasszon relay admissionön át. A user-defined channel sections device-ok között szinkronizálódnak Nostr-on át a PR #792-ben, a channel sections mobilra is megérkeznek relay szinkronnal a PR #800-ban. Thread-aware notification-ök mutable follow és mute kontrollokkal a PR #761-ben.

Tetszőleges fájltípusú attachment-ek download card-okkal a PR #810-ben, kibővítve a Sproutot az image-only attachment-eken túlra. A mobil Pulse social feed tab-ot kapott (PR #772) és Pulse polish-t feed, compose és filter surface-eken (PR #796).

NostrBotKit v0.5.0: Marmot group chat Rust bot frameworkben¶

A NostrBotKit v0.5.0 (május 24., Codeberg) Marmot (MLS-over-Nostr, NIP-104) támogatást ad a self-hosted Rust bot frameworkhöz. Ha marmot: true van beállítva, a bot publikálja az MLS key package-jeit (kind 443, 30443, 10051), automatikusan elfogadja a group invitation-öket, és figyeli az üzeneteket a csatlakozott group-okban. Két új command típus: dm_marmot és dm_marmot_npub — botok named Marmot group-okba vagy 1:1 Marmot chat-ekbe küldhetnek üzeneteket cron job-ok vagy webhook-okon át. Hogy elkerüljék a feedback loop-okat más botokkal, a NostrBotKit botok csak explicit a /command vagy @botname/command módon címzett üzenetekre válaszolnak. Az MIP-04-gyel titkosított attachment-ek auto-decryptálódnak és re-uploadolódnak Blossom-on vagy NIP-96-on át, az MLS state database a bot privát key-jéből derivált kulccsal van titkosítva. A NostrBotKit az első Rust framework, ami NIP-104 bot támogatást szállít, megnyitva a Marmot-titkosított bot deploymentet egy másik operátor profil felé, mint a meglévő TypeScript út.

noscrypt v0.1.14: signed cryptography library release¶

A noscrypt v0.1.14 a C cryptography library biztonsági release-e, amit több Nostr kliens használ secp256k1, NIP-04 és NIP-44 primitívekhez. A release PGP-signed download-okkal érkezik, amik a maintainer publikus kulcsa ellen verifikálhatók. A noscrypt-ot bundle-ölő downstream klienseknek validálniuk kellene a signatúrát integráció előtt.

Chama v1.3.0: új Nostr-native P2P escrow Fedimint-tel¶

A Chama v1.3.0 (június 1.) egy négy kiadásból álló sor főcíme egy új Nostr-native P2P escrow klienshez, ami Fedimint ecash-t és 2-of-3 Shamir secret sharing-et használ settlement-hez. A project a getchama.app-on érhető el és szerver nélkül fut. A v1.3.0 bevezeti a "heal that sticks"-et (sikeres re-broadcast és trade healing, ami session restartokat túléli) és a pay-rail matching-et, ahol az US-leaning Chama-k US payment rail-eket preferálnak. Multi-unit storefront alapok landoltak a v1.2.11-ben (multi-unit schema) és a v1.2.12-ben (storefront stock accountant + natív Fedimint bridge recovery hardening). A Chama csatlakozik a Mostro-hoz és a Shopstr-hez a Nostr marketplace kategóriában, megkülönböztetve a serverless architektúrájával és Fedimint-alapú escrow settlement-jével.

Unreleased changes¶

Amethyst: NIP-32 hashtag labeling, podcast screen, music tracks¶

Az Amethyst 52 PR-t és 411 commitot merge-elt ezen a héten release tag vágása nélkül. A legnagyobb funkcionális kiegészítés a PR #3111, ami implementálja a NIP-32 hashtag labelinget és egy label-alapú hashtag feed-et kind 1985 eventekkel L namespace és l label tag-ekkel. Ez leváltja a törékeny text-match #tag mechanizmust egy labeler-alapú discovery modellel, ahol a userek specifikus labeler npub-okat követhetnek úgy, ahogy content creatore-okat követnek. A PR #3105 dedikált podcast screen-t ad episode listával és inline playerrel, landolva a NIP-F4 podcast spec merge-je után napokkal. A PR #3071 Software Apps feed-et ad follow-list filterrel, a PR #3067 pedig music tracks és playlists támogatást NIP-51 set-eken át.

Ephemeral signerek anonymous poszt feltöltésekhez a PR #3123-ban landolnak, lehetővé téve, hogy a user anonymous posztoljon anélkül, hogy az identity key-jét felfedné upload service-eknek. Egy Tor self-heal watchdog integration tesztekkel Arti v2.3.0 ellen a PR #3053-ban, erősítve az Amethyst Tor routingját tranziens network outage-ek alatt. Onchain zaps és NIP-05 filter returning usereknek Gemini-től a PR #3052-ben, kiterjesztve a zap surface-t a Lightningön túlra onchain Bitcoin fizetésekre.

Shopstr: OpenGraph preview URL validáció¶

A PR #504 validálja az OpenGraph preview URL-eket, mielőtt megjelenítené őket marketplace listing-ekben, bezárva egy potenciális XSS felületet, ahol rosszindulatú eladók scripted contentet embedelhettek volna craftolt OG metadata-n keresztül. A Shopstr-hosted shop-ok OG preview-kat jelenítenek meg külső linkekhez, és a nem validált URL-ek lehetővé tették, hogy egy támadó tetszőleges contentet injektáljon a shop UI-ba.

NIP frissítések és protokoll spec munka¶

NIP-F4 (Podcasts) merge-elt két év után¶

A PR #1093 május 28-án merge-elt, két évvel és három hónappal azután, hogy fiatjaf megnyitotta az eredeti draftot. A NIP-F4 podcast episode-okat kind 54 eventekként definiálja imeta tag-ekkel audio file metadata-hoz (URL, mime type, language ISO code, fallback URL-ek, NIP-96 service flag, bitrate, duration), title tag-gel, opcionális image és description tag-ekkel, és t tag-ekkel topic labelekhez. A spec szándékosan RSS-t tartja a source of truth-nek: az episode-ok hordozhatnak i tag-et, ami az RSS podcast GUID-ra hivatkozik, lehetővé téve Nostr klienseknek, hogy linkeljenek meglévő podcast feed-ekhez az audio hosting duplikálása nélkül. A hosszú debate a PR thread-ben (podcast-namespace co-author Dave Jones, Alex Gleason és Mike Terenzio részvételével) egy koegzisztencia modellben állapodott meg, ahol a Nostr biztosítja a social layer-t az RSS felett, míg az RSS tartja a distribution layer-t. Az Amethyst PR #3105 podcast screen-je napokkal a spec merge után landol, és a Jumble GIF picker munkája is tartalmaz early podcast-attachment scaffolding-ot.

NIP-17 key decoupling (PR #2361)¶

fiatjaf június 1-jén nyitotta a PR #2361-et, ami azt javasolja, hogy a NIP-17 válassza szét az identity key-t az encryption key-től. A recipient-ek új kind 10044 eventben hirdetik az encryption key-jüket, és a senderek ezt a hirdetett key-t használják (ha jelen van) a gift-wrap inner seal-hez, csak a recipient identity key-jére fallbackelve, ha a hirdetmény hiányzik. A PR egy n tag-et is hozzáad a seal-hez, ami a sender encryption pubkey-jét hordozza, szóval a fogadók a helyes conversation key-t kikövetkeztethetik trial-decryption nélkül minden retired key ellen. A kimondott motiváció a bunker UX: a jelenlegi dizájnban egy bunker user minden fogadott DM-et round-trippel a signeren át kell decryptáljon, mivel az encryption key a signer által tartott identity key. A decoupling lehetővé teszi, hogy a kliens lokálisan tartsa az encryption key-t, míg az identity key a bunkerben marad signatúrákhoz.

A proposal megkapta a hét legkonfliktusosabb review-ját. Cody Tseng (Jumble) támogatja, mint a cross-client DM interop legegyszerűbb útját. Vitor Pamplona (Amethyst) két okból objektál: új hosszú-élettartamú decryption secretet ad a bunkerön kívülre, és a klienseket, amik nem szállítják, csendben elbuknak az üzenetek decryptálásánál azoktól a kliensektől, amik igen, degradation path nélkül, mert a törés a seal rétegnél van. Pamplona érvelése szerint a problémát már helyesen megoldja a Marmot key package-ek és epoch rotáció, és a kulcsszétválasztás retrofitelése a base NIP-17 specbe olyan interop failure-t teremt, amit a Marmot két évig tervezett ki. fiatjaf countere három részből áll: a decoupling opcionális per-recipient, az n-tag fix címezi a trial-decryption aggodalmat, és az alternatíva a bunker UX broken tartása, míg a Telegram megeszi a messaging use case-t. A thread maradt nyitva merge döntés nélkül, és a negyedév legjobban figyelt NIP diskussziója.

NIP-Silent Payments payment flow (PR #2362)¶

silentius-satoshi június 1-jén nyitotta a PR #2362-t a szélesebb Nostr Silent Payments NIP draft (PR #2355) társaként. A payment-flow NIP definiálja a kind 8352-t silent payment receipt notification-ökhöz (NIP-59 gift wrap-en keresztül szállítva, hogy a receipt link ne legyen publikusan megfigyelhető) és a kind 10353-at egy titkosított UTXO cache-hez, ami device-ok között szinkronizálódik ugyanannak a Silent Payments walletnek. A pár együtt lehetővé teszi, hogy egy payer Nostr-native primitívekkel jelezzen egy fizetést egy Silent Payments címre anélkül, hogy az on-chain linket felfedné a nyílt relay rétegen.

NIP-PIP Perfect IP Packets (PR #2364)¶

RandyMcMillan június 1-jén nyitotta a PR #2364-et draftként. Packet-tree transportot vezet be három új addressable kind-del: 39078 hordozza a manifestet, 39079 hordozza az egyes slice-okat, 39080 hordozza a repair request-eket. A spec olyan wire formatot definiál, ahol nagy fájlok addressable slice-okra tördelődnek, manifestek írják le a slice fát, és repair request-ekkel a fogadók kérhetik a hiányzó slice-okat. Early-draft státusz érvényes, a proposal még nem vonzott maintainer review-t.

NIP-29 audio/video live spaces (PR #2238)¶

A PR #2238 május 28-án merge-elt, kiterjesztve a NIP-29 relay-alapú group-okat audio és video live-space támogatással. A group-ok mostantól hivatkozhatnak aktív live-space session-re, lehetővé téve, hogy NIP-53-stílusú live activity eventek NIP-29 group kontextusba anchorolódjanak.

NIP-71 video multiple audio tracks (PR #2255)¶

A PR #2255 május 28-án merge-elt, audio-track imeta tag-eket adva a NIP-71 video eventekhez. Az új formátum URL-t, hash-t, mime type-ot, language tag-et (ISO-639-1 plus original-version flag-gel), fallback URL-eket, NIP-96 service signalt, bitrate-et és duration-t hordoz. Ez lehetővé teszi audio-only streaminget (video podcastok), resolution switchelést stabil audioval, több nyelvi track-et, és csökkentett storage-ot, ha a szerverek nem embedelnek audiót közvetlenül a videó fájlokba. A klienseknek ellenőrizniük kellene az audio-track elérhetőséget, mielőtt single-track viselkedést feltételeznének.

NIP-59 ephemeral gift wrap (PR #2245)¶

A PR #2245 május 28-án merge-elt, a kind 21059-et adva a meglévő kind 1059 gift wrap ephemeral counterpartjaként. A szematika megegyezik a standard NIP-59 wrap-pel, de ephemeral event rules-t követ NIP-01 szerint (a relay-ek droppolják broadcast után és nem perzisztálják). Ez lehetővé teszi, hogy appok a perzisztencia igényeik alapján válasszanak: typing indicatorok és presence pingek profitálnak az ephemeral-ből, míg a DM history-nak perzisztencia kell.

NIP-78 application-specific kind (PR #2292)¶

A PR #2292 május 28-án merge-elt, a NIP-78 application-specific data-t normál addressable kinddé reklasszifikálva, eldobva a korábbi külön range-et. Ez egyszerűsíti a replaceability szematikát és a NIP-78-at a többi application-state NIP által használt addressable event modellhez igazítja.

NIP-85 clarifications (PR #2304)¶

A PR #2304 május 28-án merge-elt, kis javításokkal a nyelvezetben a NIP-85 Trusted Assertions service providerenkénti több kulcs és relay körül, tisztázva az operátor-key-rotation útvonalat relay assertion service-ekhez.

NIP-01 relay connection management one-liner (PR #2307)¶

A PR #2307 május 28-án merge-elt, egyetlen mondatot adva a NIP-01-hez arról, hogy a kliensek hogyan kezeljék a relay connection lifetime-okat. A fix egy régóta fennálló gap-et címez, ahol a kliensek különböztek abban, hogy nyitva tartják-e a WebSocket connection-öket fetchelés után, csendes message loss-hoz vezetve olyan relay-eken, amik idle connection-öket droppolnak.

NIP-C7 kind 9 chat constraint (PR #2310)¶

A PR #2310 május 28-án merge-elt, a NIP-C7 chat view-kat kind 9 üzenetekre korlátozva. Ez szétválasztja az ephemeral chat-et a kind 1 timeline posztoktól olyan kliensekben, amik NIP-C7-stílusú chat surface-eket implementálnak.

NIP-55 simplification (PR #2363)¶

A greenart7c3 által jegyzett PR #2363 (június 1.) egyszerűsíti az Android signer application spec-et. Vitor Pamplona "Looks good"-ként signoffolta, fiatjaf megkérdezte, hogy merge-ready-e. A változás megnyitja az utat a NIP-44 v3 ContentProvider authority registration előtt, amit az Amber ezen a héten szállított.

NIP-44 v3 (Amber implementáció a spec előtt)¶

Az Amber NIP-44 v3-at szállított a v6.2.0-ban nyolc committal, ami implementálja a titkosítási upgrade-et és a ContentProvider authority registration-t, de a NIPs-repo spec PR még nem landolt. A NIP-44 versioned encrypted payload formatot definiál, amit signed eventeken belül használnak; a meglévő v2 (2024 óta production) secp256k1 ECDH-t, HKDF-et, paddinget, ChaCha20-at, HMAC-SHA256-ot és base64-et használ. A v3 wire format új version byte-ot (0x03) ad a nonce elé, lehetővé téve a fogadó klienseknek, hogy explicit egyeztessék az algoritmust. Az Amber implementáció tartalmazza a v3 invalid request-ek auto-rejectjét, dedikált approval screen-t a v2 approval-októl distinct módon, és per-direction plaintext loggingot a historyhoz. Amíg a NIPs PR nem merge-el, a v3 Amber-specifikus extensionként áll. Forward-looking signalnak kezelendő, nem stabil protokoll-szintű signalingnak.

NIP deep dive: NIP-32 (Labeling)¶

A NIP-32 strukturált módot definiál bármely Nostr actor számára, hogy eventeket, pubkey-ket, relay-eket, URL-eket vagy topic-okat labeleljen addressable kind 1985 eventekkel namespaced label vocabularryal. A spec két új tag-et vezet be: L jelöli a label namespace-t, l jelöli a labelt a namespace-en belül. Label-target tag-ek (e, p, a, r vagy t) specifikálják, hogy mi van labelelve. A namespace-követelmény megakadályozza, hogy több label rendszer összeütközzön: egy spam label a nip28.moderation-ben más szematikát hordoz, mint egy spam label a relay-report-ban.

A design választás, ami a NIP-32-ot a moderationön túl hasznossá teszi, hogy a labelek assertion-ök, nem protokoll-szintű igazság. Egy kind 1985 event csak annyit mond, hogy egy adott pubkey egy adott targetet labelelt egy adott namespace-ben. A trust model a kliensre van delegálva: minden kliens kiválasztja, mely labelereket honorolja, mely namespace-eket olvassa, és milyen UI affordancet ad mindegyik labelnek. Ugyanaz a primitív hordoz content warningokat, license assignmentet, ISO-639-1 language tag-eket kind 1 note-okon, ISO-3166-2 geographic tag-eket, content classificationt, distributed moderation suggestion-öket és reputation score-okat.

Az Amethyst PR #3111 ezen a héten a legnagyobb deployment eddig. NIP-32-n keresztül hashtag labelinget ad és egy label-alapú hashtag feedet, lehetővé téve a usereknek, hogy trusted labelerek által hozzárendelt labelek szerint böngésszenek. A korábbi #tag text-match mechanizmus, ami eredetileg a hashtag discovery-t hajtotta a Nostr-on, fallbackként marad un-labeled note-okhoz. A hashtag-as-label modell azt jelenti, hogy ugyanaz a note több label alatt is felfedezhető, amiket különböző labelerek rendeltek hozzá, és a userek muteolhatnak vagy boostolhatnak specifikus labelereket az underlying note-ok érintése nélkül.

Self-labeling is támogatott. Egy author közvetlenül a saját kind 1 note-jaihoz csatolhat L és l tag-eket, hogy deklarálja a nyelvet, lokációt és topicot. Egy note, ami ["L", "ISO-639-1"], ["l", "en", "ISO-639-1"] tag-eket hordoz, magát English-ként azonosítja, és language-aware klienseknél harmadik-fél labeling infrastruktúra nélkül szűrhető.

Az Amethyst rollout a közelmúlt Trusted Relay Assertions munkájával kombinálva azt sugallja, hogy a NIP-32 bármely "user-driven assertion about a target" minta standard szubsztrátumává válik a Nostr-on. A következő teszt az, hogy a labelerek maguk kifejlesztenek-e trust hierarchiákat: a userek fognak-e specifikus labeler npub-okat követni úgy, ahogy content creatore-okat.

NIP deep dive: NIP-F4 (Podcasts)¶

A NIP-F4 ezen a héten merge-elt, két évvel és három hónappal azután, hogy fiatjaf megnyitotta az eredeti draftot (PR #1093). Az F prefix sima hex numbering: NIP-F0–NIP-FF ugyanazt az 1-byte hex teret használja, mint NIP-0A–NIP-0D, a felső hex range overflow-ként szolgál, most, hogy a 01–99 decimális range megtelik. A NIP-F4 azt definiálja, hogy a podcastok hogyan publikálnak episode-okat és metadata-t Nostr eventekként, miközben az RSS-t komplementer layerként tartja magához az audio fájlhoz.

A core architektúrális választás az, hogy minden podcast a saját Nostr keypairje. A spec ezzel nyit: "each podcast is its own Nostr keypair". Ez lehetővé teszi, hogy a podcastok kombinálják a podcasting jelenlétüket egy normál kind 0 / kind 1 microblogging jelenléttel, és lehetővé teszi, hogy egy podcast az idő során váltson ownership-et key handover-en vagy MuSig2-stílusú shared signing-on át. Négy event kind hordozza a publishing layer-t:

kind:10154: replaceable podcast metadata. Title-t, image-et, description-t, opcionális website tag-eket, és opcionális p tag-eket hordoz, amik author-okat jelölnek host, cohost vagy editor role-lal.
kind:10164: author counter-claim. A spec példája kind 10064-et mutat (egy elírás, nyitva a korrekcióra), de a heading és a környező szöveg kind:10164-ként azonosítja. A userek listázzák a podcast pubkey-ket, amiket authorolnak, hogy a kliensek verifikálhassák a p tag-eket a kind:10154-ben egy equivalens claim ellen a supposed author-tól. Enélkül egy podcast hamisan tagelhet bárkit host-ként.
kind:54: episode eventek, amiket a podcast pubkey közvetlenül authorol. Tag-ek: title, opcionális image, description, és egy vagy több audio tag. Minden audio tag ["audio", "<audio-url>", "<optional_media_type>"]. A spec megjegyzi: "other important fields to be specified here later after further discovery", a merge-elt forma szándékosan minimális.
kind:10054: NIP-51-stílusú favorite-podcasts lista, ami lehetővé teszi a usereknek, hogy megjelöljék, mely podcastokat követik.

A thread debate a merge körül Dave Jones (Podcasting 2.0 co-author), Alex Gleason, Mike Terenzio, Pablo F7z és staab részvételével zajlott. Jones erősen érvelt bármilyen kísérlet ellen, ami az RSS-t helyettesítené: "It's been tried many times and always fails", citálva a JSONfeed-et, XMPP-t, AMP-t, Twitter API-ját és Spotify sikertelen migrációját. Terenzio újraframetezte a proposal-t social layer-ként az RSS felett, az RSS-t tartva distribution layer-ként. fiatjaf beleegyezett, hogy visszalép és hagyja a proposal-t érni: "I agree with everything you said but I still think we can pull it off, let's stop here for a while". Két évvel később a merge-elt spec közelebb van a koegzisztenciához, mint a helyettesítéshez.

Három design kérdés maradt explicit a merge-elt specben:

A kind:10164 elírást (a példa 10064-et mutat) egyeztetni kell, mielőtt a kliensek biztonságosan interoperálhatnak.
Episode-szintű discovery RSS GUID linking nélkül nyitva maradt. A merge-elt specnek nincs i tag-je, nincs podcast:item:guid formatja, és nincs RSS bridging mechanizmusa. A kliensektől, amik egy meglévő RSS katalógust akarnak kind 54 eventekbe hidalni, maguknak kell definiálniuk a bridge konvenciót.
Az "other important fields" stub a kind:54 definíción nyitva hagyja a bitrate-et, duration-t, language-t, transcript pointer-eket, chapter-eket és per-segment metadata-t follow-up proposal-ök számára.

Az Amethyst PR #3105 dedikált podcast screen-t landol episode listával és inline playerrel a merge után napokkal, az első nagyobb kliens implementáció. A Jumble early podcast attachment scaffoldingot szállított a GIF picker mellett. A Wavlake marad a legnagyobb Nostr-native podcast platform, és döntenie kell, hogy a meglévő kind 31337 music track eventeit összehangolja-e a NIP-F4 kind 54 episode modelljével.

A PR #1093 27 hónapig volt nyitva, jóval a merge-elt NIP PR-ek medián nyitvatartási ideje felett. A NIP-F4 következő tesztje az, hogy a kind 10164 elírás reconciliálódik-e, hogy az episode-discovery és RSS-bridge konvenciók kiemelkednek-e az implementerekből, és hogy a nagyobb podcast host-ok per-podcast keypair-ek alatt publikálnak-e, ahogy a spec ajánlja.

Összegzés¶

A #25-ös szám legfontosabb fejleményei: Amber NIP-44 v3-at szállít a spec előtt (a domináns Android signer átmenetileg egyszeri implementációs referenciaponttá válik, amíg a NIPs PR landol), Mostro 8 PR-en át Cashu escrow-t integrál CDK-n (második settlement backend Lightning mellett), NIP-F4 (Podcasts) 27 hónap után merge-elt (RSS marad source of truth, Nostr social layer felette), NIP-17 key decoupling proposal (PR #2361) a hét legkonfliktusosabb review-ját kapta (bunker UX vs Marmot-style key rotation vita, nyitott maradt), és Amethyst 52 PR-t merge-elt release nélkül (NIP-32 hashtag labeling, podcast screen, ephemeral signerek, onchain zaps). A NIP-32 label-alapú felfedezés Amethyst PR #3111-gyel kezd standard szubsztrátummá válni a user-driven assertion-ökhöz a Nostr-on.