# Nostr Compass #25 — Magyar Összefoglaló **Dátum:** 2026. június 3. **Forrás:** https://nostrcompass.org/en/newsletters/2026-06-03-newsletter/ --- ## Top Stories ### Amber 6.2.0: NIP-44 v3 titkosítás a spec előtt Az Amber (domináns Android signer) június 1-jén kiadott v6.2.0 verziója NIP-44 v3 titkosítást szállít dedikált approval képernyővel, intent előnézettel, bunker preview-val, history logging-gal és auto-rejecttel az érvénytelen kérésekre. A release regisztrálja a NIP-44 v3 ContentProvider authority-kat is, hogy más Android appok is kérhessék a v3 titkosítást a v2 mellett. A NIP-44-et a NIP-17 privát DM-ek, NIP-46 bunker forgalom és más Nostr primitívek használják; a v3 opcionális a v2 mellett, külön signer metódussal jelezve, így a fogadó oldali kliensek explicit egyeztethetik az algoritmust. A vonatkozó NIPs PR még nem landolt, szóval Amber a protokoll-konszenzus előtt rolloutolja a v3-at. A NIP-46 session-ök mostantól auto-elfogadják a ping kéréseket connectkor, eltávolítva az első round-trip promptját. A sign_message signer metódus teljesen törlődött (elavult és nem használt). **Trades-off:** Mivel Amber a domináns Android signer, minden downstream kliensnek, amelyik v3-at akar, az Amber wire formatját kell céloznia, amíg a NIPs PR landol. Ez ideiglenesen egyszeri implementációs referenciaponttá teszi, amit más klienseknek követniük kell. ### Mostro: Cashu escrow integráció CDK-n keresztül A grunch nyolc PR-t landolt a MostroP2P-n ezen a héten, integrálva a Cashu meglévő P2PK multisig primitívjeit (NUT-10 és NUT-11) második settlement backendként a Lightning mellé a Nostr-koordinált P2P Bitcoin exchange-en. A kriptográfiai primitívek Cashu sajátjai; a munka integrációs scaffolding és egy új escrow backend trait. A Mostro core v0.12.0 (május 30.) hozzáadja a 2-of-3 multisig escrow protokoll típusokat, a per-proof P_M signatúrákat, és engedélyezi az escrow eventeket a response validáción. Az architektúra a PR #756-ban dokumentált, a per-order trade key-eket a PR #757 tisztázza. A rollout hat follow-up PR-en keresztül ment egy nap alatt. F2 (PR #758): config, escrow mode, feltételes boot. F3 (PR #760): EscrowBackend trait Lightning implementációval és Cashu stub-bal — az order state machine változtatása nélkül lehet settlement backendet váltani. F4 (PR #759): CDK (Cashu Development Kit) wrap mint és wallet műveletekhez. F5 (PR #761): compare-and-swap escrow zárak és active-locked query-k. F6 (PR #762): containerizált mint dedikált CI job-ban end-to-end escrow teszthez. A Mostro flow amúgy is NIP-59 gift-wrapped DM-eket használ order koordinációra a relay-en, szóval a Cashu escrow simán beilleszkedik második settlement opcióként a Lightning mellett anélkül, hogy a wire protokollhoz hozzányúlna. ## Releases ### ngit v2.5.0: GRASP fallback és lusta git fetch-ek Az ngit v2.5.0 megváltoztatja a `git push pr/` é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=` 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", "", ""]`. 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.