---
title: "Nostr Compass #39 — 2026-09-09"
source: "https://nostrcompass.org/en/newsletters/2026-09-09-newsletter/"
type: newsletter-summary
language: hu
ingested: 2026-09-10
---

# Nostr Compass #39 — 2026-09-09

**Eredeti forrás:** [Nostr Compass #39](https://nostrcompass.org/en/newsletters/2026-09-09-newsletter/)

## Vezértörténetek

### Aláírt git-workflow kerül a Nostrra és a Blossomra (ngit v3 + GitWorkshop + ngit-grasp + ngit-ci)
A szeptember 8-i v3 launch egyetlen aláírt workflow-ba fogja össze az ngit, GitWorkshop, ngit-grasp és ngit-ci eszközöket. Az ngit ágakat, patcheket és PR-eket NIP-34 eseményként viszi, a GitWorkshop adja a review felületet. Az új ngit-ci 0.1 self-hosted CI: az utasítások és az eredmények aláírt Nostr eseményként utaznak, így a check a maintainer saját gépén fut a code review mellett. A release a GRASP-08 privát-repo kiterjesztésen keresztül privát repókat is ad (ngit-grasp v3), és explicitté teszi a maintaineri jogosultságot. Az aláírt release-rekordok Blossom blobokra mutathatnak — a release metaadat és a content-addressed fájlok is kikerülnek a hostolt forge-ból.

### nsite-clay — böngészőből kiadható, visszaállítható site
Az augusztus 31-i signer-prompt javítás, a publication recovery és a szeptember 2-i szerkesztői vezérlők miatt az nsite-clay egyszerű, egyoldalas böngészős publishing eszköz. A user a DOM-ot szerkeszti helyben, serializálja, content-addressed Blossom blobként feltölti, és újrapublikálja a site NIP-5A manifestjét — nincs lokális build vagy szerver. A böngészős publisher mostantól a sikertelen publikációt visszaállíthatóvá teszi, csökkenti az ismételt signer-promptokat, és a szerkesztési útmutató dokumentálja a ciklust. Az eredmény marad egy közönséges NIP-5A site a meglévő gateway-ek számára.

### Wingman App — böngészés + signing + fájlok egyben
A szeptemberi munka fájlválasztókat, profil-publikációt, biztonságos signert, session restore-t és tesztelt mobil buildet ad. A Flutter shell NIP-07 providert injektál az appban megnyitott oldalakba, a Flight Deck és a Tower-hátú Drive pedig work surface-t és fájl-munkafelületet ad a böngésző mellé. A Wingman NIP-98-cal ír alá authentikált HTTP kéréseket — a kliens felépíti az eventet, a szerver ellenőrzi, mielőtt válaszolna; egy telepített identity egységes approval útvonalat kap relay akciókhoz, web-app signinghoz és fájlokhoz.

### Shosho a Livelier self-hosted streameket hozza be
Shosho 1.1.0 szeptember 1-jén shippelt, támogatja a Liveliert, amelynek augusztus 31-i attribution update azonosítja a bridge-t és az Owncast forrást a bridgelt profilokban. A Livelier figyeli az Owncast publikus könyvtárát, ellenőrzi, hogy a stream él-e, majd `kind:30311` NIP-53 addressable eventet publikál. A felfedezés Nostron át zajlik, a videó a streamer saját szerverén marad. A chat `kind:1311` eseményként kel át a bridge-en: a bridge csak akkor nyit source-side kapcsolatot, ha Nostr reader van subscribed, címkézi a származtatott identitásokat, és 3 óra múlva törli az üzeneteket. A discovery relay csak a bridge-kulcsról fogad live-event írást; a chat relay NIP-42 authot és NIP-70 protected-event flaget használ.

### Communitator — relay-sablonok signing előtt áttekinthetők
Az augusztus 31-i launch sorozat kanonikus sablonokat ad Communitatorhoz: kind `10002` relay listák, kind `10063` Blossom szerverek, kind `10050` privát üzenet inboxok. A signer-csatlakozás előtt az app megmutatja a normalizált endpointokat, read/write jogosultságokat, event kindeket, fix publikációs relayeket és célállomásokat. A korlátos signing + publication flow szétválasztja a csatlakozást és az alkalmazást: minden event külön ír alá, egy futam max négy WebSocketet használ, és egy célállomás csak pozitív NIP-01 `OK` után számít. Az eredmény megkülönbözteti a complete / partial / failed / cancelled deliveryt. A megosztott sablonok megbízhatatlan ajánlások maradnak; a consent surface elmagyarázza a relay- és hálózat-megfigyelhetőséget.

### cal.emre.xyz — NIP-52 időpont-foglalás
A publikus repo szeptember 2-i nyitó commitja után szeptember 3-án érkezett egy aláírt handler bejelentés. A host `kind:31923` NIP-52 eventként publikálja az elérhetőséget, a vendég `kind:31925` RSVP-t küld. A rendszer a host eventjeit és az elfogadott busy RSVKet olvassa a relayekről, kizárja az átfedő időszakokat, és a Nostr eventet tartja a scheduling recordnak — nincs külön DB másolat. A host NIP-07, NIP-46 vagy lokális kulccsal ír alá; a vendég generálhat külön kulcsot. A repo az eredményül kapott `naddr` és calendar linkeket is kiadja, az email alapértelmezetten ki van kapcsolva.

### Plektos — privát event egyetlen titkosított csatornában
A szeptember 2-i privát-event implementáció minden Plektos összejövetelt egy Concord titkosított közösségen belüli privát csatornává tesz. A vendéglista, az RSVP roster, a sign-up tábla, a szál, a hozzájárulások, a borítóképek, a szerkesztések és a törlések együtt titkosítva vannak; a meghívó csak az adott event kulcsát hordozza, és nem jelenik meg plain-text calendar event. A szeptember 6-i lifecycle audit az event-definition id-t horgonyozza közvetlen lookuphoz, ha több mint 500 wrap van (paginated fallback megmarad). A meghívó bundle-ok az event vége után 30 nappal lejárnak és letilthatók, de ha valaki már megszerezte a csatorna kulcsot, megtarthatja. Egy külön parser-security javítás a rosszul formázott TLV NIP-19 azonosítókat elbukásra, nem csapdára állítja.

## Címkézett release-ek

- **Vector 0.4.4** (aug 31) — encrypted-community recovery: refounding zárja a megtámadott közösséget a támadók által használt meghívó útvonalra; replacement membership felülírja a lejárt lokális state-et; egy elérhetetlen tag nem fagyasztja a rostert. Üres rotáció elutasítva, promotion megőrzi az online tagokat, és a műveletek megtagadódnak, ha a kötelező tagok nem elérhetők. Moderátori törlések és ban-ek perzisztálódnak, guest book újratitkosítódik jelszócsere után, notification reply-k a beszélgetéshez kötődnek újraindítás után. Recovery-controls, nem kulcsvisszavonás.
- **Primal Android 3.5.27** (sep 3) — signer identity check + wallet-request auth (mindkettő aug 31-én merge). A lokális signing elutasítja a nem egyező identity-jű kérést, a bejövő NIP-47 kérések feldolgozás előtt authentikálódnak. Zap-poll routing szavazatot küld a poll szerzőjének is, ha a poll reply-ban jelenik meg.
- **GRAIN 0.8.0-rc2** (sep 7) — storage-failure javítás: a relay nem ad `OK`-t, mielőtt az async LMDB writer észrevenné a tele storage-et. 80/95%-on figyelmeztet, 97%-on új eventet elutasít (törlési hely meghagyva), post-acceptance writer hibákat jelent. Retention oldest-first, teardown kezeli a késői üzeneteket, az érvénytelen filterek nem dobják el az érvényes testvéreket. Kind `10166` monitor és kind `30166` relay report megerősítve, stale reportok evictálva, fallback relayek megtartva, NIP-11-ben valós live limit és auth jelentve (statikus nullák helyett).
- **LibreNostr 0.5.0–0.5.2** (mind sep 7) — Orbot mode: relayek, zapek, uploadok, média, playback és previews egy SOCKS porton át. Ha az Orbot vagy a proxy nem elérhető, a kapcsolatok leállnak ahelyett, hogy direkt útvonalra szivárognának (fail-closed). A 0.5.1 leállítja a lassú NIP-50 keresések késleltetését a lokális eredményeknél; a 0.5.2 felváltja a rekurzív thread layoutot és javítja a thread sorrendet.
- **SkateSpots** (sep 8, Zapstore release) — opcionális Citrine relay a telefonon: spotok, crew-k, üzenetek és térképadatok lokálisan tölthetők, posztok offline queue-ba kerülnek, a telefon lokális másolatot tart. A meglévő stash és üzenet tartalom end-to-end titkosítva marad. A payment check megköveteli az invoice összeget és a provider által kibocsátott zap receiptet, mielőtt hozzáférést ad vagy hozzájárulást számol.
- **Whistle 1.8.15** (sep 3) — Android lifecycle javítás: route-szintű state-holder-ek nem pusztítják el az alkalmazás-szintű relay subscription-öket és location updateket. Connection state lock vagy doze után frissül, 501-es backlog az observed esetben helyreáll.
- **TWENTY ONE Companion 1.12.0** (sep 5) — NIP-17 gift-wrapped DMs. A titkosított inbox különválik a régebbi space chattől (az sosem volt titkosítva, nem migrálható). PDF és videó relay policy szerint támogatott, a személyes hide-ok sync-elnek anélkül, hogy moderátori banná válnának.
- **ZapStore 1.1.2** (sep 4) — NIP-01 event-id validáció: a kliens újraszámolja a bejövő event id-t, és egyezés hiányában elutasítja, mielőtt felhasználná. A release azonosítja a ZapStore-on kívül telepített csomagokat. A szerveren certificate-hash retention megőrzi az ismétlődő `apk_certificate_hash` tageket, így az Android signing-key rotáció megtarthat egy approved lineage-t.
- **Amber 6.6.1** (sep 4) — permission parsing: a hiányzó opcionális `kind` tolerálva; elutasított signing kérések az eredeti request id-t adják vissza, így a hívó app összepárosíthatja az elutasítást a beküldött művelettel. Remote-signer default-ok frissültek, indexer relay hozzáadva.

## In Development

- **Zap Cooking** (sep 4 merge) — NIP-27 referencia-megjelenítés relay hint-tel: a `nostr:npub` és `nostr:nprofile` hivatkozások cikkekben, receptekben, editor preview-ban és nyomtatási nézetben renderelődnek. Az érvénytelen azonosítók maradnak szöveg, a feloldás non-blocking, az editor a signálandó Markdown preview-ját mutatja. Ha van relay info, a csupasz `npub` `nprofile`-lá válik outbox relayekkel és egyező `p` taggel. Ugyanezen héten: author-scoped kind `30023` olvasás javítva, verifikált NIP-50 search relayek dedup + stale-query guard-okkal, NIP-47 wallet hívások javítva (a dependency change-ek miatt eltört balance és history).
- **Conduit** (sep 2 + sep 7) — Blossom preferencia-szerkesztés + signed preferencia-reconciliation. A Market és Merchant a legutóbbi érvényes kind `10002` relay listát és kind `10050` inbox deklarációt tartja; megőrzi a használható signed listát, ha egy újabb event rosszul formázott; megkülönbözteti az explicit üres listát a nem elérhető lookup-tól; nem cseréli le a failed declared relayeket code defaultokkal. A kind `10063` editor load + reorder + review + külső sign + publish + read-back útvonalat ad anélkül, hogy az adott szerverekhez fordulna vagy undeclared defaultot szúrna be.
- **NIP-A3 payment targets** (sep 1–3) — Amethyst, Grimoire és Pollerama implementálta a kind `10133` payment targetet. Az Amethyst csak akkor nyújt opt-in handoffot, ha van kompatibilis target, és nem változtatja zappé. A Grimoire fix registry-t használ, mielőtt wallet URI-t épít. A Pollerama Monero cím-validációt végez, és lekéri a szerző relay listáját, mielőtt targeteket kérdez le. Mindhárom kliensnek kell: engedélyezett payment method, relay útvonal, pontos display.
- **Ditto** (sep 4 + sep 6) — broad Blossom fallback és mirroring: avatarok, badgek, bannerek, közösségi képek, custom emoji, app ikonok a deklarált szervereket próbálják ugyanazzal a blob hash-sel; a mirror upload standard BUD-11 authorization tokent használ. Szeptember 4-i change: kompakt `kind:30311` live-stream embed.

## Protokoll- és NIP-munka

- **NIP-01** (sep 4 merge) — a `limit: 0` filter tisztázva. A relay NEM tárolt eventet ad vissza, `EOSE`-t küld, ha a kezdeti query-k lefutottak, és a subscriptiont aktívan tartja új egyező eseményekre. Egyetlen filter mezővel live-only subscription nyitható, lokális history megtartásával. A klaretozás kompatibilis viselkedést rögzít több relay implementáció és publikus relay között.
- **NIP-78** (sep 3 merge) — authenticated app-data követelmény. A relayek NIP-42 authentikációt KELLENEK igényelniük a `78` és `30078` kindokra, és CSAK az authentikált event authornak KELLENEK szolgáltatniukuk. Ez SHOULD, nem confidentiality garancia: tetszőleges relay nem tekinthető privát storage-nak. A merge a custom app-data kindokat sem ajánlja generic public interchange-ként.
- **NIP-AC** (sep 4 nyitva) — explicit open WebRTC-signaling proposal. Provisional ephemeral kindokat használ ping, connect request, offer, answer és ICE candidate számára, `p`-vel addresselve és session `e` taggel csoportosítva; a `30600` kind a discovery-t támogatja. A relayek KELLENEK broadcastolniuk és NEM KELL tárolniuk ezeket a signaling eventeteket, amíg a peer-ek direktben csatlakoznak. A számok provisional-ok maradnak, a kliensek NIP-65 relay listát KELLENEK használniuk, és a confidentiality-t igénylő appok NIP-44-gyel KELLENEK titkosítaniuk az offer/answer/candidate tartalmat.

## NIP Deep Dive: URI linkek és referenciák event szövegben

Egy Nostr azonosítónak hordozható jelentéssel kell rendelkeznie, mielőtt egy másik app megnyithatná. A **NIP-21** a `nostr:` URI scheme után helyezi el a NIP-19 azonosítót, egységes dispatch-álható formát adva a böngészőknek, operációs rendszereknek és appoknak. A **NIP-27** ugyanazt az URI-t definiálja az olvasható event `content` belsejében. A NIP-21 alkalmazás-határt lép át; a NIP-27 profil- vagy event-referenciát tart szignált prózában. Egyik sem hoz létre új event kindet és nem változtatja a relay üzeneteket; a két specifikáció csak a linking és renderelési viselkedést írja le.

### URI dispatch és NIP-19 szemantika

A NIP-21 nyelvtana `nostr:` + egy NIP-19 bech32 entitás. Az `nsec` kimarad (privát kulcsot kódol). Nincs authority, path vagy query komponens, ezért egy konform link `nostr:npub1...`, nem `nostr://npub1...`. Egy platform vagy kliens regisztrálhat handlerként; a specifikáció nem választ telepített appot és nem definiál web fallback-et.

Az előtag megmondja a kliensnek, mit dekódoljon. Az `npub` publikus kulcsot hordoz, a `note` event id-t. Az `nprofile` opcionális relay hintet ad egy profilhoz; a `nevent` relayeket, author-t és kindet egy event id-hez; az `naddr` az author-t, kindet és `d` azonosítót hordozza addressable eventhez, opcionális relayekkel. Ezek NIP-19 TLV (type-length-value) mezőket használnak. A hint szűkíti a felfedezést, de nem bizonyít sem relay birtoklást, sem author kontrollt. Minden lekért eventhez kell id újraszámítás és signature check.

A NIP-21 specifikáció profile formája: `nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9`.

A NIP-21 HTML hidakat is definiál: egy Nostr eventet szolgáltató page az `naddr`-et a `<link rel="alternate">`-be, egy profil az `nprofile`-t a `<link rel="me">` vagy `<link rel="author">`-ba teheti.

### NIP-27 renderelés és opcionális tagek

A NIP-27 olvasható event contentre vonatkozik (kind `1` note, kind `30023` cikk). Egy composer megjelenítheti `@name`-ként, de a `nostr:nprofile1...`-t publisholja a signált stringben. Az olvasó scaneli az URI-t, dekódolja a NIP-19 entitást, lekéri a targetet, és renderelhet nevet, kártyát, preview-t vagy lokális linket. Ha a dekódolás sikertelen, az URI marad sima szöveg. A raw content NEM írható át: az átírás megváltoztatja a NIP-01 serialization-t, az id-t és a signature-t.

A content referenciáknak és a tageknek rokon, de különböző feladatuk van. A NIP-27 opcionális `p` és `e` tageket, valamint a NIP-18 `q` taget írja le. Egy kliens megjeleníthet referenciát anélkül, hogy notification vagy thread kapcsolatot hozna létre; quote discovery-hez az URI-t és egy `q` taget is ki kell írni. A Zap Cooking szeptember 4-i implementációja ezt a splitet követi: megtartja az URI-t, és relay hintet + egyező `p` taget ad hozzá. A `p` vagy `q` hozzáadása NEM teszi priváttá az URI-t, és a NIP-27-nek nincs rejtett mention módja.

A konkrét NIP-27 referenciaként bemutatott kind `1` event a `wss://nos.lol`-ról lett recovered és verifikálva a bevonás előtt. A `content` egy `naddr`-et tartalmaz version-independent addressable eventre. A dekódolás: kind `30402`, author `91036d...310a`, a workbook `d` azonosítója, és egy `wss://nos.lol/` hint. A `q`, `p`, `t`, `zap` és `client` tagek alkalmazás-választások, nem NIP-27 követelmények.

### Trust, failure behavior, kliens implementációk

Egy biztonságos reader megtalálja a teljes `nostr:` tokent, validálja a bech32-t, dekódolja a NIP-19-et, elutasítja az `nsec`-et, ignorálja az ismeretlen TLV típusokat, és a rosszul formázott / túlméretes szöveget békén hagyja. Az `npub` és `nprofile` profil-query-hez vezet; a `note` és `nevent` immutable eventet azonosít; az `naddr` a legutóbbi érvényes addressable eventet választja ki a saját kindjére, authorjára és `d` tagjére. A relay hint csökkenti a keresést, de nem terjeszti ki a bizalmat. A NIP-01 event szabályok szerint a kliens verifikálja a lekért `nevent` id-t, és minden `naddr` candidate signature-t ellenőriz, mielőtt az addressable-event csere szabályokat alkalmazná.

Az inline preview-k kliens-választás privacy és resource költségekkel. Minden referencia lekérése felfedi az olvasó érdeklődését és lookup storm-ot okozhat, ezért a kliensek használhatnak cache-t, deferelhetnek fetch-et a láthatóságig, korlátozhatják a konkurrenciát, és kérhetnek click-et ismeretlen médiához. A NIP-27 alatt a preview külön kell maradjon az aktuális author signált szövegétől. A hibának láthatónak kell lennie unresolved textként vagy nem elérhető kártyaként — nem silent verifikált tartalomként.

A bizalom identifier-típus szerint is változik. Egy `nevent` immutable byte-okat nevez meg, így a kliens elutasíthatja a lekért eventet, ha a serializált id nem egyezik a kért id-vel. Egy `naddr` replaceable koordinátát nevez meg, így a kliensnek minden candidate-et verifikálnia kell, és alkalmaznia az addressable-event szabályokat, mielőtt a megjelenítendő verziót kiválasztaná. A relay hint hasznos az első query-hez mindkét esetben, de nem endorsement sem a relayről, sem a visszaadott tartalomról. A NIP-19 TLV definíciója adja azt az adatot, ami ezeket a check-eket explicitte teszi.

A NIP-21 hordozható linket definiál, amely Nostron kívülről is megnyitható; a NIP-27 ugyanazt a linket tartósítja a signált szövegen belül. Egy csak NIP-21-et implementáló kliens megnyithat egy beillesztett URI-t, de nem renderelhet beágyazott referenciákat. A teljes NIP-27 támogatás hozzáadja a scanelést, a biztonságos dekódolást, a fetch policy-t, a lokális renderelést, és egy explicit döntést a notification és quote tagekről. A megosztott URI interoperábilisan tartja ezeket a rétegeket anélkül, hogy a klienseket azonos megjelenítésre kényszerítené.

A Damus az inline referenciákat típusos mention-ként modellezi. A mention code az `npub` és `nprofile`-t profil-referenciává, a `note` és `nevent`-et event-referenciává, az `naddr`-t address-referenciává mapolja; a NostrLink a megfelelő célhoz route-ol. A Primal Android parsolja a scheme-t és a beillesztett formákat, validálja a bech32-t és kinyeri a relay hintet, majd a referenciákat note-content modellekbe mapolja. A Zap Cooking ugyanazokat a referenciákat cikkekben, receptekben, editor preview-ban és nyomtatási nézetben rendereli.

A cikk/projekt hír megosztásához: küldj NIP-17 DM-et a Nostr Compass projektnek.

## Linkek / kulcs repo-k és projektek

- ngit v3 / GitWorkshop / ngit-grasp / ngit-ci — [NIP-34](https://github.com/nostr-protocol/nips/blob/master/34.md), aláírt git workflow
- nsite-clay — [nsite](https://github.com/hoytech/woodstock) stílusú NIP-5A böngészős publisher
- Wingman App — Flutter shell NIP-07-tel, Flight Deck + Tower Drive
- Shosho 1.1.0 + Livelier — Owncast → NIP-53 bridge
- Communitator — relay/Blossom/inbox sablonok signing előtt
- cal.emre.xyz — NIP-52 időpont-foglalás
- Plektos — Concord-alapú privát event csatorna
- Vector 0.4.4, Primal Android 3.5.27, GRAIN 0.8.0-rc2, LibreNostr 0.5.0–0.5.2, SkateSpots, Whistle 1.8.15, TWENTY ONE Companion 1.12.0, ZapStore 1.1.2, Amber 6.6.1
- Zap Cooking NIP-27, Conduit Blossom/reconciliation, NIP-A3 payment targetek, Ditto Blossom fallback
- NIP-01 (limit: 0), NIP-78 (auth app-data), NIP-AC (WebRTC signaling proposal)