Kihagyás

No Solutions #30 — Napplets w/ Sandwich

Epizód: Episode 30: Napplets • Dátum: 2026-07-22 • Házigazda: Gigi (dergigi) • Vendég: Sandwich (napplet.run) Forrás: sovereignengineering.io • Blossom M4A (52 MB, 1:37:45) 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

Vissza a tetejére