Conversation
Rebased onto current master; spec only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dskvr
marked this pull request as draft
June 18, 2026 22:43
Contributor
Author
|
Need to add some kind of cvm registry that discovers cvms, so that the user can enable them in the runtime. This would allow more easy implementation in napplets. |
Contributor
Author
|
CMV implementation doesn't work. works in kehto playground using the same library. try again. |
* Let runtimes broker common ContextVM tool families NAP-CVM already lets napplets reach explicit ContextVM servers. This adds a narrower registry facade so a runtime can discover common tool schemas, choose providers, verify schema hashes, cache safe calls, and expose the resulting family calls without pushing provider-selection logic into each napplet. Constraint: PR must build on the existing NAP-CVM branch and preserve direct CVM implementation paths Constraint: ContextVM CEP-15 already defines common-schema hashing, so NAP-CVM should reference it instead of inventing version semantics Rejected: Add a new NAP domain | registry belongs under the existing cvm capability Rejected: Define a full external registry protocol | ContextVM announcements and runtime curation already cover discovery Confidence: high Scope-risk: narrow Directive: Keep registry semantics shell-level; do not define new ContextVM server behavior here Tested: git diff --check Tested: HTTP 200 for ContextVM spec, CEP-15, and MCP tools references Not-tested: No executable test harness exists in this markdown-only repo * Treat CVM registry discovery as liveness candidates Runtime registry discovery can outlive the provider that originally announced it. This clarifies that registry entries are candidates until the shell has recently verified reachability, and that calls should fall back within the same schema hash before returning provider unavailable. Constraint: Keep the liveness solution as a minimal NAP-CVM wording change Rejected: Add a heartbeat or separate liveness protocol | too much machinery for stale registry candidates Confidence: high Scope-risk: narrow Directive: Keep liveness checks runtime-owned; napplets should not need provider retry logic Tested: git diff --check Not-tested: No executable test harness exists in this markdown-only repo --------- Co-authored-by: sandwich <dskvr@users.noreply.github.com>
ContextVM operations, registry helpers, server refs, request options, registry entries, and MCP JSON-RPC envelopes now use operation tables plus CDDL-style schemas instead of TypeScript declarations. Constraint: Keep this branch scoped to NAP-CVM. Confidence: high Scope-risk: narrow Tested: git diff --check Tested: rg found no TypeScript code fences or declarations in naps/NAP-CVM.md
dskvr
marked this pull request as ready for review
July 2, 2026 14:32
The ContextVM bridge schemas now use primitive, enum, and field tables instead of a CDDL-style block. The JSON-RPC, registry, server, and event shapes remain unchanged while the spec avoids code-looking type definitions. Constraint: PR #31 owns NAP-CVM; keep this change scoped to that spec file. Confidence: high Scope-risk: narrow Tested: rg for cddl/typescript schema fences and type assignment patterns in NAP-CVM Tested: git diff --check -- naps/NAP-CVM.md
Open NAP proposal branches need reader-visible changelogs that track semantic spec changes without recording formatting-only migrations. Constraint: Changelog entries are one bullet per semantic commit-change. Rejected: Include schema-table or formatting-only commits | they do not change the spec contract or boundary. Confidence: high Scope-risk: narrow Directive: Keep future changelog entries semantic; omit changelog-only and formatting-only commits. Tested: git diff --check Not-tested: Rendered Markdown
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds NAP-CVM, a shell-provided bridge for ContextVM/MCP-over-Nostr. It lets napplets discover servers, send MCP requests, use common MCP convenience wrappers, receive server-pushed MCP events, and call shell-curated ContextVM registry families while the runtime handles ContextVM relay transport, initialization, signing, encryption, JSON-RPC correlation, provider/schema selection, policy, and optional payment prompts.
Namespace
window.napplet.cvmStatus
draftChanges
cvm.discover,cvm.request,cvm.close, andcvm.event.request:listTools,callTool,listResources, andreadResource.cvm.registry.list,cvm.registry.has,cvm.registry.describe, andcvm.registry.call.valuedependency for ContextVM payment prompts when a server requires value exchange.Downstream
Napplets receive MCP results and curated registry entries, not ContextVM private keys, relay credentials, direct sockets, or raw transport authority. Registry calls are shell-level conveniences and do not define new ContextVM server behavior.
Reference
Changelog
e001eaf- Introduced NAP-CVM as a native ContextVM bridge.1873f7e- Added a runtime registry facade for discovering CVM surfaces.