Napps

All Napps are Nsites, but not all Nsites are Napps.

Napps are Nsites with extra practical powers. The goal is portable client behavior across gateways and operators, not just static hosting.

Super powers

  • - Cloneability into your own sovereign space.
  • - Gateway redundancy when one resolver is down.
  • - Potential distribution patterns similar to app stores.
  • - Multiple named sites can act like a personal app store catalog.

Working definition

A Nostr client deployed as an Nsite that supports at least 2/3 of core Napp capabilities.

  • - Cloneability: resolving through subdomain or author.
  • - Key login and/or signing flows (NIP-07 or remote signing in practice).

Personal app store model

A single pubkey can publish multiple named sites and use them as a personal app-store style catalog. Each named site can represent one app, one version channel, or one feature branch while staying under the same publisher identity.

There is only one root app per pubkey (the root `15128` site). Treat that root as the canonical entrypoint, then branch into additional named `35128` sites for the rest of the app collection.

Open questions

Carbon copy behavior, auto-update semantics, and manifest-driven inject/resolve patterns are still evolving. The debugger and examples pages are built to test those assumptions in public.