# No Solutions #30 — Napplets w/ Sandwich > **Epizód:** [Episode 30: Napplets](https://sovereignengineering.io/podcast/30-napplets-w-sandwich) • **Dátum:** 2026-07-22 • **Házigazda:** Gigi (dergigi) • **Vendég:** Sandwich (napplet.run) > **Forrás:** [sovereignengineering.io](https://sovereignengineering.io/podcast/30-napplets-w-sandwich) • [Blossom M4A (52 MB, 1:37:45)](https://haven.dergigi.com/e2261870d0eb338d6c4907b82d3cf7a51cb420a3907198124cbb368015de0b19.m4a) > **Transcript:** OpenAI Whisper `ggml-medium.en.bin` (whisper.cpp, Metal GPU), saját futtatás 2026-07-23 (97:45 → 16 259 szó, 0 hallucináció, 3 részre bontva) --- ## Összegzés --- Az epizód középpontjában a **Napplets** projekt áll: sandboxed, composable Nostr appletek, amelyek a böngészősandbox- és az alkalmazás-szerver kontinuum közötti hézagot töltik be. A beszélgetés az architektúra (Nostr események, mint app-tároló), a biztonsági modell (iframe sandbox, postMessage kommunikáció), és a gyakorlati iteráció (1 éves fejlesztés, több mint 50 sandboxolt mini-app) mentén halad, miközben a Bitcoin Lightning micropayment-ek és a Nostr identity integrációját is érinti. A vendég **Sandwich** (korábban *hzrd*, illetve *gzuuus*) a Sovereign Engineering cohort tagja, és a Napplets a cohort egyik legnagyobb, legkomplexebb nyílt forrású projektje. ## 1. rész: A napplet architektúrája — composable, sandboxed Nostr appok A házigazda **Gigi** (dergigi), a *No Solutions* podcast műsorvezetője, a sovereignengineering.io oldaláról. A vendég **Sandwich**, a **napplet.run** készítője, aki mintegy egy éve fejleszti a sandboxed, composable Nostr appletek rendszerét. A beszélgetés a nappletek architektúráját, biztonsági modelljét, iterációs történetét és a böngésző-sandbox kontinuumot járja körül. ## Bevezető: a live stream applet és a workshop A beszélgetés a live stream applet demójával indul, amely a SAP Stream megfelelője, de immár egy nappletként, azaz egy host shellbe ágyazva működik — csupán a stream-eseményeket húzza be a Nostr relay-kből. Gigi a demó apropóján jelenti be, hogy a nap aznap *a világ eddigi legsikeresebb workshopját* tartotta: **több mint egy tucat (12+) résztvevő készített nappletet**. Sandwich ehhez egy külön tutorial-oldalt is összerakott, amelyre rámutatva egy AI agent öt-hat perc alatt képes volt megépíteni és telepíteni egy működő nappletet — feltéve, hogy a felhasználónak van NIP-46-os távoli signer profilja (pl. Amber a telefonon) és a fejlesztőgépen is be van állítva a Nostr signing flow. ## Mi a napplet: composable, sandboxed Nostr app A napplet definíciója: **composable, sandboxed Nostr app, amely egy host shellben fut**. Sandwich kiindulópontja az volt, hogy a Nostr protokoll — „vagy annak hiánya” — *maximum flexibility*-t igényel, mert a relay-k, a kind-ok és a kliensek tetszőlegesen kombinálhatók. Ezzel szemben egy hagyományos Nostr kliens (Damus, Amethyst, Coracle stb.) túlzottan restriktív: egyetlen csapat egyetlen víziót valósít meg, és a felhasználó nem tudja kicserélni a komponenseket. Sandwich erre reagál: *„every functionality should be atomic… you should be able to compose your clients.”* Gigi ezt egészíti ki azzal, hogy a komplexitás egy része a kulcskezelés, az aláírás, a relay-kapcsolatok, a cache és az Outbox modell — ezek azonosak minden kliensben, tehát értelmetlen, hogy minden applet újraimplementálja őket. A nappletek emiatt egy másik absztrakciós rétegen dolgoznak, mint a meglévő klienskönyvtárak (NDK, applesauce): a host shell mediálja a signing/storage/relay/upload/permission/user trust funkciókat, és az applet fejlesztőjének nem kell ismernie a Nostr teljes protokollját. ## Iterációs történet: Naps, Nap.run, Tauri, Thorium, iframe hardening Sandwich az eredeti ötletét visszavezeti a 2024. júliusi sacramentoi estéhez, amikor barátja ajánlására elkezdett Claude-dal „vibe codeolni”, és ugyanakkor megismerkedett a **Hyprland** Wayland kompozitorral. A Hyprland élménye — „sick of the bloat, sick of the opinionation” — ihlette azt a gondolatot, hogy egy saját, minimalista desktopot érdemes építeni, és ezen a lendületen született az első prototípus, amelyet ma már Atlas néven ismerünk. A korai változat neve **Naps** volt, és a teljesítményproblémák miatt az appleteket iframe-ekre bontotta — ekkor jöttek elő a komoly biztonsági problémák: az applet bármit megtehetett, amit a runtime, a sorok elmosódtak a konténer és az applet között. A tanulság: vissza kellett lépni a prototípustól, és „valóban jól” kellett megcsinálni. A következő iteráció a **Tauri**-alapú **nap.run** volt, de ez hamar elérte a plafont, mert nem lehetett mindent megvalósítani. Ezután a **Thorium** (egy slimmed-down Chromium-fork) felé fordult, de a build-chain és a CI erőforrásigénye kezelhetetlennek bizonyult. Végül a letisztult megoldás: egy **single-frame** architektúra, ahol az iframe-ből indítva *progresszíven eltávolította* az összes feature-t, amit az iframe használhatott, amíg az már csak **postMessage-en** keresztül tudott kommunikálni a hosttal. A biztonsági modell ekkor állt össze: 4-6 hónapnyi újrafogalmazás után jött rá, hogy „a person making the application doesn't need to know as much as I originally thought” — az applet fejlesztőjének nem kell tudnia, hogy Blossom-ot használ, hová tölti fel, milyen relay-t használ. ## A host runtime konkrét felelősségei A host runtime hét konkrét feladatot lát el: 1. **Keys** — a privát kulcs soha nem hagyja el a hostot. 2. **Signing** — minden aláírás a shellben történik. 3. **Encryption / decryption** — a titkosítás és visszafejtés is shell-oldali, és a host köteles elutasítani a bejövő üzenetet, ha az felette titkosítva érkezik (lásd lentebb). 4. **Relays** — a relay-pool és a kapcsolatkezelés a host dolga, beleértve az Outbox modellt is. 5. **Resource loading** — a bináris tartalmak betöltése és a blob-hash validáció a hoston fut. 6. **Storage** — az appletek sandboxolt storage-scopesokat kapnak. 7. **Uploads és user prompts** — a feltöltés a felhasználó által konfigurált Blossom-szerverlistán át történik, és ha a felhasználónak nincs konfigurálva szervere, a host promptol. Sandwich egy konkrét példán demonstrálja: egy drag-and-drop upload appletben az applet csak annyit tud, hogy „upload”; a host dönti el, hogy ez Blossom, Hashtree, IPFS vagy akár Google Drive-ot jelent-e. Ha a felhasználónak nincs szervere, a host promptolja a konfigurációra; ha több van, megkérdezi, melyikre vagy melyekre töltse. Olvasásnál az applet átad egy Blossom-hash-t, és a host tudja, hol keresse. ## Helper API-k vs. escape hatches, a plaintext-only busz A runtime két szintű API-t biztosít az appleteknek. A **magas-szintű helper API** elrejti a protokoll részleteit (Outbox, upload, publish stb.), míg az **escape hatches** — alacsony szintű relay interfész — közvetlen hozzáférést ad a protokollhoz, ha a helper nem elég rugalmas. Sandwich indoklása: ha mindent helperen keresztül kényszerítenénk ki, az korlátozná a lehetséges felhasználói élményeket, viszont az escape hatches garantálja, hogy a „maximum flexibility” megmaradjon. A biztonsági modell sarokköve: **a message bus fölött mindig plain text megy**. A host azonnal elutasítja a titkosított bejövő üzeneteket. Ennek oka a side-channel támadások kivédése: ha az applet dekódolhatna titkosított tartalmat, a támadó applet kihasználhatná a tárolási scopot és a heurisztikákat, hogy az applet szerzőjének visszaküldött titkosított üzenetekben exfiltrálja az adatokat. A plain-text szabály biztosítja, hogy a runtime naplózni tudja, az applet mit küld, és a felhasználó „reasonable assurance”-t kap, hogy „no funny business is going on”. ## Applet-to-applet kommunikáció és a „rebuild an operating system” felismerés Az appletek közötti kommunikáció megoldása a legnehezebb kérdés, és „csak tegnap este” (a felvétel előtti napon) dőlt el — Hazard bevonásával, aki közel egy évig tartó meggyőzés után 10 perc alatt „hookolt be”. A megoldás lényegében az, hogy az appletek ugyanúgy viselkednek, mint egy operációs rendszer folyamatai: Android intents, MIME-typok, archetype-ok és OS resource API-k mentén kommunikálnak. Az „aha moment” a resource loading kapcsán jött: a bináris tartalmakat az applet nem éri el hálózaton át, ezért a bájtokat a buszon kell streamelni — ugyanaz a probléma, mint amit az OS-ek médialejátszáskor megoldanak (Linux media API). Sandwich szó szerint kimondja: *„you just have to rebuild an operating system in a browser window.”* A gyakorlatban a YouTube-videók és a stream-ek ezen a médialejátszó API-n keresztül működnek. A fő szál ugyanakkor (FiatJaf projektjéhez hasonlóan) kezdetben a shell mint relay, és a NIP-1 üzenetek küldözgetése volt, de ez „huge convoluted mess”-t okozott, mert minden appletnek külön kulcspárt kellett volna rendelni — feleslegesen, hiszen a host amúgy is teljes kontrollal bír az applet fölött. A jelenlegi modellben az appletek nem kulcsolnak eseményeket, hanem a host mindent aláír a felhasználó kulcsával. ## Fejlesztői ökoszisztéma: Kehto, Paja, no-dependencies A teljes fejlesztői stack **no-dependencies** elvet követ: vanilla JavaScript (a bundlerek és a skill-ek kivételével). Ennek oka biztonsági és karbantarthatósági: a csomagok függetlenek más Nostr-könyvtáraktól, így a támadási felület minimális. A protokollt enélkül is meg lehet valósítani, de a csomagok nélkül „really hard to sell anyone on it in 2026”. A két fő komponens: - **Kehto** (finnül „bölcső”) — a runtime csomag: shell, ACL, firewall (egyelőre rate limiterként viselkedik, hogy tehermentesítse a runtime-ot), service-ek stubjai (notifications, relay pools, storage, KB storage, media handler). A shim is ide kerülhet át. - **Paja** (finnül „munkapad”) — a fejlesztői runtime, amivel runtimékat lehet építeni. A nappletek további formai megkötése: **minden napplet egyetlen fájl** — ez implicit módon kényszeríti ki az „egy dolgot csinál, de jól” filozófiát, és méretben tartja a komponenseket. A workshop után a felhasználók több mint egy tucat nappletet publikáltak. ## A böngésző-sandbox kontinuum és a natív app határ Sandwich tudatos döntése, hogy a nappleteket **böngészőben** valósítja meg, nem natív asztali appként. Ennek okai: (1) a felhasználónak nem kell telepítenie semmit — egy link azonnal működik, akár anonymous Jack-ként; (2) a rendszer permissionless, mert a runtime maga old fel mindent (nsites, blob-hash validáció, IPFS, torrent), és az egész telepíthető nsite-ként, így nincs szükség „initial delivery” gateway-re; (3) a legszélső eszközöktől (mikrokontroller kijelzővel) a natív appokig terjedő kontinuumon a böngésző a középső lépés, és ha működik a böngészőben — ami elvileg „lehetetlen” —, akkor elméletileg a kontinuum minden pontján működnie kell. A demó egyébként egy távoli, gyenge hardveren futott hibátlanul, a host-szerű UI fullscreenben „úgy néz ki, mintha natív app lenne”. A teljesítmény és biztonság kulcsa: a **main thread kizárólag a DOM renderelésére és az üzenetirányításra** szolgál a parent frame-ben, minden más **web workerekben** fut. CSP-vel és sandboxolt iframe-ekkel kombinálva egy applet nem tudja kimeríteni a relay-ket és összeomlasztani a parent frame-et. Ez a fő különbség a jelenlegi alternatívákkal szemben. ## Kapcsolódó projektek és a párhuzamos evolúció Sandwich a többi hasonló próbálkozást is ismerteti kronológiai sorrendben. FiatJaf (FiatJaf) 2022 végén, a JaxWave előtt indította a *Naps*-ot — „ancient idea, too early”. A Yakihonne-nek volt egy egyszerűbb view-jellegű megoldása. A **Soapbox Tiles** Lua-alapú, natív környezetre készült, és Sandwich aktívan beszél a készítőjével. FiatJaf most **Balazs**-szal dolgozik a *Nostr Apps / Naps* projekten, amely a commit history alapján „kb. egy évvel ezelőtti gondolkodásomra hasonlít” — hasonló problémákat oldanak meg, hasonló sorrendben, de más-más konklúziók felé haladhatnak. Gigi philosophikus párhuzama: Paul **Hypernote**-ja, amely „spiritedly hasonló”, bár a végrehajtás nagyon más. A fő eltérés a többi projekttel szemben a fenti biztonsági és teljesítmény-modell: CSP + sandboxolt iframe + web workerek + main thread korlát — enélkül egyetlen applet leterhelhetné az összes relay-t. --- ## 2. rész: A workshop, az inter-applet kommunikáció és a Nostr-út (2022-2025) A második rész a „workshop tapasztalatokkal” indul (RISC-V microkernel kitérő, 80%-os sikerességi arány), azután az inter-applet kommunikáció kísérleti tervezését tárgyalja (Android intents, MIME types, under-specification), végül Sandwich teljes Nostr-útját meséli el 2022-től 2025-ig: a NIP-46-os key management problémától a Nostr Watch-on át a Nsites v2-ig és a NIP-66 relay state machine-ig. ## A workshop és a microkernel-tanulság Sandwich az első workshopot a **RISC-V microkernel**-implementációval alapozta meg — ez egy „teljesen más projektnek” indult, de a tapasztalatok közvetlenül átvihetők voltak a nappletekre: - A microkernel a **TUI**-val (terminal user interface) működött „moderately sandbox environment”-ben - Implementálta a nehezebb NIP-eket: resource, outbox, KV storage (+ egy harmadik, amelyik nem jut eszébe) - A cél: látni, hogy a sandbox-architektúra **elvileg működik** — amint ez megvolt, „full force on the website, just to get it to the public” - A workshop sikerességi aránya: **a résztvevők kb. 80%-a készített nappletet** a cohortban, és a kész nappletek betölthetők voltak több hostban (Strudel, Paja — utóbbiban volt bug, Amethyst) - A demo appletek között: live stream view, paste-to-upload flow, multiplayer chess (alpha), paint applet, profile maplet, és még sok más Az Amethyst-integráció még nem teljes: Vitor (az Amethyst fejlesztője) nem üldözte a specet, de ez a workshop hangulatából fakadóan várható volt. A spec „még evolvál”, és Sandwich örülne, ha a cohort tagjai nyitnának issue-kat + thumbs up-okkal jeleznék a prioritásokat. ## Inter-applet kommunikáció: „napplet://archetype/intent” A hiányzó feature: az egyik appletből egy másikba akciót indítani. A megoldás a séma: `napplet://archetype/intent?parameters` — ugyanaz a minta, mint az Android/iOS deep linkeknél (share, open profile, stb.). ### Miért NEM specifikálják túl a wire formatot? - A „semantics of data alone” túl merev — az intent-ek implicit kontextust hordoznak - Ha `profile/open` intentet hívsz, **nyilvánvaló, hogy npub-ot vagy nprofile-t** fogsz kapni, és a developer rájön, mit kell vele tennie - A wire format-ok száma „százezer potenciális” lenne, ha minden részletet formalizálnának — ez most túl sok overhead - **Az LLM/agent korában az under-specification gyakran jobban működik**, mint a túl-specifikáció: a fejlesztők „rátalálnak” a helyes használatra, és a system „magic”-ként hat, amikor két fejlesztő egymástól függetlenül ugyanarra a megoldásra jut Sandwich konkrét példája: Balázs (a cohort tagja) készített egy profile mapletet, ami megnyitotta a feedet. „Működött.” A kérdés: „Can your agent make sense of it?” — és a válasz igen, az LLM-ek számára ez az állapot „makes sense”. ### Mi következik ezután? - **Polish** + onboarding - **Notifications** (még nem készültek el) - **Inter-applet communication** (az imént tárgyalt kísérleti fázis) - **Desktop shell** (natív, nem böngésző-alapú) - **Egyedi kernel / cyberdeck** típusú microkernel-hardver — ez az „exoteric” végállapot, ahol a felhasználó a teljes szoftver-stack-et kontrollálja ## A napplet használati lehetőségek a szociális domainen túl A futásidejű (runtime) oldalról a napplet-modell **nem korlátozódik social appokra**: - **Játék-mod rendszer:** Sandwich készített egy „npub land” (korábban pubkey land) nevű játékot, ami nappleteket használ modokként — permissionless, és a felhasználó közelébe érve a játék betölti a mod-appletet - **Rádió-állomás applet** globálisan, bárki broadcastolhat - **Zenei / videó kollaborációs eszközök** (social aspect nélkül) - **Plugin rendszer** bármilyen alkalmazáshoz - A nappleteknek **NEM kell** a Nostr social aspect-jét használniuk — azonosításra (session-azonosító) használhatják a Nostr identity-t, de a képességek nagyon limitáltak lehetnek ### A paint applet, mint „MS Paint Nostr-ban” A workshop egyik legszemléletesebb demója: a **paint applet** — lényegében egy MS Paint-stílusú mini app, ami bármely kliensben betölthető, és amivel a felhasználó képeket annotálhat. A workflow: paint appletben rajzolás → right-click copy image → paste a long-form appletbe vagy note appletbe. „Visszatérés a jó öreg egyszerű időkbe, ahol minden nagyon egyszerű.” ## Sandwich Nostr-útja (2022-2025) Sandwich a teljes hátterét elmeséli, és ez a szakasz az epizód legjobb first-person története. ### A kezdet: 2022-es szabbatikálás - 2022-ben egy **„self-funded sabbatical”**-on volt, „kind of miserable” állapotban - Új szerződés vagy állás helyett az volt az ösztöne, hogy „play around a little bit” - Elindított egy **Lightning node-ot** (LNDG-vel kísérletezett) - Az LNDG-ben volt egy **Nostr notification** input — „what the hell is Nostr? This must be related to Bitcoin” - Egy barátja később emlékeztette, hogy **2020-ban**, a cenzúra-hisztéria idején már találkoztak a repóval, de akkor „csak egy repó volt”, nem kerestek semmit, amit építeni lehetne - Elkezdett játszani **Astral Ninja**-val — látta, hogy „ugyanaz a 10 ember aktív rajta”, és ez felkeltette az érdeklődését - Elolvasta a **NIP1-et** — „valami történt a fejemben, valami robbanásszerű, mind-blown, azonnal értelme lett” — ez a „mély húzás” indította el a fejlesztői utat ### Nostr Watch: 6 relay → 50 PR/3 nap - Kíváncsi volt, milyen relayek vannak — forkolta a **Nostr Relay Registry**-t (Fiat Jeff repója, vagy valaki másé, nem emlékszik pontosan) - A fork lett a **Nostr Watch** - Akkor jött a **flu** — 3 napig ágyban feküdt, a telefonja folyamatosan vibrált - Mire fel tudta venni a telefont (a flu miatt fényérzékeny volt): **kb. 50 pull request** várta, „what the fuck” - A Jack (jb55?) által posztolt link hatására az emberek elkezdték hozzáadni a saját relayjeiket - 6 relayről indult, és egy nap alatt kiderült, hogy a felfedezhetőség az egész ökoszisztémát blokkolja - A 2023-as év viszont „pretty hard” volt — a side project negatív visszajelzései (incel-imulzus a kommentekben) kimerítőek - Ma a Nostr Watch stabil és olcsó: cross-site scripting attack pár hete (gyors javítás), de „runs itself” - Gigi: „I use it all the time” — főként NIP-50 relayek keresésére és saját dolgok health check-jére ### Nsites v1 → Nsites v2: a spec-háború - Sandwich az **Nside.run**-t (mindkettőt, az elgépelést is) építette - Az eredeti Nside szerzője „nem igazán értette, mit csinált” — mások vették át a projektet, köztük Sandwich és **Hazard (hzrd149)** - Sandwich első szándéka nem az Nside volt, hanem egy **CLI / TUI** építése (NIP-46 key management-tel, mert nem akarta a privát kulcsát „random website secrets field”-jébe tenni) - A Florian-féle első CLI „nagyon jól sikerült”, de Sandwich egy **automatizáltabb, szebb CLI-t** akart - Az Nside.run kiadása „az első alkalom volt, amikor sokan tudták, hogy ez létezik” - **December 2025**: Hazard új specet tett közzé, de senki nem frissítette a stack-jét → Sandwich „getting pissed off and fed up with Master” - A megoldás: „ha te megcsinálod, mások követnek” — Sandwich kiadott egy Nside v2 gateway-t + Blossom szervert + relayt (ami csak Nside eventeket fogad) + frissített CLI-t + web deployert (statikus site drag-and-drop) - Az infrastruktúra **teljesen serverless, edge scripting on bunny.net** — „barely works, but very cheap to run” - A web deployer egy „novel idea” volt az Nsite-ok „ellopásáról” — ez viralitást kapott, és a leverage révén Sandwich tudta tagelni azokat, akiknek volt infrastruktúrájuk, hogy „update your shit” - Egy héten belül **mindenki frissített, és a PR merge-ölve lett** - Sandwich tervei: lebontja a saját Nside infrastruktúráját, mert „not intended for long-term” ### A NIP-66: relay mint state machine A NIP-66 a relayek állapotát írja le Nostr eventek formájában. Sandwich „really freaking excited” róla, mert: - A Nostr itt **„state machine-ként”** működik, de a state nem globális, hanem **relatív a felhasználó trust-gráfjához** - Egy **monitor / observer NPUB** publikál információt egy relayről — és ez „bárki lehet, akit követsz, vagy a web of trust-od része, vagy bármi más” - Első ránézésre „very arbitrary and useless”, amíg nem érted meg a relay-domain komplexitását A relay-domain „nagyon komplikált”, mert: - A relay URL-ek **„fuzzy string”-ek** — nem garantáltan egyediek - A NIP1 egészen a közelmúltig **nem specifikálta a relay path / segment kezelést** - Emiatt `relay.damis.io` és `relay.damis.io.io/gg` **ugyanaz a relay** — ez kliens-oldali optimalizálási problémákat okoz - A legtöbb string „garbage”: 15-20 ezer egyedi string, de ezek nagy része vagy offline, vagy „client bug seven months ago, that still exists somewhere” A NIP-66 általános értelme: a relay discovery-hez vezető út. A NIP-50 (search) relayek megtalálása a web of trust-ban nehéz, mert nem lehet „az összes NIP-50 relay a web of trust-omban” lekérdezést csinálni a NIP-11-ek egyenkénti hívása nélkül. A kliens-oldali deduplikáció „pretty efficiently” megoldható idővel. A NIP-66-ra **ráépül** a **trusted relay assertions** koncepció: bárki építhet adatot a liveness data tetejére, és a NIP-66 lényege, hogy **„csökkenti mások munkaterhét”**. --- ## 3. rész: Relay specializáció, vibe coding, AI slop scanning és bare metal GPU A harmadik, egyben utolsó rész négy nagy témát ölel fel: a relay specializáció jövőjét (NIP-66 trusted relay assertions, relay attributes, „subjective” self-descriptive words), Sandwich teljes vibe coding / agent workflow útját (waterfall, GSD, loop engineering, OpenSpec, Socratic method), az AI slop scanning szerepét a CI-ban, és a bare metal GPU vásárlás „Bitcoin bányászat” közgazdaságtanát. ## Relay specializáció és a NIP-66 trusted relay assertions A NIP-66-ra épül a **trusted relay assertions** koncepció: bárki építhet adatot a NIP-66 liveness data tetejére, és így **szubjektív trust score-ok** szerint lehet sorbarendezni a relayeket. Sandwich az outbox optimalizációban használja ezt másodlagos szűrőként (a web of trust grouping után). ### Relay discovery: 1500+ relay (Tor/I2P-vel együtt) A relay-ek száma a dedup után **~1500** — Tor és I2P relayekkel együtt. „Több relay, mint user” — ez a NIP-66 első látásra „arbitrary”-nak tűnő értelmét adja. ### A jövő: relay attributes (Hazard-del közös munka) Sandwich és **Hazard (hzrd149)** ~1,5 éve dolgozik együtt a relay specializáción. A Costa Rica-i beszélgetés után megegyeztek a **relay attributes** rendszerben: - A NIP-11-hez **9 PASCAL case attribute**-et lehet hozzáadni (a 9 a cap, az aggregatorok truncate-elnek) - Az attribute-ök **self-descriptive words** a relay viselkedéséről — NEM technikai implementációk, hanem **a relay operátor szubjektív döntése** (pl. „pubkey-indexer” a Purple Pages-hez) - A cél: ne atomizálják túl, hanem **„hashtag clouds”**-szerűen hagyják, hogy a közösség koalíciókat alkosson a saját szavaik köré - A specializáció dimenziói: **NIP-50 search támogatás, web-of-trust gating, fizetős vs. ingyenes, geoblokk, proof-of-work, restricted writes, clear-net / Tor / I2P / FIPS** - A NIP-1 korlátai miatt a payment filteringhez `capital R` + `!payment` formátumot használnak (negatív prefix a free relayekhez) Sandwich saját tervei: saját Purple Pages instance profil-lookup-ra, **Boris (highlight app)** újraépítése, és egy relay kifejezetten highlights + long form tartalomnak. ## Vibe coding: Sandwich 8 hónapos útja Sandwich a 2024-es LLM-robbanás óta fejleszti az agent workflow-ját, és az iterációk: ### 1. Auto-GPT / Baby-AGI korszak (2023 eleje) - Az első próbálkozások „beagle-agyi” loopokba ragadtak - Az agentek IQ-ja „100 ponttal alacsonyabbnak” tűnt — ugyanazt a fájlt 100-szor írták felül, vagy a root mappában kezdtek „destroy everything” - Sandwich humora: „I should have been outside skateboarding” — ehelyett ukrán és román fejlesztőkkel dolgozott korábban (kelet-európai csapatok vezetése → „I was babysitting my agent before it was cool”) ### 2. 2024 vége: az első „success” - A reasoning modellek megjelenésével az agent „elkezdett döntésein inflectálni” - Sandwich: „abrupt change in ability for me to delegate” - Az iteráció innentől nem „every 3 months”, hanem „every couple of days” - A **waterfall** volt az egyetlen módszer, ami működött: high-level dokumentum → spec → low-level design chunks → implementation - A használt modell: **GPT-4/5 Pro** (késői 4-es, korai 5-ös), „dead-arrow” fázisban ### 3. GSD (Get Shit Done): 7-8 hónap - Az első tooling, ami „worked exactly with how I thought” - A GSD research fázisa a projekt indulásakor nagyon fontos — különösen experimental / novel domain-eknél (Nostr régebben „miserable” volt az LLM-ek számára, mert client-server / username-password mintákat akartak erőltetni) - A GSD **milestone-okra bontja a scope-ot**, capture-eli a döntéseket, és a surface-re hozza a kontextust - A loop engineering mostanra „részben kiváltja” a GSD-t, de a GSD „template” a loop engineeringhez ### 4. OpenSpec (Fran ajánlotta, pár hete) - „Very lightweight”, kevésbé nehézkes, mint a GSD - „Quite good starting point” — GSD-szerű workflow építhető rá a sajátosságokkal - Sandwich még nem váltott, de a GSD-t hamarosan kinövi ### 5. A jelenlegi flow: back-and-forth + Socratic method - Minden projekt egy **AGENTS.md template**-tel indul (alap policy, nyelv, scope) - GSD-vel indul a projekt, „pretty good conversation” → research docs → design docs - **NIP-17**-en kommunikál a projekttel (minden projektnek saját NPUB) - A **Socratic method exclusively**: az első 10 prompt kérdés, NEM utasítás („what are the search keywords we have?”) - Az agent kérdez vissza, és a válaszokból építkezik a research - Pull-the-trigger után „basically done” ### A „top 5 things we could improve” gate - Minden feature branch végén megkérdezi: „what's the top 5 things we could improve on this feature branch before I merge?” - Ha 1-2 dolog „OK”, akkor még iterate - Ha minden „complete bullshit”, akkor kész - Ez a „opponent processing” elve: a tesztelő és az implementáló **különböző modellek**, mert a diverzitás segít ## Az AI agent workflow „visszatérése” a klasszikus szoftverfejlesztéshez Sandwich fontos megfigyelése: **ugyanazokat a struktúrákat építjük újra, mint a klasszikus szoftverfejlesztésben** — most agent-ekkel a humánok helyett. Specifikációk, milestone-ok, issue tracking, review team, CI. A konkrét workflow: - **Saját agent-ek** issues-okra és pull request-ekre (strict policy-val) - **Automated agent**, ami átnézi a „sloppy” issue-kat (amiket valószínűleg Sandwich posztolt), contextualizálja őket, és előkészíti a planninget a következő agent számára - **Development team agent** (cron-on fut) átveszi az issue-kat, PR-t nyit - **Review team agent** review-eli - Végső review: Sandwich maga, és ha baj van, „I fucked up somewhere” — „I haven't gotten angry at agents in a long time” A „vibe coded slop”-ra viszont **Sandwich soha nem ír tesztet** — „pollutes the context”, és a saját kódja „nem fontos” (UX / interface). Ez az ő szabálya: „never write tests ever” (kivéve, ahol fontos). ## AI slop scanning a CI-ban A „couple months ago” megjelent az **ai-slop-scan** library (eredetileg JavaScript, Sandwich talált egy Rust verziót is crates.io-n). Sandwich az **AGENTS.md-be** és a **CI-ba** is beépítette: - A CI pull request-jei **nem mennek zöldre**, amíg a slop-scan nem fut le - A cél: **„context poison”** megelőzése — minden alkalommal, amikor slop kerül a code base-be, az „örökre” ott van, amíg 3 napnyi munka ki nem takarítja - A **naming consistency** különösen fontos: ha egy terminust átnevezel, a function signature-ökben, a property-kben, a paraméterekben még hetekig előfordulhat, és az agent-ek „I renamed it” / „the term doesn't exist anywhere” válaszokat adnak, miközben a signature-ökben még mindig ott van - A **code becomes the context at a certain point in the project** — és a jó minták a code-ban a jövőbeli agent-ek outputját is meghatározzák - A **test-driven development** a project közepétől kezdve „really, really, really well” működik — különösen a behavior-driven development - A lényeg: **specializált implementer + specializált teszter, soha ne ugyanaz az agent/model** ## Bare metal GPU: a Bitcoin bányászat analógia Az utolsó nagy téma: **saját GPU hardver vásárlás** lokális modellek futtatásához. Sandwich őszinte ajánlása: ### A subsidizált korlát - Jelenleg **mindenki subsidizált modellek és service-ek** alatt dolgozik (pl. Pablo fedezte fel a jetgpt.com „hack”-et: egy MCP wrapper, ami nem számít bele a tervedbe) - A **„50K USD per week”** compute-költség, amit egyes agent-ek generálnak, „nem tarthat fent” — az AI bubble ki fog pukkanni - A token-use-nak **gazdaságilag optimalizálttá** kell válnia ### A hardver-vásárlási döntés - Sandwich „50-100K USD”-t tervez költeni (ahelyett, hogy új autót venne) - Az **RTX PRO 6000 Blackwell** a jelenlegi „út” - A limitáció: az NVENC/NVDEC encoder/decoder **korlátozva van** (csak 4 layer, miközben a chip 10-12-öt tudna) — ez az Nvidia „enterprise vs. consumer” árazási stratégiája - A megoldás: az **Nvidia patch** bash script, ami eltávolítja a limitet („chip tuning your car”) - Sandwich-nek már van hardvere az US-ben, amit az unboxing során fog összerakni ### A Bitcoin bányászat analógia - A GPU-vásárlás **nem befektetés, hanem operating cost** - A kulc: **„cost per watt”** és a refresh ciklusok - Nem szabad érzelmileg kötődni a hardverhez — „wash the market”, „cycle your equipment”, különben veszteséges - A subsidy era vége: amikor a cloud model-ek ára felmegy, a lokális hardver megtérülése javul - A lokális modellek Austin (Austin) kutatása szerint **„smaller and cheaper and more competitive faster than anyone basically thinks”** — ez motiválja a vásárlást Sandwich záróüzenete: **„everyone should do it”** — squeeze ki a subsidizált modellekből amennyit lehet, de készülj fel a saját hardverre. ## Outro Sandwich „fáradt, 3 órás sétának érezte az epizódot”, és „bocsánatot kért, ha valakinek végig kellett hallgatnia”. A pénteki demó session-re mentek haza — Sandwich-nek „some ideas”-ok vannak, és várja, hogy a tudatalattija megoldja a maradékot alvás közben. Az outro: „Fantastic.” --- ## Forrás - **Epizód weboldal:** - **Hangfájl (M4A):** - **Vendég:** Sandwich (napplet.run) — - **Házigazda:** Gigi (dergigi) — - **Nostr event:** - **Transcript forrása:** OpenAI Whisper `ggml-medium.en.bin` (whisper.cpp, Metal GPU), saját futtatás 2026-07-23 - **Feldolgozás:** Henky-pipeline (3-chunk: 1 subagent + 2 self-write, 2026-07-23)