30: Napplets w/ Sandwich

&quot;You should be able to compose your clients.&quot; Sandwich &amp; Gigi take a walk. Listen on sovereignengineering.io Sandwich and Gigi spend the first 45 minutes or so talking through napplets: composable, sandboxed Nostr apps that can run inside a host shell while the host mediates signing, storage, relay access, uploads, permissions, and user trust. What starts as a conversation about applets quickly becomes an operating-system conversation: if Nostr is flexible enough to carry many kinds of software, clients probably need to become composable runtimes instead of monolithic apps. Along the way they get into browser sandboxes, iframes, postMessage, malicious applets, Blossom uploads, NIP-5D, nsites, specialized relays, agent workflows, slop scanning, and why the AI subsidy era will not last forever. In this dialogue: why a normal Nostr client can feel too restrictive for a protocol built around maximum flexibility how napplets grew out of earlier experiments with Naps, Nap.run, nsites, Hyprland-inspired desktops, Tauri, Thorium, and iframe hardening why the host runtime handles keys, signing, encryption, relays, resource loading, storage, uploads, and user prompts why napplets should get high-level helper APIs plus low-level escape hatches instead of direct access to everything how a napplet can upload through Blossom without knowing which Blossom server the user prefers why the shell should see plaintext over the message bus, and how that helps defend users from malicious applets how applet-to-app communication starts to look like Android intents, MIME types, archetypes, and operating-system resource APIs why the browser is a practical deployment target even if the napplet protocol itself is not browser-bound what Kehto, Paja, the napplet dev tooling, and the no-dependencies approach are trying to protect how a workshop produced a dozen napplets, including live stream views, paste-to-upload flows, and even a rough multiplayer chess app why nsites, nsyte, Blossom, Hashtree, and specialized relays all rhyme with the same broader Nostr publishing model why relay specialization and relay discovery might matter more than one giant general-purpose relay model how agent workflows are starting to rebuild older software-development structures: specs, milestones, issues, review teams, and CI why slop scanning, naming discipline, and opponent processing matter once code becomes the context future agents learn from why local model hardware is tempting, but only if you think about it like mining: power, refresh cycles, subsidy cliffs, and cost per watt People mentioned: hzrd149 fiatjaf Pablo Austin Franzap Projects &amp; tech mentioned: napplet.run Napplet Workshop NIP-5D Kehto nsite.run nsyte nsyte.run Blossom Hashtree Nostr NDK Applesauce Amber zap.stream Nostr Watch NIP-66</a