nappletRuntime provides an API
Propose a capability.
First check the merged and proposed NAPs. Extend an existing domain when it already owns the operation. For a distinct runtime capability, start a NAP proposal.
NAP interface template ↗Contribute / Start with the boundary
One capability.
A shared contract.
A new NAP makes sense when napplets need a runtime-provided API that the existing capability contracts do not cover.
The decision guide below is editorial guidance inferred from the upstream boundary rule. The repository’s current guidance takes precedence.
Does this need a NAP?
Napplets agree on a payload
Write a convention.
If the idea describes what napplets say to one another rather than a runtime API, use a convention. A shared message shape does not by itself need a new NAP.
Convention template ↗A role needs a name
Propose an archetype.
If the idea names what kind of napplet this is and where its responsibility ends, it belongs in the NAAT registry. An archetype owns neither an API nor a payload.
Archetype template ↗A host carries the contract
Discuss the projection.
Transport and host bindings belong to a projection. Keep the capability contract separate from how a browser or another host delivers it.
Web projection ↗From idea to pull request
Check the current conversation.
Search the directory and open PRs for overlap. Describe the missing capability, which napplets need it, and what the runtime would provide.
Start from the upstream template.
Fork napplet/naps, make a branch for the spec, and add
naps/NAP-WORD.mdusing the current interface template. Keep one spec concern in the PR.Make the contract reviewable.
Describe operations, schemas, errors, dependencies, runtime behavior, and security boundaries. Follow the template’s language-neutral tables and link to the living projection specifications. Read the contributor guide for the current dependency and changelog rules.
Open the discussion.
Use a title such as
NAP-WORD: Add a focused capability. Explain the motivation and concrete changes. Keep the registry entry and related docs consistent, and link an implementation when available.Refine it with the community.
Discuss the proposal in PR comments, respond to interoperability concerns, and update the spec as the design stabilizes. Maintainers decide when to merge; an open PR is not acceptance.
Based on upstream governance and the contributor guide. Names and acceptance are maintained by that repository.
Refreshed from upstream
The current template
These are the headings in the current interface template. Open it for the latest instructions and examples.
Use the NAP template ↗- Description
- API Surface
- Schemas
- Wire Protocol
- Examples
- Error Handling
- Shell Behavior
- Security Considerations
- Implementations
Current upstream boundary and governance notes
A NAP is runtime-provided AND defines an API surface. A convention is napplet-agreed AND defines message semantics. Only runtime-provided API surfaces are NAPs.
- NIP-style informal process:
- Fork this repo, add a markdown file under naps/ following the interface template, open a PR. Every NAP spec is a named runtime capability contract. Templates and the NAP registry (README.md) stay at the repo root.
- Community discusses via PR comments.
- Maintainers merge when the spec has been implemented, defended and has stabilized.
- No formal stages, review committees, or voting.
- NAP-WORD names are first-come-first-served but must be approved by the maintainer.