NIP-5D is an open proposal for a postMessage protocol through which sandboxed web applications (“napplets”) running in iframes could communicate with a hosting application (“shell”). The draft would extend NIP-5A (Static Websites) with a runtime communication layer that gives web apps access to Nostr functionality without exposing the user’s private key.

How It Works

Under the proposal, a shell application would load a napplet in a sandboxed iframe. The napplet would communicate with the shell through the browser’s postMessage API using a structured message protocol. The shell would provide signing, relay access, and user context through this channel while keeping the user’s private key outside the iframe.

Use Cases

  • Interactive Nostr apps: Build apps that read and write Nostr events without requiring users to paste their nsec
  • App marketplace: Distribute interactive web applications through Nostr events
  • Sandboxed extensions: Add functionality to Nostr clients through third-party napplets

Implementations

Myco v0.7.0 implements a NIP-5D napplet runtime inside its Android FIPS mesh application. Napplets run in sandboxed frames and request user-approved identity, relay, outbox, mesh, picture, and file capabilities through the host. NIP-5D remains an open proposal, so Myco’s implementation is current experimental evidence rather than a final interoperability guarantee.

Primary sources:

Mentioned in:

See also: