Kihagyás

Nostr ökoszisztéma

Blossom — decentralizált fájltárolás Privacy tech — Nostr adatvédelmi funkciók OCE-32 — identitás és hatóság 32 byte-ba omlaszt (SHA-256 + secp256k1 szimmetria) Decentralizált moderáció — web-of-trust, user-driven reporting kontra centralizált cenzúra

Protokoll alapok

Core NIP-ek

  • NIP-01: alap protokoll (események, kind 0/1/2, relé kapcsolat)
  • NIP-05: DNS-alapú azonosítás (nostr-address)
  • NIP-19: bech32 kódolás (npub, nsec, note, nprofile)
  • NIP-44: titkosítás (közvetlen üzenetek)
  • NIP-96: HTTP fájlfeltöltés (elavult, Blossom váltja)

Azonosítás & hitelesítés

  • NIP-07: böngészőbővítmény (window.nostr)
  • NIP-46: NIP-05 → remote signer (bunker protokoll)
  • NIP-89: app handler (kind 31990 — "milyen app kezeli ezt?")

Fizetési rétegek

Lightning

  • ZAPPOOL: automatikus zap elosztás tartalomgyártóknak
  • NIP-57: zap protokoll (Lightning tippküldés)
  • Spark: azonnali Lightning fizetés (Cake Wallet integráció)
  • CLINK: Nostr-native Lightning interakciós protokoll — LNURL/Bolt12 utód

Cashu (Chaumian ecash)

  • NIP-60: Cashu pénztárca (kind 37375/37376)
  • NIP-61: Cashu nutz (bizonyíték kvórum)
  • Privacy: blind signature, nem traceable
  • Egy app: wallet + relay + blossom + signer

Common Lightning Interface for Nostr Keys — Shocknet specifikáció, ami Nostr-native szabványokat definiál Lightning interakciókhoz.

Három protokoll: - CLINK Offers (noffer1..., kind 21001): LNURL-Pay utódja — statikus fizetési kódok invoice generáláshoz. Bech32 kódolás TLV-kkel (pubkey, relay URL, offer ID, árazás típusa). NIP-57 Zap kompatibilitás. - CLINK Debits (ndebit1..., kind 21002): Statikus debit authorization — alkalmazások fizetést kérhetnek a felhasználó tárcájától. Direct payment, budget request (recurring), vagy unrestricted access. - CLINK Manage (nmanage1..., kind 21003): Delegált menedzsment külső alkalmazásoknak. Első resource: Offers CRUD (marketplace, SaaS use case).

CLINK vs NWC vs LNURL: - NWC: Wallet remote control RPC tunnel → komplementer, nem versenytárs - LNURL: HTTP endpoint függőség → CLINK ezt eliminálja - CLINK: Teljes interakciós protokoll, identitás-alapú (NIP-05), esemény-vezérelt

Integrációk: NIP-01 (clink_offer/clink_debit kind 0-ban), NIP-05 mapping, NIP-57 Zap flow.

Implementációk: Lightning.Pub (referencia szerver), ShockWallet (tárca), Bridgelet (NIP-05/LNURL bridge), CLINK SDK (JS/TS), clinkme.dev (web demo), bxrd.app (Nostr kliens).

Design elvek: Implementation first, backwards compatible, no redundancy, Nostr native, web-kompatibilis webhook-kal.

CLINK → teljes raw specifikáció

NIP-46 signer réteg — hol él az nsec

A NIP-46 (remote signer / „bunker”) az a pont, ahol a Nostr kulcskezelés eldől. A kulcs vagy egy kliensben él (böngésző-profil, telefonos app, szerver home könyvtára), vagy egy külön aláíró device-on. A Nostr kulcsnak nincs jelszó-resetje — ezért ez a döntés végleges: egy phishing oldal, egy rosszindulatú update vagy egy elrontott backup után az identitás örökre másé.

Heartwood — hardveres signer ESP32-n (2026-09-26)

Nyílt forrású (MIT), Rust firmware egy ESP32 dev boardon. A master seed a chip hardveres entrópiájából születik, egyszer megjelenik az OLED-en, és semmilyen kódúton nem hagyja el a device-ot: nem USB-n, nem relayen, nem backupban. A NIP-44 visszafejtés, a policy-kiértékelés és a BIP-340 aláírás is a chipen történik; a gép, amibe dugod, csak ciphertextet lát.

Kétfokozatú engedélyezés — ez a lényegi minta: - Policy (allowlist): pontos metódus- és event-kind plafon kliensenként. Amin belül van, az felügyelet nélkül aláírható (pl. egy bot automatikus posztja). - Fizikai gomb: minden más. A kijelző mutatja, melyik identitás, milyen event és a tartalom előnézete, visszaszámlálással. 2 s nyomva = approve, rövid nyomás = deny, a csend is deny (és a képernyő ki is mondja, nem hagy halott visszaszámlálót). - A policy fail-closed: amin kívül esik, azt elutasítja, és utólag semmilyen gomblenyomás nem eszkalálhatja.

Hardver: négy board (Heltec V3/V4, LilyGO T-Display két gombbal, Waveshare ESP32-C6), egy firmware, board a fordításkor választva. A szignált update board-id-hez kötött, így a device elutasítja a más boardra épített firmware-t. Akár 8 master identity device-onként.

Kulcshierarchia (nsec-tree): egy master secretből korlátlan al-identitás, és minden device saját ágat kap (persona/social, client/bray, device/mobile-0, …). Egy gyerek kompromittálódása sosem fenyegeti a rootot vagy a testvéreket — egy elveszett portable device-nál csak azt az ágat égeted el.

Üzemmódok: Raspberry Pi-re dugott HSM (minden rádió ki; a Pi intézi a hálózatot, az ESP32 a kriptográfiát — kompromittált Pi nem tud master kulcsot kinyerni), WiFi-standalone (a chip maga beszél a relay-ekkel, nagyobb támadási felület), és BLE portable (roadmap).

Az őszinteség a legjobb jel benne. A SECURITY-MODEL.md (58 KB) a saját korlátait ugyanolyan részletességgel mondja ki, mint az erősségeit — és van egy kritikus rész, amit tudni kell:

A default konfigurációban a seed NYUGALMI ÁLLAPOTBAN PLAINTEXT. Flash encryption, NVS encryption és secure boot mind kikapcsolva, ezért egy „unsealed” device és egy USB kábel elég: esptool.py read_flash kihozza a 32 bájtos seedet. A boot PIN csak az alkalmazás frame-loopját zárja, a ROM bootloadert nem. Secure boot nélkül tetszőleges firmware flashelhető a ROM bootloaderen, megkerülve a gombos OTA-jóváhagyást teljesen.

Amit ez jelent: a Heartwood a távoli és a szoftveres támadót zárja ki — vagyis pont azt, ami a valóságban elviszi az nseceket —, a fizikai támadót viszont csak akkor, ha bekapcsolod a PIN-ből derivált seed-titkosítást (PBKDF2 100k round, ChaCha20 + HMAC, beépítve, opt-in) vagy a host-oldali vault key-t. Az eFuse-alapú hardeninget (Secure Boot v2 + flash/NVS encryption) tudatosan elvetették: irreverzibilis, brick-kockázatos. Részletek: Hardver wallet biztonság.

Megoldatlan kriptográfiai rés — nonce-commitment. A projekt maga nyitotta meg: a BIP-340 enged 32 bájt aux_rand-ot a nonce-derivációhoz, és a protokoll nem korlátozza a választást. Rosszindulatú firmware az aux_rand-ot csiszolhatja, amíg az aláírás néhány választott bitet kódol, és néhány tucat érvényes aláíráson át egy teljes seed kiszivárog. A felhasználó normál eseményeket lát, normálisan aláírva — semmi nem jelzi. A Blockstream Jade Anti-Exfil protokollja ezért létezik Bitcoinon. A megoldás a sign-to-contract: a signer a nonce-pontjára előre commitál, mielőtt a kliens randomitását megtudná. A projekt publikált egy draft NIP-et (sign_event_commit + sign_event_reveal, kind 30817) — a firmware-implementáció még nincs meg.

Ökoszisztéma: Sapwood (TypeScript management console: USB bootstrap Web Serial API-val, távoli management Nostr relay-eken át; a device nem nyit bejövő portot, nincs cloud fiók — a frame protokoll a Rust frame.rs TS portja, 19 teszttel igazolva; saját státusza: „untested alpha”), heartwoodd (daemon), nsec-tree (sub-identity deriváció), bray (trust-aware Nostr MCP szerver).

Státusz: beta, v0.16.0 stabil / 0.18.0-beta.19 aktív, napi commitok 2026-04 óta, de gyakorlatilag egy szerző munkája (★1). Nem Trezor/Ledger-szintű védelem fizikai lefoglalás ellen — a Nostr kulcsot viszont kiveszi a böngésző-profilból, ami a valós támadási felület.

Teljes feldolgozás: Heartwood ESP32 — hardveres Nostr aláíró

Blossom fájl tárolás

  • NIP-B7: Blossom specifikáció (draft)
  • BUD-01/02/03: upload, HEAD check, server list
  • Hash-alapú címzés, HTTP szervereken tárolva
  • Blossom — részletes specifikáció

