CEP-XX server profile metadata and socials

[ContextVM-org]

Summary

ContextVM servers should have a standard way to publish a persistent public profile and a public communication channel, separate from capability announcements. Some servers are already doing this, so this would simply be the standardization of that practice.

This issue tracks a proposal to standardize:

• server profile metadata via Nostr kind 0
• server public/social updates via Nostr kind 1
• website integration so ContextVM servers can expose a richer public identity beyond announcements

Problem

Current ContextVM announcements are useful for discovery of capabilities, but they are not the same as a server profile.

We need a standard way for servers to:

• publish human-facing profile metadata
• expose social/contact context around the server
• publish public updates in a Nostr-native way
• integrate that information into the ContextVM website and server listings

Goal

Define a ContextVM convention for server identity and public communication using existing Nostr primitives instead of inventing custom event kinds.

Direction

Use:

• Nostr kind 0 for server profile metadata, aligned with NIP-01
• Nostr kind 1 for public short text notes, aligned with NIP-10-style ecosystem usage

[siddharthjaiswal05]

Hi, I've been studying this issue as part of my Summer of Bitcoin application
for the CEP-XX project. I've gone through the CEP-6 spec, the NIP-01 and NIP-10
conventions, and the existing contextvm-docs to understand the problem space.
Here's my analysis.

The Core Problem

CEP-6 (kind 11316) was designed for one specific job: letting MCP clients
programmatically discover what capabilities a server exposes. It does that well.
But it was never designed to answer the question a human asks when browsing a
server listing: "Who runs this? Can I trust it? How do I contact them?"

Currently, some fields in the kind 11316 tags (name, about, picture, website)
overlap with what would naturally live in a Nostr kind 0 profile. This creates
two problems:

1. Every time a server updates its capabilities (new tool, changed version),
   it must republish the kind 11316 event, which also churns the identity
   fields unnecessarily, making it harder to track meaningful identity changes
   vs routine capability updates.

2. There is no standardized place for richer identity data (nip05 verification,
   operator information, social links, Lightning address) that would make server
   listings trustworthy and human-friendly.

Field Analysis: What Belongs Where

Kind 11316 (CEP-6) - Capability announcement, machine-readable:

• protocolVersion: which MCP version the server supports
• capabilities.tools / resources / prompts: what the server exposes
• serverInfo.name / serverInfo.version: technical identifier and version
• instructions: operational hint for MCP clients on session initialization
• support_encryption tag: transport-level feature flag for clients

These fields exist purely to help a client decide whether and how to connect.
They should be updated whenever capabilities change and are not meant for
human consumption.

Kind 0 (NIP-01 profile metadata): Server identity, human-readable:

• name: human-readable display name of the server or operator
• display_name: alternate display name
• about: description of the server's purpose and who operates it
• picture: avatar or logo URL
• banner: optional banner image for rich UI presentation
• website: landing page, documentation, or operator homepage
• nip05: verifiable Nostr address (e.g. server@example.com) for identity trust
• lud16: Lightning address for contact or tipping
• contact: operator contact details

These fields are stable over time. A server's identity does not change when
it adds a new tool. Decoupling them means kind 0 events can be trusted as a
persistent, verifiable identity anchor independent of operational changes.

Kind 1 (NIP-10 short text notes): Public communication:

• Changelog posts announcing new capabilities or tools
• Maintenance and downtime notices
• Community updates and general server news

Kind 1 is already the standard Nostr mechanism for public posts and fits
naturally for server-operator communication without inventing a custom event kind.

Why This Separation Matters

The key principle is separation of concerns. Announcements serve machines.
Profiles serve humans. Notes serve communication.

This also aligns with how the broader Nostr ecosystem already works. NIP-01
kind 0 is used by every Nostr client to render profiles. By using it for
ContextVM servers as well, server listings on the ContextVM website can
immediately integrate with existing Nostr identity infrastructure including
NIP-05 verification, lightning payments via lud16, and profile rendering
libraries without any custom implementation.

The alternative (embedding all identity data into kind 11316 tags) would mean
that ContextVM server identity is siloed from the broader Nostr ecosystem and
cannot benefit from existing tooling.

On the Discovery Linkage

One thing worth specifying in CEP-XX is how a client correlates a server's
kind 11316 announcement with its kind 0 profile. The natural answer is the
server's public key (pubkey), which is already the primary identifier in both
event types. A client that fetches a kind 11316 event can use the same pubkey
to query for the kind 0 profile and kind 1 notes from any Nostr relay, with
no additional linking mechanism required.

This also means the CEP does not need to introduce any new event kinds — it
simply defines the convention that ContextVM servers SHOULD publish a kind 0
profile and MAY publish kind 1 notes, and specifies which fields are
recommended for server identity context.

Small Docs Contribution

I have opened a PR on CEP-6 to document this distinction under a
"Related Concepts" section, so that readers of the existing spec understand
why identity and capability data are intentionally kept separate:

[https://github.com//pull/32]

Happy to discuss any of the above in more detail, or help draft specific
sections of the CEP-XX specification.