# napplet: Composable Nostr apps

Sandboxed Nostr web applets that delegate signing, storage, and relay access to a host shell over the NIP-5D JSON envelope wire format.

- [Get Started](https://napplet.run/docs/guide/getting-started.md)
- [What are napplets?](https://napplet.run/docs/guide/index.md)
- [Community](https://armada.buzz/invite/naddr1qvzqqqyzz5pzpjk98hj7z978r9xc9d2ymagw6tga0lx0s06y8lhpy9twc2kp8uwdqqqqpwqpw5#BAACAwTDEKKhS9_iA_qOc1n4ljVt)
- [napplet.run](https://napplet.run/)

## Single-purpose by design

A napplet does one thing well. The shell composes many sandboxed napplets instead of one monolithic client re-implementing feeds, DMs, profiles, and relay management.

## Every request brokered

Napplets never call a signer, relay, or store directly. Every request is brokered through the shell over postMessage — to a remote signer, an extension, or the shell's own services. No window.nostr is installed.

## Browser-enforced sandbox

The iframe uses allow-scripts only — no allow-same-origin. Identity is bound to the MessagePort the verified document hands over in napplet.hello, and revoked if the frame navigates.

## Modular NAP domains

Capabilities are split into NAP domains (relay, storage, inc, identity, and more). Shells implement the domains they support; napplets gate on domain presence.

## Just a JSON envelope

Every message is { type: "domain.action", ...payload }. A simple, standardized wire format that any shell can host and any web app can speak.

## Portable across shells

Build once against the protocol. Any compatible shell — like the Kehto reference runtime — can host your napplet without changes.