Nsite webhosting

  • Blossom-alapú weboldal hosting
  • https://[npub].nsite.lol formátum
  • Nsite manifest → Blossom storage → gateway szolgáltatás
  • Egykattintásos deploy: nsite CLI

Kliens & architektúra

Nostria

  • Custom listák: Kedvenc lista + akármennyi egyéni lista létrehozható
  • Feed szűrés: A listák szerint lehet szűrni a feedet
  • Link: https://www.nostria.app/
  • Forrás: Boka (@bokatummtukote) — felhasználói visszajelzés

PhoenixD Dashboard

  • Node monitoring és menedzsment
  • Freedom Tech Friday #31

Cake Wallet + Spark

  • Multi-coin wallet Lightning integrációval
  • Spark: azonnali Lightning, nem kell csatornát nyitni
  • Privacy fókusz: Tor, coin control

BIP-47 PayNyms & Auth47

  • Újrafelhasználható fizetési kódok (nem kell új cím minden tranzakcióhoz)
  • Auth47: Nostr-alapú hitelesítés PayNym-mel

Monetizáció modellek

Pablo: Nostr monetizáció platformok

  • Value4Value (V4V) mint alapmodell
  • Zap-pool automatikus elosztás
  • Substack-szerű fizetés Nostron
  • NIP-57 zapek + NIP-96/BB7 média

Sovereign Engineering

  • Cohort 5: builder közösség
  • Szerződés nélküli, V4V alapú működés
  • Cohort #7 (2026-04): 21 résztvevő, ~100 demo
  • Eredmények: Phips, Blossom, Zap Store, Tollgate

Shadow OS

Justin Moon projektje — permissionless Android OS Pixel 4a-ra - Rust + Nix + TypeScript/TSX appok (Deno runtime) - No JVM — PID1 custom Rust code - Appok: Cashu wallet, Noster client, photos, podcast player - "3D printed gun of phones" filozófia — full Yolo, hackability focus - Pre-alpha: GPU direct + instant touch működik - Hiányzik: WiFi, cellular, NFC, Bluetooth, volume buttons - Repo: justinmoon/shadow

Phips protokoll

DNS/IP nélküli hálózati réteg - Minden végpont npub — kriptográfiai identitás - Overlay DNS/IP felett, de nem tőle függ - Mesh-ready: Starlink + helyi hálózat → offline community - Jonathan (40 év networking) — protocol-first approach - Bitchat funkcionalitás OS szinten - "Fips brought Jonathan out of retirement"

Boris (Read with Boris)

dergigi — Nostr-alapú olvasó app - Flight mode: offline is működik (local relay), online sincs mindenki más - Vibe-coding: 21 nap, 0 sor kézzel írt kód (Claude/YOLO mód) - Fő funkciók: bookmarks, highlights, TTS, reading position, zap splits - NIP-85: új draft specifikáció highlights és bookmarks kezelésére - Integrációk: ants.sh kereső, value4value zaps - Tanulság: "midcurve models" — LLM mindig a középérték felé regresszál; dialogical development kell - Link: https://readwithboris.com/

Pocket Nostr — Cross-Client Saved-for-Later Aggregator (NIP-X draft, 2026-06-03)

Piaci rés: 774 projekt a Nostr Compass katalógusban, SENKI nem csinál cross-client 'Pocket/Readwise' aggregátort. Boris single-client kísérlet, NIP-85 draft instabil. Aki Primalt/Amethystet/Nostriát használ, elveszett a 'save for later' lista — minden kliensben külön.

Javasolt megoldás: NIP-X (NIP-85 kiterjesztés vagy új dedikált NIP) + referencia PWA, ami: - Cross-client sync: bármelyik kliensből 'save' gomb, bármelyikben 'read' (kind 30023 long-form + NIP-46 remote signer) - Reading queue: prioritásos lista (kind 30003, mint a follow/mute listák) - Highlights + notes: NIP-85 trusted assertion kompatibilis (kind 30382-30385) - Offline-first: Blossom + service worker (mint a Boris flight mode) - Subscription: CLINK debit recurring (fizetős tier $5-8/hó, mint a Readwise) - Zap-the-source: a save event tartalmazza a forrás npub-ját, és a CLINK debit a forrást támogatja

Tervezett event-típusok: - kind 30023 (long-form save) — L: nip-x.saved-for-later, l: unread|reading|read|archived, source: <npub> - kind 30023 (highlight) — NIP-85 trusted assertion kiterjesztés - kind 30003 (reading-queue lista) — mint a follow/mute listák - kind 30023 (subscription) — NIP-99 marketplace listing, CLINK debit ID

Technológiai stack: NDK + Applesauce (reactive), NIP-46 bunker, NIP-44 titkosítás privát olvasmányokhoz, Blossom offline cache.

Piaci validáció: 1.5M+ havi aktív Nostr user (becsült) × $5/hó × 1% conversion = $750 MRR realisztikus az MVP első évében. Readwise $8/hó, Pocket $5/hó — bizonyított willingness to pay.

Roadmap: 1 hét NIP draft + 4 hét MVP webapp + 2 hét CLINK integráció + 2 hét browser extension + 1 hét NIP finalizálás.

Specifikus előny Henky számára: first-mover advantage a Nostr 'Readwise' kategóriában, NIP szerzői státusz, passzív CLINK income, és a Serpent Academy anyagok discoverable/saveable/highlightable a NIP-X-szel.

Link: raw/projects/2026-06-03_nostr_saved_for_later_aggregator.md

Marmot problémák

  • MLS encrypted chat 15 embernél összeomlik
  • Spec server-side ordering service-t ír elő, client-side próbálják
  • Double ratchet talán jobban skáláz kis csoportokra
  • Metadata leak: relays lekérdezhetők

Amish filozófia

Nem tech-ellenes, hanem függőség-ellenes - Autó vs buggy: buggy-t meg tudod javítani, autót nem feltétlenül - Bitcoin = dependency-free money (cryptography + PoW) - Nostr = dependency-free protocol (saját magad futtathatod örökre) - Bitstein: "orange pull the Amish" - Justin Moon: "by the fruits you shall know them"

Nostr Compass — Projekt Katalógus

A Nostr Compass (nostrcompass.org) 752 projektet követ kurált katalógusban, folyamatosan frissítve.

Kategóriák

Kategória Darab Kiemeltek
Social kliensek 151 Damus, Amethyst, Iris, Coracle, Gossip, Snort, Nostur, Notedeck, Primal, Nostria (custom listák)
Long-form 27 Habla, notestack, YakiHonne, Highlighter, Samizdat
Üzenetküldés 38 Bitchat, Blowater, White Noise, Vector, Pika, 0xChat
Média 17 Wavlake, Fountain, Zap.stream, Olas, Stemstr
Piacok 16 Mostro, Plebeian Market, Shopstr, SatShoot
Tárcák 45 Alby Hub, Zeus, Cashu.me, NWC, eNuts, Mutiny, Blixt
Signerek 45 Amber, Alby Extension, Frostr, Aegis, Keystr
Relék 88 strfry, nostr-rs-relay, Khatru, nostream
Dev tools 153 NDK, nostr-tools, rust-nostr, Nostr Army Knife
Könyvtárak 88 go-nostr, nostr-sdk, rx-nostr, nostrdb
Protokollok 5 Blossom, NIPs, Marmot, HyperNote

AI & Agent Integráció

Projekt Leírás
Routstr Decentralizált AI marketplace Nostr discovery-vel
ContextVM SDK Nostr ↔ MCP bridge AI számára
Tollbooth L402 + MCP szolgáltatásfizetés
Elisym AI agentek, amik Nostr-on találnak egymásra és fizetnek
DVMCP MCP szerverek és Nostr DVM-ek közötti híd
Clawstr Reddit-szerű platform AI agent közösségekkel

Privacy

Seth-for-Privacy

  • "Save BTC, Spend XMR" filozófia
  • Monero költés, Bitcoin megtakarítás
  • CoinJoin vs Lightning adatvédelmi összehasonlítás

Kulcsbiztonság

  • NostrKeySecurity.md: nsec védelem, hardware signer
  • SafeBox: helyi kulcstároló, nem felhőalapú
  • Bunker protokoll (NIP-46): távoli aláírás-delegálás

Nostrbook — Dokumentációs Registry

URL: https://nostrbook.dev
Készítő: Soapbox Technology

AI-kompatibilis, rendszerezett Nostr dokumentáció: - 85+ kind részletes leírása (programmatikusan: /kinds/N.md) - 19 tag típus részletes leírása (/tags/T.md) - Protocol reference: Event, Filter, Client, Relay (/protocol/SECTION.md) - llms.txt specifikáció: AI eszközök számára optimalizált struktúra - MCP integráció: npx @nostrbook/mcp@latest — VSCode Copilot, Goose, más MCP kliensek

MCP Tools

Tool Leírás
read_nip(nip) NIP leolvasása
read_kind(kind) Kind dokumentáció
read_tag(tag) Tag dokumentáció
read_protocol(doc) Protocol szekció
read_nips_index() Teljes NIPs index

