30: Napplets w/ Sandwich — No Solutions

"You should be able to compose your clients."

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

Related dialogues:

People mentioned:

Projects & tech mentioned:

Recorded at 959,164.