Újabb NIP-ek (Nostrbook szerint)

  • NIP-62 (Kind 62): Request to Vanish — right-to-be-forgotten
  • NIP-64 (Kind 64): Chess (PGN)
  • NIP-68 (Kind 20): Picture
  • NIP-71 (Kind 21/22): Video / Short-form Portrait Video
  • NIP-73 (Tag i): External identities
  • NIP-75 (Kind 9041): Zap Goal
  • NIP-84 (Kind 9802): Highlights
  • NIP-85 (Kind 10040): Trusted Service Providers; (Kind 30382-30385): Trusted Assertions
  • NIP-88 (Kind 1068/1018): Poll / Poll Response
  • NIP-89 (Tag client): Client identification
  • NIP-92 (Tag imeta): Media metadata
  • NIP-C0 (Kind 1337): Code Snippet
  • NIP-C7 (Kind 9): Chat Message
  • NIP-7D (Kind 11): Thread
  • NIP-EE: MLS-based E2EE groups (Ditto megközelítés)

Groups összehasonlítás (Nostrbook)

Feature NIP-28 NIP-72 NIP-29 NIP-EE Ditto NIP-87
Focus Public chat Reddit-style Closed groups E2EE (MLS) Domain-based Private encrypted
Group ID Event ID (k40) Replaceable (k34550) Random + relay host MLS Group ID NIP-05 domain Admin key
Access Client-side mod Mod approval Relay-enforced E2EE admin Admin relay Encryption
Privacy Public Public Configurable Strong E2EE Public default Strong
Tag "e" "a" "h" "h" + MLS Standard Encrypted
Complexity Low Medium High Very High Medium High
Clients Amethyst, Iris Amethyst, nostrudel 0xChat, chachi.chat whitenoise Ditto Coracle (dep.)

Lásd még

AI és automatizáció — Nostr mint AI ágens kommunikációs réteg Open Source Philosophy — Jack Dorsey & Lyn Alden

Források

  • Building Nostr (könyv)
  • NOSTR_CORE_PROTOCOL, NIPS_COMPLETE, CLIENT_ARCHITECTURE notes
  • NOSTR_CRYPTOGRAPHY, NOSTR_RELAYS notes
  • Cake Wallet Research, ZapPool, SafeBox notes
  • Gotta Map 'Em All (2026-03-27)
  • Pablo: Nostr Monetization (2026-04-01)
  • Sovereign Engineering Cohort 5 (2026-04-01)
  • Vic Sharma: Cake Wallet Privacy (2026-04-03)
  • No Solutions #23: Shipping Violently (2026-04-14)
  • Citadel Dispatch CD200: UTXO + Wisp (2026-04-21)
  • Huszonegy #104: Nostr mint szabadság — HenkyPenky (2026-04-30)
  • Huszonegy #108: Budabit — magyar Nostr-alternatíva GitHub helyett (2026-05-28)
  • No Solution #25: White Noise, MLS, Marmot (2026-05-30)
  • No Solution #28: Speak Human w/ MouxDesign — UX, community, mini-AGI, vibe-design (2026-06-03)
  • projects/2026-06-03_nostr_saved_for_later_aggregator.md — NIP-X draft, cross-client Pocket/Readwise, potenciális 774-projekt piaci rés (2026-06-03)

Huszonegy #104: Nostr mint szabadság (2026-04-30)

HenkyPenky a Huszonegy podcastban:

  • Algoritmusok börtöne: X/Facebook = echo chamber, manipuláció, vásárlási/szavazási profilozás
  • Nostr = protokoll, nem alkalmazás: nincs kozponti cég aki lekapcsolhatná
  • Nincs algoritmus: te választod mit látsz, nem egy cég
  • Henky tapasztalata: Facebookról leszokás = mentális egészségjavulás, "nem depressziós többé"
  • Helyi piactér: magyar termelők Bitcoinért Nostron, földrajzi szűrés
  • Szólásszabadság: bármiről beszélhetsz, a néző dönti el mit lát

Huszonegy #108: Budabit — magyar Nostr-alternatíva (2026-05-28)

Five (Árpi, Budabit fejlesztő) és a HUSZONEGY csapat:

  • Budabit: Nostr-alapú, Git-natív közösségi szoftver — Discord+GitHub alternatíva egy felületen
  • Mi a baj a GitHubbal? Platformfüggőség, aláíratlan adatok, Microsoft kontroll, cenzúra, személyre szabhatóság hiánya. "Úgy képzeljétek el, mint egy demokráciában létezést — addig működik, amíg elhisszük, hogy a kurátorok védik a közösséget."
  • Nostr-modell: Minden adat (poszt, like, zap, kód) digitálisan aláírva, több szerverre tükrözhető. A kliens csak egy "lencse" — bármilyen kliens ugyanazt az adatot máshogy jelenítheti meg.
  • Tartalomszintű engedélyek: nem mindenki posztolhat repókat — csak akinek van rá joga
  • Közösségi kurálás: a tagok kollekciókba gyűjthetnek kódbázisokat, cikkeket, widgeteket
  • SatShoot: Nostr szabadúszó-piactér — második hely Nostr versenyen. Cold start probléma: közösségi szerveződéssel áthidalható.
  • Open slop vs. open protocol: AI korában könnyű szoftvert gyártani, de a valódi érték a nyílt protokoll, ami nem zárja be a szociális koordinációt egy platformba.
  • Patkóelmélet: totál decentralizáció (káosz) és totál centralizáció (zsarnokság) közel van egymáshoz — a közösségek (Dunbar-szám ~150) a megoldás.
  • Nick Szabo: "Trusted third parties are security holes"

Nostr Compass #20 — GitWorkshop PR merge, Routstrd AI inference (2026-04-29)

GitWorkshop: git-over-Nostr evolúció

  • In-browser PR merge button GRASP relay-ekkel
  • Stars és repository following — NIP-51 listák + kind10617/30617
  • Bandwidth-efficient git explorer — git client/server protokoll, nem shallow clone
  • Inline code review (NIP-22, kind1111): file path, commit SHA, line range
  • Experimental primitives (NIP-32): rename, hashtag, CoverNote pin, resolve
  • Multi-device notification sync: encrypted nsec → kind30078, dedicated keypair

Routstrd: inference over Nostr

  • TypeScript daemon, OpenAI-compatible endpoint
  • Provider discovery: Nostr kind38421 (RIP-02)
  • Scoring: price, trust, performance (RIP-06)
  • Payment: local Cashu wallet (cocod) + Lightning
  • Fallback ha provider fail

Kulcs NIP-ek és releases

  • NIP-59: Dual-key gift wrap (Mostro Core v0.10.0) — identity + trade key szeparáció
  • NIP-65: Relay list metadata (nostream, Wisp v1.0.0)
  • NIP-OA: Owner Attestation (Sprout) — autonomous agent authorization
  • FIPS: Nostr-based udp:nat bootstrap — hole punching, STUN, encrypted signaling
  • applesauce 6.0.0: Legacy EventFactory removal, Blossom URI parsing, BUD-10
  • Six Nostr Aprils: Retrospective 2021–2026 — protokoll fejlődés

Nostr Compass #23 (2026-05-21) — Onchain Zaps, Marmot Multi-Device, Hostr

Amethyst v1.10.0: Onchain Bitcoin Zaps

  • NIP-BC onchain Bitcoin zaps: küldés, fogadás, megjelenítés közvetlenül onchain Bitcoin tranzakciókkal
  • Dedikált ₿ sor az expanded reactions galériában
  • On-chain tranzakciós előzmények oldal paginációval (PR #2974)

White Noise / Marmot

  • Markdown renderelés chat üzenetekben, deep link (whitenoise:// URI-k)
  • Key package rotation NIP-33 replaceable event szemantikával
  • Audio metadata: duration_ms és waveform mezők (MDK PR #300, whitenoise-rs PR #833)
  • Biztonsági fix: HKDF-SHA256 explicit MIP-01 image key derivation-höz

Scramble: Multi-Device Marmot Kliens

  • .NET/Avalonia desktop és Android, 13 release egy hét alatt
  • Minden eszköz egyedi KeyPackage slot (d-tag kind:30443-on)
  • Auto-add peer device-ek MLS csoportokhoz (admin-only), forward-secrecy banner

Hostr: P2P Szállásfoglalás

  • 4 draft NIP: accommodation listings, reservation lifecycle, EVM escrow (Rootstock), marketplace tags
  • Buyer privacy: tranzakciónkénti ideiglenes Nostr kulcsok encrypted participant_proof tag-ekkel

AgentNoise (nvk)

  • Rust desktop helper, telefonról Codex/Claude agent vezérlés White Noise-on
  • /claude → új munkamenet, streaming progress

Keycast Security Audit

  • NIP-98 HTTP auth szigorítás, ALLOWED_PUBKEYS szerver-oldali kikényszerítés
  • SQLite foreign-key enforcement, AUDIT.md publikálva

További Release-ek

  • Primal 3.5.9: új app shell, NIP-05 badge-ek, audio lejátszás
  • Wisp v1.1.0: NIP-17 privát reply-k, auto-translate, NIP-55 eltávolítva
  • Amber v6.1.0-pre3: PSBT aláírás
  • Sprout v0.0.16: Sprig bináris, huddle v2 (10 peer)
  • Angor v0.2.26: NIP-04→NIP-44, GrapheneOS
  • Alby js-sdk v8.0: NWC multi-relay reconnect
  • KeyChat v1.41.1: Signal prekey törlés fix (forward secrecy)
  • Mostro Phase 2: anti-abuse bond, admin dispute slash

Új NIP Draft-ok

  • Drafts: privát draft event-ek NIP-44 titkosítással
  • Snapshots: immutable snapshot-ok replaceable event-ek historikus verzióihoz
  • Namecoin-anchored identity: Aegis, nostter, dart-nostr PR-ok

Nostr Compass #24 (2026-05-28) — Calendars, Vector v0.4.0, Disappearing Messages, 6 Years of May

Amethyst v1.11.0: Naptár + Onchain Zap Splits

  • NIP-52 naptár implementáció dedikált UI-val és emlékeztető rendszerrel
  • On-chain Bitcoin zap split támogatás (több címzett egy tranzakcióban)
  • Marmot/MLS csoport reply támogatás
  • NIP-57 zap-receipt validáció LNURL provider ellenőrzéssel
  • Payment Targets (NIP-A3) integráció

White Noise v2026.5.22: iOS Push Értesítések

  • iOS Notification Service Extension: MLS üzenetek visszafejtése az extension process-ben
  • Block/unblock UX, "Add members" gomb
  • Share-via-long-press média és üzenetekhez

MDK: NIP-40 Eltűnő Üzenetek

  • UniFFI bridge-en keresztül iOS és Android közös Rust implementáció
  • Lejárati tag a titkosított üzenet borítékban → relay szintű lejárat
  • Konzisztens viselkedés minden Marmot kliensen

Vector v0.4.0: vector-core Rewrite, Tor, NIP-46, MCP Agent

  • Teljes engine újraírás: vector-core crate, 440+ teszt, platformok közt megosztva
  • One-click Tor bridge támogatással
  • NIP-46 remote signer (bunker QR vagy URI)
  • Delete-for-everyone NIP-17 DM-ekben és Marmot csoportokban
  • MLS group sync NIP-77 negentropy-val
  • vector-agent: 21 eszközes MCP server AI agent-eknek (DM, csoport kezelés, fájl feltöltés, profil)
  • SQLite memória: ~308MB → 5MB

Cordn: Koordinátor-alapú MLS Messenger

  • Per-group coordinator (ContextVM service) MLS commit rendezéshez
  • Résztvevők ephemeral kulcsokkal kapcsolódnak
  • Kontraszt Marmot-tal: single-point availability vs relay-agnostic deployment

Mostro v0.17.4: Anti-Abuse Bond Phase 3

  • Slashed-bond payout: vesztes zárolt fedezete → nyertes
  • Phase 3.5 payout-confirmation üzenet
  • Yadio null-rate tolerancia, multi-source price provider spec

Notedeck: NIP-77 Negentropy Giftwrap-ekhez

  • Teljes NIP-77 reconciliation a shared outbox path-ben
  • Giftwrap reconciliation privát üzenet borítékokhoz
  • Thread view-k már nincsenek live-subscription reply limithez kötve

Applesauce v6.1.0

  • Kind 10086 lookup relay listák (NIP-51)
  • NIP-34 git-cast factory (kind 30617, 1617, 1621)

deepmarks: NIP-B0 Reference Client

  • Kind 39701 bookmark-ok, curator-monetizált publikálás NIP-57 zap-ekkel
  • Három-box architektúra: curator, indexer, viewer

NIP Javaslatok

  • Naptár Stack (Formstr): 4 NIP PR — participant self-removal (kind 84), privát naptár események (NIP-52E), ismétlődés (NIP-52R), decentralizált időpontfoglalás
  • Payment Targets (NIP-A3): kind 10133, RFC 8905 payto: URI-k, multi-rail tip jar
  • Silent Payments: két konkurens javaslat — Variant 1 (nsec-ből származtatott BIP-352 kulcsok, biztonsági aggályok) / Variant 2 (független BIP-352 cím kind 0-ban)

Release-ek

  • Amber v6.1.0 GA: titkosított per-account backup
  • Citrine: per-relay subscription, onion URL szivárgás védelem
  • Angor v0.2.27-28: multi-relay fix, Boltz reconnect
  • Nostrord v1.1.0: NIP-57 zap-ek, NIP-29 role distinction
  • Nyálkás (nurunuru) v1.5.x: SQLCipher MLS keystore, epoch catch-up
  • Bitcredit Core v0.5.10: Nostr-node-id fix

Fejlesztés Alatt

  • Jumble: Google login Pomegranate threshold signer-rel
  • Shopstr: MCP server AI agent-eknek NIP-99 listing-ekhez
  • Keydex: kind migráció (1337-1345 → 713-721), AEAD Shamir shares felett
  • Mill: drop-in Nostr signer Web Component (összes signer metódus egy script tag-ben)
  • moStard v1.0.1: Monero-first Nostr kliens, NIP-A3 Payment Targets Monero/Lightning/Bitcoin gombokkal

Hat Év Májusai (2021-2026)

  • 2021: Egy commit — NIP-02 contact list (kind:3), arcbtc PR #16 alapján
  • 2022: NIPs repo közösségi projekt lett. Uncle Bob első 3 NIP-je. NIP-07 (window.nostr).
  • 2023: 64 NIP PR egy hónapban. Jack Dorsey $10M OpenSats grant. NIP-47 NWC, NIP-53 Live Activities. Forbes profil fiatjaf-ról.
  • 2024: Konszolidáció. NIP-54 wikik, NIP-71 videó, NIP-46 átáll NIP-44-re.
  • 2025: NIP-77 (negentropy) mergelve. Notedeck Beta. Flotilla 1.0.0. $2M Reynolds Foundation.
  • 2026: MLS-on-Nostr multi-client production. Vector v0.4.0, Cordn, White Noise push. Naptár stack, MCP agent integrációk.

No Solution #28 (2026-06-03) — Speak Human w/ MouxDesign

Gigi és Mo (MouxDesign, Bitcoin Design Community) egy folyóparti sétán beszélgetnek a Bitcoin és Nostr ökoszisztéma UX-dizájnjáról, az AI szerepéről, és a közösségépítés filozófiájáról.

Designer szerepe megváltozott

  • Dizájn nem UI-képernyő, hanem App Store-pillanat + ajánlás + baráti magyarázat
  • Alapkérdés: egy mondatban el tudod-e magyarázni egy 10 évesnek mit csinál a terméked
  • Jack Dorsey: egy szóval tudod-e mondani, mi a terméked (kommunikáció? adat? oktatás?)
  • A legtöbb Bitcoin- és Nostr-alkalmazás nem megy át ezen a teszten

Mini AGI + Skill fájlok (Bean Sprout)

  • Jack Dorsey víziója: minden cég egy mini AGI-vá válik — intelligenciaréteg egy adatbázis felett
  • Mo adaptálta Bitcoin/Nostr ökoszisztémára: központi adatréteg gyűjti a user feedbackeket
  • A fejlesztők nem 60 oldalas dizájnguide-ot olvasnak, hanem AI-olvasható skill-fájlt kapnak
  • Bean Sprout (hackathon projekt): top Bitcoin tárcák GitHub repóiból kinyeri a user-problémákat, kategorizálja, Nostr relékre írja NIP-címkékkel
  • Vízió: AI automatikusan rendszerezi a visszajelzéseket és priorizál

Vibe Design munkafolyamat

  • UX designer képernyőfotókat tölt fel AI workflow-ba (N8N + Cloud Code)
  • A skill-fájl Bitcoin-specifikus tudást tartalmaz
  • AI React Native kódban generál javaslatokat
  • Designer reggel átnézi, jóváhagyja/elutasítja, AI GitHub issue-ként beküldi a tárcák front-end repójába
  • Gigi megerősíti: ő már így dolgozik — cron job-ok éjjel GitHub issue-kat oldanak meg

AI slop + verifikáció

  • Minden modellnek van saját dizájnkönyve — azonnal felismerhető (pl. Claude Opus "pill" gombok)
  • Verifikáció:
  • Szövegnél: saját Substack-írásait adja referenciaként → AI megtanulja a hangvételét
  • Vizuális dizájnnál: Mobbin.com (a legjobb appok képernyőfotó-adatbázisa) referenciaként
  • "Good designers copy. Great designers steal."
  • UX-designert nem lehet teljesen kiváltani — kell emberi ellenőrzés
  • AI "drive-by" PR-ek a nyílt forráskódú karbantartókat összezúzzák (BTCPay Server is)

Privát kulcs UX problémái (Nostr + Bitcoin)

  • A Bitcoin-dizájn legnagyobb akadálya pszichológiai: "íme a varázslatos internetes pénz, nem tudod a kezedbe fogni, de rajta van a telefonodon"
  • Ha elveszted a telefont: mindened oda — 12 szó, megtakarítás
  • Nostr-onboarding hasonló: privát kulcs újra és újra elmagyarázva, ritkán eltéve
  • Publikus kulcs keresése + beillesztése "olvasó-only" hozzáférést ad — nem valódi visszaállítás
  • "Ha elvontod a privát kulcsot és jelszó-visszaállítós rendszert csinálsz, az már nem Bitcoin — az Coinbase."
  • Postahivatal vs email analógia: Bitcoin privát kulcs = postahivatal (becenév + kocsma = kézbesítés). Ha túlzottan leegyszerűsíted, megsemmisíted az alapvető tulajdonságot

Community = Common Unity

  • "Community" = common unity — közös egység
  • Bitcoin-közösséget a megosztott tapasztalat, világnézet, szókincs tartja össze
  • Nostr-közösséget a cenzúrarezisztencia és a privát kulcs felelőssége
  • Koherencia előfeltétele bármilyen komoly problémamegoldásnak

Szuverén mérnöki módszer (Sovereign Engineering)

  • Distributed cognition csak személyes jelenlétben tud kibontakozni
  • Sovereign Engineering: több hetes, személyes, elszigetelt formáció Madeirán
  • Áttörések a 2. hét környékén jönnek: lehullik a maszk, kialakul a csapatszellem
  • Inkluzivitás problémája: globális déli fejlesztők nem engedhetik meg az utazást
  • Megoldás: közösségépítés helyi szinten induljon
  • 21.world dokumentálja a német Bitcoin-only közösség építését — más országokban replikálva
  • Legfontosabb: ne egyedül kezdj, társalapító kell, maradj konzisztens

Nostr-alkalmazások és a "fun" faktor

  • Martti Mälyi (Iris, Nostr VPN, Nostr zenelejátszó, Google Drive klón): mindennapi mainstream appokat építi újra Nostr-on, saját magának
  • Sikeres appok két kategóriája:
  • Unikorni: valaki saját igényére épít, kiderül hogy másoknak is kell
  • Klón: létező szolgáltatás Nostr-verziója
  • Vine-példa (Ravel által újraépítve, archívummal): vírusos terjedéshez nem kell elmagyarázni a motorháztetőt
  • Bitcoin és Nostr: csak oldjon meg egy problémát, legyen szórakoztató
  • Linux évtizedekig "komolytalan" volt, mégis az internet gerincévé vált — Gigi nem hisz a minden áron való tömeges adoptációban
  • Nostr másik előnye: privát AI-hozzáférés — a közösség érti a megfigyelés kockázatát

Záró üzenet

  • Mo: "építsétek a szabadság-technológiát, szeretünk titeket"
  • Gigi: "csak építsetek dolgokat"
  • Mindkettő egyetért: koherencia, közös szóhasználat, személyes jelenlét, konzisztencia építi a közösséget és a terméket

RHR #412 Releases roundup (2026-06-04)

Core Lightning v26.06

  • A Core Lightning (CLN) új kiadása — az ElementsProject/lightning GitHub-ról
  • A Lightning Network egyik két fő implementációja (LND mellett)
  • Folyamatos fejlesztés, backwards compatibility fontos

Alby Hub v1.22.2

  • A getAlby/hub új kiadása
  • Alby Hub: önellátó Lightning wallet + NWC (Nostr Wallet Connect) szerver
  • Privát, saját infrastruktúrán futó alternatíva a felhő wallet-ekhez képest

Sparrow Wallet 2.5.2

  • A sparrowwallet/sparrow új kiadása
  • Desktop Bitcoin wallet — UTXO management, multisig, hardware wallet integráció
  • A privacy-conscious felhasználók egyik fő eszköze

nostr-vpn v4.0.48

  • A mmalmi/nostr-vpn új kiadása
  • Decentralizált VPN, Nostr-on keresztül peer-to-peer
  • Martti Mälyi projektje (aki az Iris-t és más mainstream Nostr appokat is építi)
  • A self-hosting + privacy stack fontos eleme

Tails 7.8.1

  • Tails (The Amnesic Incognito Live System) — Tor-alapú, amnéziás OS
  • Élő USB-ről fut, nem hagy nyomot a gazdagépen
  • Aktivista/újságíró alapműveltség

Releases roundup jelentősége

  • A Bitcoin/privacy ökoszisztémában folyamatos a release-ciklus — nincs megállás
  • A release-ek gyakorisága (5+ release egyetlen hét alatt) mutatja az ökoszisztéma érettségét és vitalitását
  • Minden release egy-egy trust-minimization lépés — a felhasználó egyre kevésbé bízik harmadik felekben
  • A lépésenkénti fejlesztés ellentétben áll a hype-ciklusokkal — itt építkezés, nem pump-and-dump

Nostr Compass Hírlevél #26 — 2026-06-10

Előző szám: #25 (2026-06-03). 7 nap alatt számos jelentős release és protokoll-változás.

Marmot v2 (Dark Matter) — protokoll-újradolgozás és natív kliensek

  • darkmatter (Rust, 2026-05-13. óta, 34 commit/7 nap): v2 protokoll-tervezet a spec/ mappában, OpenMLS-alapú CGKA engine a crates/cgka-engine-ben, konformancia-szimulátor property tesztekkel, Tamarin formális modell a konvergencia-bizonyításokhoz.
  • darkmatter-ios (Swift/SwiftUI): MarmotKit UniFFI xcframework, Notification Service Extension a MIP-05 push ébresztések on-device dekódolásához.
  • darkmatter-android (Kotlin/Jetpack Compose): Rust bindingok, just build, signed arm64-v8a APK.
  • A régi Whitenoise Flutter app whitenoise-archive jelölést kapott; az aktív Flutter vonal az új whitenoise Dart repóban fut.

v1→v2 átmenet főbb változásai: - MIP-01 monolitikus marmot_group_data MLS extension szétszedése 5 verzionált app komponensre: profile, admin-policy, transport.nostr.routing, blossom.image, message-retention - MIP-00 credentials új "account-identity-proof-v1" dokumentumot kap (címkézve: "new in v2 and breaking") - cgka-engine saját állapotgép: Stable, PendingPublish, Merging, Recovering epoch állapotok - A TransportPeeler trait elválasztja a Nostr transportot, a StorageProvider trait a SQLite/SQLCipher tárolót - Tamarin modell bizonyítja a konvergencia-tulajdonságokat (branch szelekció, policy-gated eligibility, anchor replay, stale-branch elutasítás)

Megjegyzés: A darkmatter README jelzi: "MDK remains the deployed Rust protocol implementation until this draft and engine are adopted." A cgka-engine crate 0.1.0-ás, "single internal consumer, not semver-stable". Pre-announce státusz, nem production ready. A natív kliensek a Marmot leggyakrabban emlegetett gyengeségét (mobil megbízhatóság) célozzák.

Chama v2.0.0 → v3.1.0 — standalone P2P escrow egy hét alatt

17 release 7 nap alatt, június 9-ére v3.1.0-ig trade-room UI újrarajzolással és per-seller storefronts-okkal.

Verzió-történet: - v2.0.0 (BREAKING): escrow LOCK formátum változás — Shamir share csak a tulajdonosához titkosítva (sharePolicy holder-only-v1); federation bearer ecash nem rekonstruálható egyetlen résztvevőből - v2.0.1–v2.0.3: Fedi WebView funding-rail gap-ek zárása - v2.1.0–v2.3.1: arbiter réteg keményítés (arbiter helyettesítés, ₿121 trade proof, listing-arbiter community membership ellenőrzés) - v2.4.0: BIP-39 recovery phrase (Fedimint ecash wallet, titkosítva Nostr-on) - v2.5.0: master nsec backup (Nostr identity + wallet seed) - v2.6.0: globális community picker (ország nélküli fallback a legközelebbi federation-höz) - v2.7.0: recovery-key screen plain English újrafogalmazás - v2.8.0: group applications, dark/light theming, új event kind-ok (38120 roster, 38121 application) - v2.9.0: dispute resolution deadline-nél arbiter ruling (korábbi auto-refund helyett) — COORDINATED release - v2.10.0: per-trade thumb-up/thumb-down rating, új event kind 38123 - v3.0.0: standalone app — nem kell koordináló community a működéshez; end-to-end trade notification-ök - v3.1.0 (június 9.): trade screen újrarajzolás Reserved → Locked → Settled progress spine-nel, role-colored action cardok, per-seller storefront listing class

Architektúrális pivot: A holder-only share encryption a v2.0.0-as BREAKING change. A federation bearer ecash nem rekonstruálható egyetlen résztvevőből — ezzel bezárul egy út, ahol egy rosszindulatú fél a saját share-jével és a federation által tartott share-jával tudta volna a trade-et consent nélkül lezárni.

Piaci pozíció: A Chama csatlakozik a Mostro-hoz és a Shopstr-hez mint Nostr-natív marketplace, megkülönböztető jellemzői: serverless architektúra, Fedimint-backed 2-of-3 Shamir escrow, holder-only share encryption, koordináló community nélküli self-contained desktop+mobile kliens.

Coracle Hosting — fizetős relay szolgáltatás Caravel+zooid stackkel

Június 3-án Hodlbod bejelentette a hosting.coracle.social címen — hosztolt community-relay szolgáltatás, ami recurring lightning payment-eket fogad el NWC-n vagy kártyán keresztül.

  • A szolgáltatás a Caravel (Coracle billing és provisioning frontend) és a zooid (egy relay runtime, ami sok virtuális relay-t hostol egy gépen) stackre épül
  • A Caravel opcionális livekit és Blossom integrációval shippel
  • Ingyenes tier member-count limitekkel, fizetési adatok megadása előtt
  • Üzleti modell: "monetize open source by selling a hosted version of a stack that anyone else can also run"
  • A Flotilla integráció (tervezett) — Flotilla birtokolja a user surface-t, a hosztolt opció a Flotilla-ból kiszolgálva lesz a default útvonal
  • Hodlbod felajánlotta, hogy más Caravel operátorokat hozzáad a Flotilla alternative-hosting picker-jéhez, ha jelentkeznek

Piaci pozíció: A Caravel a relay.tools-hoz csatlakozik mint nyilvános Nostr relay-provisioning platform paid member támogatással. A zooid many-relays-per-process sűrűsége az operátor hosting költségeit amortizálja sok kis community közt.

Release-ek

  • Angor v0.2.30 (június 8.): PR #893 — default network átváltás mainnetre. További: single-tap mobile create-project flow (PR #889), lightning invoice spinner race condition fix (PR #890), Boltz lightning invoice hálózati hiba runtime switch után fix (PR #885). Angor unstable alpha státuszban marad, de a default-mainnet jelzi a testnet-only fázis lezárultát.
  • Sprout v0.3.15 (június 10.): PR #902 TTL refresh ephemeral channels, PR #906 mobile custom emojis + settings redesign, PR #912 directory-backed team UI desktop-ra, PR #919 slash command-ok átengedése ACP connector-oknak.
  • Wisp v1.1.1 (június 5.): két-szintű wallet Connect screen Spark sub-screen-nel (PR #548), dashboard parity iOS wallet UI-val (PR #549), rendszer-szintű nsec paste guard (nsec1-prefixű paste-et bárhol detektálja és blokkolja), QR-scan login + watch-only mód npub/nprofile-hoz (PR #552), Zap message-ek mini-post-ként (PR #559), web-of-trust filter thread reply-kre (PR #583).
  • Nostria v3.1.46 (június 7.): notification counter rework — csak az utolsó megtekintés óta új notification-öket számolja.
  • nospeak 1.1.3: hang/videó hívás kliens.
  • Amethyst: 41 PR a NIP-32/NIP-F4/Tor vonalon, release tag nélkül.
  • Damus: PR #3786 OK message-ekből relay tracking.
  • Shopstr: NIP-34 dual-publishing.
  • Coracle: event build-time locality fix (PR #1490).
  • hermes-marmot: új repo, május 27-i utolsó frissítés, első AI agent ↔ MLS-Nostr híd.

NIP-ek státusza

  • NIP-67 (EOSE completeness hint) — merge-ölve június 6-án. Opcionális string üzenet subscription végén, jelzi hogy a relay minden elérhető event-et szolgáltatott-e. Konkrét failure mode (silent data loss) + minimális surface (egy string) gyors átmenetet hozott.
  • NIP-50 autocomplete extension — merge-ölve. Search filter extension autocomplete támogatással.
  • NIP-GART (emergency alerts) — PR #2374 early-draft státusz.
  • NIP-46 logout method — PR #2373 early-draft.
  • NIP-44 v3 — két független implementáció (Amber + Clave), a wire format consensus gyűlik.

Marketplace érettség — három Nostr-natív piac egymás mellett

  1. Mostro — eredeti NIP-driven marketplace, nostr-only event flow
  2. Shopstr — most NIP-34 dual-publishing-gel (git + nostr)
  3. Chama — standalone P2P escrow Fedimint-tel, holder-only share encryption

Mindhárom más-más escrow/coordination modellt képvisel, de a NIP-99 listing kompatibilitás közös nevező.

Nostr-git ökoszisztémák szaporodnak

  • NIP-34 tracker-ek
  • Hashtree transport
  • ngīt (Nostr-native Git, NIP-34)
  • joinmarket-ng
  • Mostro/Shopstr dual-publishing

Projektek snapshot (2026-06-04 óta nincs változás)

784 projekt, 12 kategória, top 3: Developer Tools 162, Social Clients 151, Relays/Libraries/Other 89-89-89.

Forrás: https://nostrcompass.org/en/newsletters/2026-06-10/

Cloud fodder cikk: Concord and NIP-29 — Two Designs for Group Chat on Nostr (2026-07-10)

Szerző: cloud fodder (Nostr: npub10n…ztl5h) Típus: Nostr protokoll-elemzés, csoportos chat design-ok összehasonlítása Forrás: njump.to link → nostr.ae Fókusz: Concord (CORD-01..07) vs. NIP-29 — két ellentétes csoportos chat design

Kulcspontok:

  • Concord (CORD-01..07) — "private stream" modell, mindent kulcs-birtoklásból vezet le. Trust anchor: a kulcs. NIP-59 minta invertálva (fix author, efemer p tag). Stream address group_key(label, secret, id, epoch)-ből deriválva. Csak kulcstartók tudják kiszámolni a címet és aláírni az event-eket
  • NIP-29 — relay a szerver. Plaintext, valódi kulccsal aláírt nostr event-ek, h tag-gel. Trust anchor: a relay aláírása. Nincs encryption sehol. A relay moderation event-ekből (kinds 9000–9020) építi a tagsági állapotot
  • A szerző mindkét designnak ugyanazt a 3 kérdést teszi fel: mit lát a relay/tagok, spam control, push notification feasibility
  • "Near-perfect dual" — minden válasz megfordul a két design között. Egyik sem jobb; mindegyik egy trade-off másik oldalát választja
  • Concord relay lát: anonim traffic graph (volumes, timing, groupings); soha tartalmat vagy identitást. Stable per-epoch address-ek + untweaked timestamps + subscription-filter grouping → gazdag activity graph, de anonim
  • Concord camouflage állítás cáfolata: "blend in with giftwrap traffic" strukturálisan törött — a fix author pubkey GROUP BY pubkey query-vel triválisan azonosítható. A védelem "unlinkable to a community", nem "indistinguishable from DMs"
  • Concord tagok látnak: mindent — authority recomputed from owner key. Non-repudiable seal-ek (szerzőség bizonyítható ha a kulcs kikerül)
  • Concord lurker-tulajdonság: tagság = kulcs-birtoklás, nincs enforced lista, observation csak a publikálókat kapja el. Bárki, aki valaha kapott invite-ot, csendben olvashat mindent egy rekey-ig, amiből kimarad — és a protokoll ezt nem tudja detektálni
  • NIP-29 relay lát: mindent. Plaintext, örökre, minden hosztolt csoportban (beleértve private-okat, ahol "private" csak annyit jelent, hogy a relay szűri a mások általi olvasást)
  • NIP-29 tagok látnak: "whatever the relay chooses to show them — and notably, possibly less than the truth." Malicious relay shadowbanolhat, fabricate-elhet moderation history-t, és a kliens nem tudja detektálni
  • "private is a promise, not a property" — a NIP-29 private group-okról. Subpoena vagy relay kompromisszum a teljes plaintext archívumot adja
  • Spam control trade-off: Concord-ban nehéz (relay nem tud per-member rate limit-et, mert minden event egy signing key-t használ); NIP-29-ben triviális (relay látja az author-t, write-time enforcement lehetséges)
  • Concord PoW trükk: NIP-13 normálisan nonce tag-et igényel, de a no-outer-tags szabály tiltja. A wrap p tag egy random efemer pubkey, amit addig lehet grindelni, amíg az event id vezető nullákat nem kap. PoW-gated writes nulla protokoll-változtatással
  • Concord push notifications: "wake and fetch" pattern (Signal/Matrix). Push gateway metadata-equivalent a relay-hez, nem ad új privacy osztályt. Rekey-k csendben törik a regisztrációkat
  • NIP-29 push notifications: solved. Server-side composition works, mint a Discord. Mention filtering, keyword alerts, per-channel mutes, digests — mind server-side, nulla battery cost
  • Bot-as-member ötlet (Concord): bot = npub, ami tartja a kulcsokat, mindent dekódol realtime, szelektíven push-ol (mentions, kulcsszavak). De full member trust-wise — a notification bot minden üzenetet olvas
  • Lurker három út, ami megkerüli az invite log-ot: public link (CORD-05 §1-2, nincs redemption event), Direct Invite (CORD-05 §6, "appears in no Registry by design"), whisper (out-of-band key átadás, "ungateable act")
  • Két gap a Concord moderation story-ban: (1) bannolt tag addig égeti a sávszélességet, amíg a Refounding landol (Ban = client-side display filter); (2) régi epoch address-ek forever floodable-ok
  • Concord spec erős pontok: self-certifying community_id (ownership = hash preimage), identity/access key split, plaintext-seal trükk (kind 20014), frozen byte-exact derivations label registry-vel, "three removals" decomposition
  • Concord spec trade-offok: nincs forward secrecy/post-compromise security egy epoch-on belül (szándékosan MLS ellen trade-elve); traffic analysis az elfogadott költség; nincs owner succession; NIP-44 64KB envelope limitációk (~500-npub banlist, 50-community list, 400-member snapshot chunks, 120-recipient rekey blobs)
  • NIP-29 spec erős pontok: radikálisan egyszerű (egy délután alatt implementálható), normál nostr kind-ok (threads, articles, calendars, livestreams), instant moderation, operacionális tapasztalat
  • NIP-29 spec költségei: group id self-certifies semmit, relay master key kompromisszum totális, undefined role semantics hurt interop, community portability aspirational, AV section az operátorra bízza a media-t
  • Minden design legnehezebb problémája a másik alapja: Concord-ban a server-side filtering visszahozásához trusted keyholding member kell (per-user, mert a kommunalis pont plaintext-holding middleman); NIP-29-ben ez a trusted member mindig is ott volt (az adatbázis)
  • NIP-29 specifikus event kind-ok: 39000 (metadata), 39001 (admin list), 39002 (member list), 39003 (role names), 39004 (currently-in-call), 9000-9020 (moderation: put-user, remove-user, delete-event, join request)
  • Concord specifikus event kind-ok: 1059 (giftwrap-szerű private stream), 21059 (efemer presence heartbeat, 30s), 20014 (plaintext-seal, control-plane compaction kulcsa), 13302/13303 (Community List/Invite List), 33301 (Public invite bundle)
  • Összehasonlítási alap: MLS (Messaging Layer Security), Signal, Matrix, Discord, LiveKit, APNs/FCM/UnifiedPush, NIP-42 (AUTH), NIP-44 (encryption), NIP-46 (Nostr Connect/bunker), NIP-59 (gift wrap)

Open Markets Podcast #12 — Max Proxy Hillebrand (2026-07-13)

A Max Proxy Hillebrand-del készült epizód négy, a Nostr ökoszisztémát közvetlenül érintő szálat tartalmaz:

  • NIP-99 marketplace ökoszisztéma projekt updates: Shopster × Cashu (P2PK@CashewXPro end-to-end lifecycle, scriptability: multi-sig, hash time-locked contracts — Lightningben nem lehetséges), Conduit guest checkout (ephemeral keys: app automatikusan generál privát kulcsot, email/phone out-of-band csatorna, onboarding flow a kulcs user-side megtartására), edenweeks.arc / robotechy NIP-99 spec demo, Nostr Compass integráció az Open Markets spec grouppal
  • NIP spec writing reform (NostrHub 2.0 / experts framing, Alex Gleason): a NIPs repo "sandwich" túl nagy — javasolt modularizáció feature compatibility / versioned docs mentén, Blossom / Marmot / Open Markets szétszabdalása külön spec-ekbe. BCH botnet spamelés problémája (a BCH chain-en olcsó spam-miatt elárasztott NIP-ek)
  • Marmot Protocol / White Noise privacy tech (chunk 4 fő tartalma): NIP-17 vs Marmot összehasonlítás — NIP-17: key leak = minden régi üzenet dekódolható (nincs forward secrecy), Marmot: kulcsrotáció, MLS-alapú csoportkulcs-kezelés, sokkal erősebb garancia. Marmot v2 "soon" — MDK (Marmot Development Kit) kész, TS WIP, C#/Kotlin még a régi spec-en, source-ból minden platformon elérhető. Marmot commerce-ready: bármilyen Nostr event becsomagolható encrypted groupba, capability negotiation app components-szel → agent marketplace / commerce use case-ek. Corden mint centralizált fallback: stabilabb, egyszerűbb, de Max szerint nem szabad feladni a decentralizációt
  • Privacy filozófia (Max „lopás” definíciója scarce property felett): lopás = erőszak, csalás, nem-teljesítés, kényszer — common decency kategória (Google/FedEx/Bitcoin OÜ tudja hol vagy, kivel beszélsz) — Google/closed source: "stealing your computer from you" (forced install closed source). Opt-out filozófia: "you can simply stop using a system that doesn't benefit you and use systems that do" — Bitcoin / Nostr / Marmot mint agency-restoration eszköz

Newlay — Kotlin Multiplatform Nostr Relay (NIP-29 implementáció, 2026-07-13)

A Newlay (opensauce/newlay, code.relay.tools) egy Kotlin Multiplatform Nostr relay (JVM Linux + Android telefon), M12 milestone = teljes NIP-29 (relay-based groups) implementáció. A Nostr Compass projektlistában jelenleg nem szerepel (808 projekt, Newlay 2026-07-11 óta létezik, várhatóan a következő heti frissítésben kerül be).

Tech stack

  • Kotlin Multiplatform (JVM + Android, single codebase), Gradle, LMDB single-writer (atomic commits: events + indexes + search + tombstones + metadata egyszerre)
  • NIP-ek: 1, 9, 11, 29, 40, 42, 43, 45, 50, 70, 77, 86, 65535 (LIMITS) + Blossom BUD-01/02/04/06/12
  • 14 modul: core, crypto, store, policy, server, client, spider, wot, apphost, app-jvm, app-android (+ ci, deploy, docs, gradle)
  • GrapeRank Web-of-Trust LMDB-n számolva, ACL tier-ekbe és spam filteringbe táplálva

NIP-29 implementáció (M12 milestone)

  • Kétféle event: user-signed (9000-9009 moderation, 9021 join, 9022 leave) + relay-authored (39000-39003 metadata addressable)
  • Flags bitmaszkként: PRIVATE (1), CLOSED (2), RESTRICTED (4), HIDDEN (8)
  • Nip29Settings config: enabled, allowUnmanaged (default true), requirePrevious (default off), minPreviousRefs (3), acceptForks, latePublicationWindowSecs (3600), inviteMaxUses (100), inviteExpiryHours (48)
  • LMDB layout: group_meta (groupId → packed record), group_member (u16‖groupId‖pubkey → roleBits‖since), group_invite (groupId‖0x00‖code → expiresAt‖usesRemaining)
  • Writer-batch atomicity: a moderation event + a group row-ok egy LMDB transaction-ben commitálódnak
  • Boot reconciliation: reconcile() scan-eli a group_meta-t és minden ismert group 39xxx-át újraszintetizálja
  • GroupRingListener (NotificationBus): minden committed #h-tagged event id-jét bejegyzi a GroupState.previous ringbe
  • Closed-group held-join minta: 9021 invite kód nélkül → tárolódik, admin 9000-zal approve-olja ({"kinds":[9021],"#h":["<group>"]} szűrővel listázza)
  • REQ gate (gateReq): filter-szintű CLOSED (auth-required/restricted) + per-event EventVisibility predicate (lock-free restrictedIndex)
  • 9009 invite system: writer-batch race-free redemption, absent/expired/exhausted = false (szándékosan összemosva, NIP-43 restricted: nem szivárogtat)
  • delete-group privacy: purgeGroupFootprint törli a 39000-39003-at + minden #h-tagged event-et (a private group content nem marad world-readable)

Kompatibilitás a Concord spec-emmel (cloud fodder, 2026-07-10)

Szempont Newlay (NIP-29 stock) Concord (terv)
Trust anchor Relay identity key (39xxx relay-signed) Key-holders (community secret → stream author pubkey)
Group identity group_id random, relay-scoped community_id = hash preimage, self-certifying, serverless
Encryption Plaintext event-ek, csak access control Minden üzenet layer-encrypted (kind 1059 private stream)
Forward secrecy Nincs Nincs epoch-on belül (szándékosan MLS ellen trade-elve)
Address rotáció Nincs (fix group id) Epoch bump rotálja a stream address-t
Membership group_member LMDB row + moderation log Nincs admission event; possession of keys = membership
Invite 9009 invite code, uses-limited, expiring 3 típus: public link / direct invite / whisper (nincs redemption event)
Relay szerepe Moderátor, jogalkalmazó, identity signer Postafiók (tárol + indexel), nem moderál
Tamper resistance Relay kitilthat (put-user/remove-user) Relay nem tud kitiltani (only client display filter)

Konklúzió: a Newlay NIP-29 implementáció NEM kompatibilis a Concord tervvel — más paradigmára épül (relay-kulcs vs. key-holders, plaintext vs. layer-encrypted, fix group id vs. epoch-rotáció). A híd gyakorlatilag lehetetlen a jelenlegi formában.

Döntési fa a NIP-29 / csoportos chat stratégiához

  • Standard NIP-29 csoportos chat (relay moderál, plaintext): Newlay használata ajánlott (NIP-29 teljes, M12 milestone kész)
  • Key-holder Concord-style csoportos chat: saját implementáció kell (Newlay-ből kiindulva, de Nip29Service → ConcordService csere)
  • Haven fork NIP-29 bővítésre: nem javasolt (Haven khatru-architektúrára épül, jobban illeszkedik a Newlay-be)
  • Multi-platform (Android + Linux) gyors deployment: Newlay (KMP natív támogatás)

Open Markets Podcast #13: The return of Gzuuus (2026-08-10)

A Nostr ökoszisztémát érintő főbb Ep 13 tanulságok: - ContextVM (volt DVMCP) és MCP integráció — Gzuuus projektje, ami az MCP (Model Context Protocol) JSON-RPC szemantikáját ülteti át Nostr relékre, egységesített kind használatával, kvázi AI-ügynökök felfedezési és hitelesítési rétegeként. A koncepció: "relays as discovery repository", "ContextVM-szerverként felfedve" = Nostr kulcs-alapú hitelesítés azonnal, ingyen. - CORDN privát üzenetküldés — Marmot/MLS protokoll kihívásaira (erős rendezés, több-relés fuzzy szállítási réteg) koordinátor-alapú megoldás. A koordinátorok ContextVM szerverként felfedve, relé "buta" efemer pipe, üzenetek a kliens helyben tárolja, multi-device Blossom szinkronizálással. - NIP-1 vs NIP-X vita — a "Nostr app" címke problematikája: a NIP-1 a legkisebb közös nevező, a többi NIP vektor, ami vagy új funkciót ad vagy csökkenti az interoperabilitást. A felhasználók gyakran "Nostr app"-nak neveznek tisztán identitásréteget használó alkalmazásokat is (kind 0, npub, pubkey). - Calvadev cikke: "Nostr is not for social media" — a protokoll-szintű szuverenitás alapja, hasonlóan a Bitcoin "BIP" rendszeréhez. A műsorvezetők a "Bitcoin app" vitával párhuzamba állítják. - A Nostr adat-tulajdon kulcsmondata: "a felhasználó ír alá minden payloadot, tehát az adat nem a tiéd, hanem a felhasználóé, és hordozható" — SOC Infinity státusz poén.

Intelligence Snacks #72 — Pete NIP javaslata a window.fips transportra és a "Nostr + FIPS elég" tézis (2026-09-17)

A YouTube-videó Pete és Andy beszélgetésének Nostr-specifikus része: a FIPS-t a Nostrral kombinálva "az internet, amit megérdemlünk" építhető újra. Pete a transcript második felében konkrét NIP-javaslatot vázol a window.fips transportra.

  • Pete draft NIP (window.fips transport): a window.fipsTransport API-t definiálja, amelyen keresztül egy Nostr web app user-approved HTTP vagy WebSocket hozzáférést kérhet FIPS-címzett relay-hez, Blossom szerverhez, Git service-hez vagy más privát endpoint-hoz. A host grantenként az origin-hez és célponthoz köti az engedélyt. Ez a NIP-F5 (Permissioned FIPS Transport for Web Apps) javaslat gyakorlati alkalmazása, amit a Nostr Compass #40-ben is dokumentáltak.
  • Device-key identity: a FIPS-címzés Nostr-style identity-t használ — a kliens publikus kulcsa a device-key, és a Nostr Connect-tel történő bejelentkezés során a Wingman app azonnal felismeri a felhasználót. Ez a Nostr NIP-46 (Remote Signing) és a NIP-07 (Browser Extension) koncepcióinak kiterjesztése lokális hálózati kontextusba.
  • "Apps that aren't apps" minta: familiaris UI-k alatt olyan alkalmazások, amelyek a saját gépünkön tárolják az adatot, és a FIPS-címen keresztül érhetők el. Ez a Nostr "adat-tulajdon" elvének alkalmazása alkalmazás-szinten: a felhasználó ír alá minden payloadot, az adat a saját gépén van, és a Nostr identity a hitelesítés.
  • Organizations as distributed computers: a FIPS-címzéssel egy szervezet a tagok lokális gépeiből áll össze "elosztott számítógéppé" — ez a Nostr relay-infrastruktúra általánosítása (ahol a Nostr relay is "elosztott" a publikus node-ok között). A saját gép + Nostr identity + FIPS címzés együttese a centralizált IT-infrastruktúra (Active Directory, Google Workspace) alternatívája.
  • "Nostr + FIPS elég" tézis: Pete szerint a kettő kombinációja elegendő "minden újraépítéséhez" — a Nostr az identity és a payload-hitelesítés, a FIPS a lokális hálózati címzés és a peer-to-peer connectivity. Ez a Nostr protokoll-filozófiájának ("a felhasználóé az adat") és a FIPS gyakorlati megvalósításának konvergenciája.

A teljes 9829 szavas magyar summary a nostr/2026-09-17_intelligence_snacks_72_fips_nostr_ai.md fájlban, ASR transcript a YouTube-transcript-api-ból (nostr/transcripts/2026-09-17_intelligence_snacks_72_fips_nostr_ai.txt, 17306 szó). Vendégek: Pete + Andy. Podcast: Intelligence Snacks #72 (2026-09-17, 75 perc).

E116 Húszonegy: BitChat, NymChat, Armada — Nostr-identitású decentralizált chat appok (2026-09-17)

A Húszonegy 116. epizódjában Henky három chat-app kategóriát mutat be: (1) BitChat (Jack Dorsey kezdeményezése) — Bluetooth + wifi mesh, Noise Protocol titkosítás (Cure53 audit), Nostr-identitással belépés, Cashu fizetési integráció. (2) NymChat — MLS-titkosítás (Messaging Layer Security): forward secrecy + post-compromise security. (3) Armada (Derek Ross, Soapbox csapat) — Concord protokoll, interoperabilizált csoportos kommunikáció, Git-szerű repo-megosztás, mesh-hálózat, Discord-szerű UI, fehérlistás belépés. Használati esetek: afrikai diktatúrákban demonstráció-szervezés BitChat-tel; céges fiókok Nostr-on (kulcs-átadás/visszavétel több kolléga között); Nostr monetizáció — szatosi tipping közvetlenül az alkotónak, platform-közbeiktatás nélkül. A "Kiürült a Nostr, jöttek a Monerósok" téma: a COLDCARD-hack után sokan visszatértek X-re, de a Monerós közösség (fiatjaf Monero-relay kliense) friss vért hozott. Episode: https://huszonegy.world/podcast/megepult-egy-uj-internet-amihez-nem-kell-engedely/

Soapbox Ditto 2.12: Onchain Zaps — Nostr publikus kulcs = Bitcoin cím (2026-09-19)

A Soapbox blog cikke a Ditto 2.12 release-t mutatja be, amelyben a Nostr publikus kulcs közvetlenül Bitcoin címként funkcionál — nincs Lightning channel, LNURL szerver, invite code, vagy bármilyen előzetes beállítás.

  • "Are you a pirate or an accountant?" — a szerző (a Ditto / Soapbox mögötti fejlesztő) a Lightning UX-ét könyvelői munkaként írja le, míg az onchain Bitcoin a "kalóz" élményt adja. A 2017-es bull run okozta magas díjak miatti védekezés mára dogma lett, és elszakadt a Bitcoin eredeti ígéretétől.
  • $2000 szétosztva egy hétvégén: a release első napján a szerző $100-t küldött prominens Nostr fejlesztőknek (köztük Vitor Pamplona, az Amethyst alkotója). Vitor 24 órán belül beépítette az Amethystbe, és a funkció ezer felhasználóhoz jutott el. A személyes tapasztalat: "It feels good to give to people. There were no barriers stopping me from giving."
  • NIP-SP (hzrd) és Tim Bouma Silent Payments áttörés: a privacy-ellenérvekre válaszul hzrd forkolta a Ditto-t, és silent payment implementációt épített. Az ő javaslata interaktív volt (a fogadónak előre kellett publisholnia). Tim Bouma fedezte fel, hogy silent payment address közvetlenül származtatható egy Nostr publikus kulcsból — ez drop-in kompatibilis az onchain zaps-okkal, és nem igényel előzetes beállítást.
  • "Unstoppable money is the plot": a cikk végső üzenete Bitcoin-maximalista kiáltvány. A Bitcoin mindig is "unstoppable money" volt, de a saját rajongói (akik a "helyes használat" vallásos szabályait erőltetik) akadályozzák, hogy visszatérjen az eredeti formájához. A Bitcoin legfőbb akadálya nem a díjak, nem a lánc, nem a világ — a Bitcoin saját népe.

A teljes 2002 szavas magyar summary a nostr/2026-09-19_soapbox_onchain_zaps_in_ditto.md fájlban. Vendég: a Soapbox / Ditto mögötti fejlesztő. Forrás: soapbox.pub/blog/onchain-zaps-in-ditto.

E117 Huszonegy: Cashu a Nostr-on — publikus kulcshoz kötött ecash és zapek (2026-09-25)

A HUSZONEGY 117. epizódjában Five bemutatja, hogyan kapcsolódik a Cashu a Nostrhoz: a Cashu programozható digitális pénz, ezért bármilyen publikus kulcshoz hozzá lehet kötni. A gyakorlatban ez azt jelenti, hogy a kibocsátótól olyan token kérhető, amit csak a másik fél tud elkölteni, és onnantól a tranzakció már csak átadás kérdése. A Nostr-on nyilvánosan hozzá lehet kötni ecasht valakinek a kulcsához, sőt ezt publikussá is lehet tenni, mert a kibocsátónál csak az adott személy tudja beváltani. A token megkapásakor érdemes beváltani, mert adatvédelmi szempontból jobb saját tokent tartani. Five egy konkrét fejlesztésről is beszámol: Cashu-integráció a CI-szolgáltatásba, ahol a fejlesztői continuous integration számítási kapacitását Nostr-on hirdetve, szabadpiaci jelleggel, másodpercre vagy percre lehet Cashuval megvásárolni (BudaBit kiadás előtt). Az epizód a Nostr-ökoszisztéma és az ecash-fizetési réteg összekapcsolódásának egyik legkonkrétabb magyar nyelvű leírása. Episode: https://huszonegy.world/podcast/lehet-a-bitcoin-olyan-privat-mint-a-keszpenz/

Forrás: raw/podcasts/2026-09-25_e117_lehet_a_bitcoin_olyan_privat_mint_a_keszpenz.md

Vissza a tetejére