diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
new file mode 100644
index 0000000..2c74cb3
--- /dev/null
+++ b/.github/workflows/ci.yml
@@ -0,0 +1,36 @@
+name: CI
+
+on:
+  pull_request:
+  push:
+    branches:
+      - master
+
+jobs:
+  check:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Setup Bun
+        uses: oven-sh/setup-bun@v2
+        with:
+          bun-version: latest
+
+      - name: Install dependencies
+        run: bun install --frozen-lockfile
+
+      - name: Type check
+        run: bun run check
+
+      - name: Unit tests
+        # Full `bun test` fails on a pre-existing svelte-sonner -> runed
+        # resolution error; run the green files until that is fixed.
+        run: bun test src/lib/content/seo-snapshot.test.ts src/lib/seo.test.ts
+
+      - name: Build
+        run: bun run build
+
+      - name: Check SEO build output
+        run: bun run check:seo
diff --git a/.github/workflows/deploy-github-pages.yml b/.github/workflows/deploy-github-pages.yml
index 845ae05..d18efe2 100644
--- a/.github/workflows/deploy-github-pages.yml
+++ b/.github/workflows/deploy-github-pages.yml
@@ -38,8 +38,8 @@ jobs:
           GITHUB_PAGES: 'true'
         run: bun run build
 
-      - name: Add SPA fallback for GitHub Pages
-        run: cp build/index.html build/404.html
+      - name: Check SEO build output
+        run: bun run check:seo
 
       - name: Upload Pages artifact
         uses: actions/upload-pages-artifact@v3
diff --git a/package.json b/package.json
index 07380f8..a2897f5 100644
--- a/package.json
+++ b/package.json
@@ -6,6 +6,7 @@
 	"scripts": {
 		"dev": "vite dev",
 		"build": "vite build",
+		"check:seo": "bun scripts/check-seo-build.ts",
 		"preview": "vite preview",
 		"prepare": "svelte-kit sync || echo ''",
 		"check": "svelte-kit sync && svelte-check --tsconfig ./tsconfig.json",
@@ -13,7 +14,8 @@
 		"format": "prettier --write .",
 		"lint": "prettier --check . && eslint .",
 		"test": "bun test",
-		"test:watch": "bun test --watch"
+		"test:watch": "bun test --watch",
+		"content:refresh": "bun scripts/refresh-seo-snapshot.ts"
 	},
 	"devDependencies": {
 		"@changesets/cli": "^2.31.1",
diff --git a/scripts/check-seo-build.ts b/scripts/check-seo-build.ts
new file mode 100644
index 0000000..a33195e
--- /dev/null
+++ b/scripts/check-seo-build.ts
@@ -0,0 +1,222 @@
+import { readFileSync, readdirSync } from 'node:fs';
+import { getArticleIdentifier, seoSnapshot } from '../src/lib/content/seo-snapshot';
+import { nprofileEncode, npubEncode } from 'nostr-tools/nip19';
+
+const siteOrigin = 'https://contextvm.org';
+const staticPages = new Map([
+	['index.html', '/'],
+	['about.html', '/about'],
+	['blog.html', '/blog'],
+	['faqs.html', '/faqs'],
+	['servers.html', '/servers'],
+	['slides.html', '/slides']
+]);
+const articlePages = new Map(
+	seoSnapshot.articles.flatMap((article) => {
+		const identifier = getArticleIdentifier(article);
+		return identifier
+			? [[`blog/${identifier}.html`, `/blog/${encodeURIComponent(identifier)}`] as const]
+			: [];
+	})
+);
+const canonicalServerPages = new Map(
+	seoSnapshot.servers.map(
+		(server) => [`s/${server.event.pubkey}.html`, `/s/${server.event.pubkey}`] as const
+	)
+);
+const serverAliasPages = new Map(
+	seoSnapshot.servers.flatMap((server) => {
+		const canonicalPath = `/s/${server.event.pubkey}`;
+		const nprofile = nprofileEncode({
+			pubkey: server.event.pubkey,
+			relays: server.relays
+		});
+		return [
+			[`s/${npubEncode(server.event.pubkey)}.html`, canonicalPath] as const,
+			[`s/${nprofile}.html`, canonicalPath] as const
+		];
+	})
+);
+const serverPages = new Map([...canonicalServerPages, ...serverAliasPages]);
+const pages = new Map([...staticPages, ...articlePages, ...serverPages]);
+
+function readBuildFile(path: string): string {
+	return readFileSync(new URL(`../build/${path}`, import.meta.url), 'utf8');
+}
+
+function schemaTypes(html: string, page: string): string[] {
+	const matches = [...html.matchAll(/<script type="application\/ld\+json">([^<]+)<\/script>/g)];
+	if (matches.length !== 1) {
+		throw new Error(`${page} contains ${matches.length} JSON-LD blocks; expected 1`);
+	}
+
+	const structuredData = JSON.parse(matches[0][1]) as {
+		'@graph'?: Array<{ '@type'?: string }>;
+	};
+	return structuredData['@graph']?.map((entry) => entry['@type'] ?? '') ?? [];
+}
+
+for (const [page, path] of pages) {
+	const html = readBuildFile(page);
+	const expectedCanonical = `${siteOrigin}${path}`;
+	const canonicalUrls = [...html.matchAll(/<link rel="canonical" href="([^"]+)"/g)].map(
+		(match) => match[1]
+	);
+	const titles = [...html.matchAll(/<title>([^<]+)<\/title>/g)].map((match) => match[1]);
+	const descriptions = [...html.matchAll(/<meta name="description" content="([^"]+)"/g)].map(
+		(match) => match[1]
+	);
+	const robots = [...html.matchAll(/<meta name="robots" content="([^"]+)"/g)].map(
+		(match) => match[1]
+	);
+	const openGraphUrls = [...html.matchAll(/<meta property="og:url" content="([^"]+)"/g)].map(
+		(match) => match[1]
+	);
+	const types = schemaTypes(html, page);
+
+	if (titles.length !== 1 || !titles[0].trim()) {
+		throw new Error(`${page} contains ${titles.length} non-empty titles; expected 1`);
+	}
+	if (descriptions.length !== 1 || !descriptions[0].trim()) {
+		throw new Error(`${page} contains ${descriptions.length} non-empty descriptions; expected 1`);
+	}
+	if (canonicalUrls.length !== 1 || canonicalUrls[0] !== expectedCanonical) {
+		throw new Error(
+			`${page} has canonical ${JSON.stringify(canonicalUrls)}; expected ${expectedCanonical}`
+		);
+	}
+	if (robots.length !== 1 || robots[0] !== 'index, follow') {
+		throw new Error(
+			`${page} has robots directives ${JSON.stringify(robots)}; expected index, follow`
+		);
+	}
+	if (openGraphUrls.length !== 1 || openGraphUrls[0] !== expectedCanonical) {
+		throw new Error(
+			`${page} has Open Graph URLs ${JSON.stringify(openGraphUrls)}; expected ${expectedCanonical}`
+		);
+	}
+	if (!types.includes('Organization') || !types.includes('WebSite')) {
+		throw new Error(`${page} is missing the Organization or WebSite schema`);
+	}
+	if (html.includes('contextvm.com') || html.includes('sveltekit-prerender')) {
+		throw new Error(`${page} contains an obsolete or placeholder SEO URL`);
+	}
+}
+
+for (const page of articlePages.keys()) {
+	const html = readBuildFile(page);
+	const types = schemaTypes(html, page);
+	const images = [...html.matchAll(/<meta property="og:image" content="([^"]+)"/g)].map(
+		(match) => match[1]
+	);
+
+	if (!html.includes('<article') || !html.includes('<nav aria-label="Breadcrumb"')) {
+		throw new Error(`${page} is missing its prerendered article or visible breadcrumb`);
+	}
+	if (!types.includes('Article') || !types.includes('BreadcrumbList')) {
+		throw new Error(`${page} is missing Article or BreadcrumbList structured data`);
+	}
+	if (images.length !== 1 || !images[0].startsWith('https://')) {
+		throw new Error(`${page} does not have one absolute Open Graph image`);
+	}
+}
+
+for (const page of serverPages.keys()) {
+	const html = readBuildFile(page);
+	if (!html.includes('<article') || !html.includes('<nav aria-label="Breadcrumb"')) {
+		throw new Error(`${page} is missing its prerendered server profile or visible breadcrumb`);
+	}
+	if (!/<h1[^>]*>[^<]+<\/h1>/.test(html)) {
+		throw new Error(`${page} is missing its server-name heading`);
+	}
+}
+
+const builtArticlePages = readdirSync(new URL('../build/blog/', import.meta.url))
+	.filter((file) => file.endsWith('.html'))
+	.sort();
+const expectedArticlePages = [...articlePages.keys()]
+	.map((page) => page.slice('blog/'.length))
+	.sort();
+if (JSON.stringify(builtArticlePages) !== JSON.stringify(expectedArticlePages)) {
+	throw new Error('The built article routes do not match the reviewed snapshot');
+}
+
+const builtServerPages = readdirSync(new URL('../build/s/', import.meta.url))
+	.filter((file) => file.endsWith('.html'))
+	.sort();
+const expectedServerPages = [...serverPages.keys()].map((page) => page.slice('s/'.length)).sort();
+if (JSON.stringify(builtServerPages) !== JSON.stringify(expectedServerPages)) {
+	throw new Error('The built server routes do not match the curated allowlist');
+}
+
+const homepage = readBuildFile('index.html');
+if (!homepage.includes('<h1') || !homepage.includes('ContextVM')) {
+	throw new Error('index.html does not contain the prerendered homepage');
+}
+
+const githubPagesBase = '/contextvm-site';
+const isGitHubPagesBuild = homepage.includes(`href="${githubPagesBase}/favicon.ico"`);
+if (isGitHubPagesBuild) {
+	for (const page of pages.keys()) {
+		const internalLinks = [...readBuildFile(page).matchAll(/<a\b[^>]*href="([^"]+)"/g)]
+			.map((match) => match[1])
+			.filter((href) => href.startsWith('/') && !href.startsWith('//'));
+		const linksOutsideBase = internalLinks.filter(
+			(href) => href !== githubPagesBase && !href.startsWith(`${githubPagesBase}/`)
+		);
+
+		if (linksOutsideBase.length > 0) {
+			throw new Error(
+				`${page} has internal links outside ${githubPagesBase}: ${JSON.stringify(linksOutsideBase)}`
+			);
+		}
+	}
+}
+
+const about = readBuildFile('about.html');
+if (!about.includes('Imagine a world where anyone, anywhere')) {
+	throw new Error('about.html does not contain the About page copy');
+}
+
+const faqs = readBuildFile('faqs.html');
+if (
+	!faqs.includes('What is ContextVM?') ||
+	!faqs.includes('Rather than relying on centralized infrastructure')
+) {
+	throw new Error('faqs.html does not contain the FAQ questions and answers');
+}
+
+const sitemapPages = new Map([...staticPages, ...articlePages, ...canonicalServerPages]);
+const expectedSitemapUrls = [...sitemapPages.values()].map((path) => `${siteOrigin}${path}`);
+const sitemapUrls = [...readBuildFile('sitemap.xml').matchAll(/<loc>([^<]+)<\/loc>/g)].map(
+	(match) => match[1]
+);
+if (JSON.stringify(sitemapUrls) !== JSON.stringify(expectedSitemapUrls)) {
+	throw new Error('sitemap.xml does not match the static and snapshot-backed routes');
+}
+
+const robots = readBuildFile('robots.txt').trim();
+const expectedRobots = `User-agent: *
+Allow: /
+
+Sitemap: ${siteOrigin}/sitemap.xml`;
+if (robots !== expectedRobots) {
+	throw new Error('robots.txt does not match the expected crawl policy and sitemap URL');
+}
+
+const fallback = readBuildFile('404.html');
+if (fallback === homepage) {
+	throw new Error('404.html duplicates the prerendered homepage');
+}
+
+const vercelConfig = JSON.parse(
+	readFileSync(new URL('../vercel.json', import.meta.url), 'utf8')
+) as { cleanUrls?: boolean; rewrites?: Array<{ source?: string; destination?: string }> };
+const hasIndexFallback = vercelConfig.rewrites?.some(
+	(rewrite) => rewrite.source === '/(.*)' && rewrite.destination === '/index.html'
+);
+if (vercelConfig.cleanUrls !== true || hasIndexFallback) {
+	throw new Error('vercel.json must use clean URLs without an index.html catch-all rewrite');
+}
+
+console.log('SEO build output is valid');
diff --git a/scripts/refresh-seo-snapshot.ts b/scripts/refresh-seo-snapshot.ts
new file mode 100644
index 0000000..7efe23d
--- /dev/null
+++ b/scripts/refresh-seo-snapshot.ts
@@ -0,0 +1,168 @@
+import { InitializeResultSchema } from '@contextvm/mcp-sdk/types.js';
+import { SERVER_ANNOUNCEMENT_KIND } from '@contextvm/sdk';
+import { SimplePool } from 'nostr-tools/pool';
+import { LongFormArticle } from 'nostr-tools/kinds';
+import { validateEvent, verifyEvent, type Event } from 'nostr-tools';
+import { readFile, rename, writeFile } from 'node:fs/promises';
+import {
+	ARTICLE_AUTHOR,
+	ARTICLE_RELAYS,
+	EXCLUDED_ARTICLE_IDENTIFIERS,
+	SERVER_SOURCES
+} from './seo-snapshot-sources';
+
+interface ServerSnapshot {
+	event: Event;
+	relays: string[];
+}
+
+interface SeoSnapshot {
+	schemaVersion: 1;
+	generatedAt: string;
+	articles: Event[];
+	servers: ServerSnapshot[];
+}
+
+const SNAPSHOT_PATH = new URL('../src/lib/content/seo-snapshot.json', import.meta.url);
+const TEMP_PATH = new URL('../src/lib/content/seo-snapshot.json.tmp', import.meta.url);
+const MAX_WAIT_MS = 10_000;
+
+function tagValue(event: Event, name: string): string | null {
+	return event.tags.find((tag) => tag[0] === name)?.[1] || null;
+}
+
+// Website/picture tags are rendered into prerendered href/src attributes, so
+// anything that is not a plain http(s) URL is rejected at this trust boundary.
+function safeHttpUrl(value: string | null): boolean {
+	if (value === null) return true;
+	try {
+		const protocol = new URL(value).protocol;
+		return protocol === 'http:' || protocol === 'https:';
+	} catch {
+		return false;
+	}
+}
+
+function validSignedEvent(event: Event): boolean {
+	return validateEvent(event) && verifyEvent(event);
+}
+
+function validArticle(event: Event): boolean {
+	const identifier = tagValue(event, 'd');
+	return (
+		validSignedEvent(event) &&
+		event.kind === LongFormArticle &&
+		event.pubkey === ARTICLE_AUTHOR &&
+		Boolean(identifier && /^[A-Za-z0-9_-]+$/.test(identifier)) &&
+		Boolean(tagValue(event, 'title')) &&
+		Boolean(event.content.trim())
+	);
+}
+
+function validServer(event: Event, pubkey: string): boolean {
+	if (
+		!validSignedEvent(event) ||
+		event.kind !== SERVER_ANNOUNCEMENT_KIND ||
+		event.pubkey !== pubkey
+	) {
+		return false;
+	}
+
+	try {
+		const content = JSON.parse(event.content);
+		const initializeResult = 'result' in content ? content.result : content;
+		if (!InitializeResultSchema.safeParse(initializeResult).success) return false;
+	} catch {
+		return false;
+	}
+
+	return safeHttpUrl(tagValue(event, 'website')) && safeHttpUrl(tagValue(event, 'picture'));
+}
+
+function latestByIdentifier(events: Event[]): Event[] {
+	const latest = new Map<string, Event>();
+
+	for (const event of events) {
+		const identifier = tagValue(event, 'd');
+		if (!identifier || EXCLUDED_ARTICLE_IDENTIFIERS.includes(identifier)) continue;
+
+		const current = latest.get(identifier);
+		if (!current || event.created_at > current.created_at) latest.set(identifier, event);
+	}
+
+	return [...latest.values()].sort((a, b) => b.created_at - a.created_at);
+}
+
+async function readPreviousSnapshot(): Promise<SeoSnapshot> {
+	try {
+		return JSON.parse(await readFile(SNAPSHOT_PATH, 'utf8')) as SeoSnapshot;
+	} catch (error) {
+		throw new Error(
+			`Could not read the previous snapshot at ${SNAPSHOT_PATH.pathname} (restore it from git history if it was deleted): ${error}`
+		);
+	}
+}
+
+async function refresh() {
+	const previous = await readPreviousSnapshot();
+	const pool = new SimplePool();
+
+	try {
+		const articleEvents = await pool.querySync(
+			ARTICLE_RELAYS,
+			{ kinds: [LongFormArticle], authors: [ARTICLE_AUTHOR], limit: 500 },
+			{ maxWait: MAX_WAIT_MS }
+		);
+		const validArticles = articleEvents.filter(validArticle);
+
+		if (validArticles.length === 0) {
+			throw new Error('No valid ContextVM articles were returned; the previous snapshot was kept.');
+		}
+
+		const articles = latestByIdentifier([
+			...previous.articles.filter(validArticle),
+			...validArticles
+		]);
+		if (articles.length === 0) throw new Error('The article snapshot cannot be empty.');
+
+		const servers: ServerSnapshot[] = [];
+		for (const source of SERVER_SOURCES) {
+			const events = await pool.querySync(
+				source.relays.slice(),
+				{ kinds: [SERVER_ANNOUNCEMENT_KIND], authors: [source.pubkey] },
+				{ maxWait: MAX_WAIT_MS }
+			);
+			const current = events
+				.filter((event) => validServer(event, source.pubkey))
+				.sort((a, b) => b.created_at - a.created_at)[0];
+			const fallback = previous.servers.find(
+				(server) =>
+					server.event.pubkey === source.pubkey && validServer(server.event, source.pubkey)
+			);
+
+			if (!current && !fallback) {
+				throw new Error(`No valid announcement found for curated server ${source.pubkey}.`);
+			}
+
+			servers.push({ event: current ?? fallback!.event, relays: source.relays.slice() });
+		}
+
+		const snapshot: SeoSnapshot = {
+			schemaVersion: 1,
+			generatedAt: new Date().toISOString(),
+			articles,
+			servers
+		};
+		const output = `${JSON.stringify(snapshot, null, '\t')}\n`;
+		await writeFile(TEMP_PATH, output, 'utf8');
+		await rename(TEMP_PATH, SNAPSHOT_PATH);
+
+		console.log(
+			`Wrote ${articles.length} articles and ${servers.length} servers to the SEO snapshot.`
+		);
+	} finally {
+		pool.close([...ARTICLE_RELAYS, ...SERVER_SOURCES.flatMap((source) => source.relays)]);
+	}
+}
+
+await refresh();
diff --git a/scripts/seo-snapshot-sources.ts b/scripts/seo-snapshot-sources.ts
new file mode 100644
index 0000000..e1ae25a
--- /dev/null
+++ b/scripts/seo-snapshot-sources.ts
@@ -0,0 +1,27 @@
+export const ARTICLE_AUTHOR = '6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8';
+
+export const ARTICLE_RELAYS = [
+	'wss://relay.damus.io',
+	'wss://relay.nostr.net',
+	'wss://nos.lol',
+	'wss://nostr.mom'
+];
+
+// Removing an identifier here deliberately removes it from the next snapshot.
+export const EXCLUDED_ARTICLE_IDENTIFIERS: string[] = [];
+
+// This reviewed allowlist is the only source of prerendered server profiles.
+export const SERVER_SOURCES = [
+	{
+		pubkey: '65a334b02f5913cf2c1f73376044df11254166676e7d499d0c34e2ca10cf3e16',
+		relays: ['wss://relay.contextvm.org']
+	},
+	{
+		pubkey: '29bd6461f780c07b29c89b4df8017db90973d5608a3cd811a0522b15c1064f15',
+		relays: ['wss://nos.lol']
+	},
+	{
+		pubkey: 'e3564bb877adb0c99a7e4973ccb22e516d7d9eca0027d0bd62a04174ed670530',
+		relays: ['wss://relay.contextvm.org']
+	}
+] as const;
diff --git a/src/lib/components/SEO.svelte b/src/lib/components/SEO.svelte
index 0eb80c1..0b5cc05 100644
--- a/src/lib/components/SEO.svelte
+++ b/src/lib/components/SEO.svelte
@@ -1,9 +1,22 @@
 <script lang="ts">
-	import { asset } from '$app/paths';
-
+	import { asset, base } from '$app/paths';
 	import { page } from '$app/stores';
+	import { absoluteSiteUrl, canonicalUrl, SITE_ORIGIN } from '$lib/seo';
+
+	type StructuredData = Record<string, unknown>;
+
+	interface Props {
+		title?: string;
+		description?: string;
+		image?: string;
+		type?: 'website' | 'article';
+		siteName?: string;
+		locale?: string;
+		robots?: string;
+		canonicalPath?: string;
+		structuredData?: StructuredData[];
+	}
 
-	const defaultOgImageSrc = asset('/apple-touch-icon-180x180.png');
 	const favicon32Src = asset('/favicon-32x32.png');
 	const favicon16Src = asset('/favicon-16x16.png');
 	const appleTouchIconSrc = asset('/apple-touch-icon-180x180.png');
@@ -11,47 +24,72 @@
 	let {
 		title = 'ContextVM',
 		description = 'Discover and connect with Model Context Protocol (MCP) servers on Nostr.',
-		url = $page.url.href,
-		image = defaultOgImageSrc,
-		type = 'website' as 'website' | 'article',
+		image = '/apple-touch-icon-180x180.png',
+		type = 'website',
 		siteName = 'ContextVM',
-		locale = 'en_US'
-	} = $props();
+		locale = 'en_US',
+		robots = 'index, follow',
+		canonicalPath,
+		structuredData = []
+	}: Props = $props();
 
-	// Generate the full title by combining site name and page title
 	const fullTitle = $derived(
-		`${title || 'Untitled'} ${title === 'ContextVM' ? '' : `| ${siteName}`}`.trim()
+		`${title || 'Untitled'} ${title === siteName ? '' : `| ${siteName}`}`.trim()
+	);
+	const url = $derived(canonicalUrl(canonicalPath ?? $page.url.pathname, base));
+	const imageUrl = $derived(absoluteSiteUrl(image, base));
+	const jsonLd = $derived.by(() =>
+		JSON.stringify({
+			'@context': 'https://schema.org',
+			'@graph': [
+				{
+					'@type': 'Organization',
+					'@id': `${SITE_ORIGIN}/#organization`,
+					name: siteName,
+					url: `${SITE_ORIGIN}/`,
+					logo: {
+						'@type': 'ImageObject',
+						url: `${SITE_ORIGIN}/apple-touch-icon-180x180.png`
+					}
+				},
+				{
+					'@type': 'WebSite',
+					'@id': `${SITE_ORIGIN}/#website`,
+					name: siteName,
+					url: `${SITE_ORIGIN}/`,
+					publisher: { '@id': `${SITE_ORIGIN}/#organization` }
+				},
+				...structuredData
+			]
+		}).replace(/</g, '\\u003c')
 	);
 </script>
 
 <svelte:head>
 	<title>{fullTitle}</title>
 	<meta name="description" content={description} />
-	<meta name="viewport" content="width=device-width, initial-scale=1" />
 
-	<!-- Open Graph / Facebook -->
 	<meta property="og:type" content={type} />
 	<meta property="og:url" content={url} />
 	<meta property="og:title" content={fullTitle} />
 	<meta property="og:description" content={description} />
-	<meta property="og:image" content={image} />
+	<meta property="og:image" content={imageUrl} />
 	<meta property="og:site_name" content={siteName} />
 	<meta property="og:locale" content={locale} />
 
-	<!-- Twitter -->
-	<meta property="twitter:card" content="summary_large_image" />
-	<meta property="twitter:url" content={url} />
-	<meta property="twitter:title" content={fullTitle} />
-	<meta property="twitter:description" content={description} />
-	<meta property="twitter:image" content={image} />
+	<meta name="twitter:card" content="summary_large_image" />
+	<meta name="twitter:url" content={url} />
+	<meta name="twitter:title" content={fullTitle} />
+	<meta name="twitter:description" content={description} />
+	<meta name="twitter:image" content={imageUrl} />
 
-	<!-- Additional SEO meta tags -->
 	<meta name="author" content={siteName} />
-	<meta name="robots" content="index, follow" />
+	<meta name="robots" content={robots} />
 
-	<!-- Favicon references -->
 	<link rel="icon" href={favicon32Src} sizes="32x32" />
 	<link rel="icon" href={favicon16Src} sizes="16x16" />
 	<link rel="apple-touch-icon" href={appleTouchIconSrc} />
 	<link rel="canonical" href={url} />
+
+	{@html `<script type="application/ld+json">${jsonLd}<\/script>`}
 </svelte:head>
diff --git a/src/lib/components/landing/DualApiSection.svelte b/src/lib/components/landing/DualApiSection.svelte
index eb4cd28..c332abe 100644
--- a/src/lib/components/landing/DualApiSection.svelte
+++ b/src/lib/components/landing/DualApiSection.svelte
@@ -1,4 +1,5 @@
 <script lang="ts">
+	import { resolve } from '$app/paths';
 	import { Button } from '$lib/components/ui/button';
 </script>
 
@@ -57,7 +58,7 @@
 			<div class="mt-10 text-center">
 				<Button
 					variant="outline"
-					href="/blog/HeekLEB1p4rU61ngbuFrH"
+					href={resolve('/blog/HeekLEB1p4rU61ngbuFrH')}
 					class="transition-transform duration-200 hover:scale-105"
 				>
 					Discover CtxCN
diff --git a/src/lib/components/landing/ValuePropsSection.svelte b/src/lib/components/landing/ValuePropsSection.svelte
index dd6e11e..86d4a59 100644
--- a/src/lib/components/landing/ValuePropsSection.svelte
+++ b/src/lib/components/landing/ValuePropsSection.svelte
@@ -1,4 +1,5 @@
 <script lang="ts">
+	import { resolve } from '$app/paths';
 	import { Button } from '$lib/components/ui/button';
 	import {
 		CheckCircle,
@@ -145,7 +146,7 @@
 			<div class="mt-10 text-center">
 				<Button
 					variant="outline"
-					href="/faqs"
+					href={resolve('/faqs')}
 					class="transition-transform duration-200 hover:scale-105"
 				>
 					Find more answers in our FAQs
diff --git a/src/lib/content/seo-snapshot.json b/src/lib/content/seo-snapshot.json
new file mode 100644
index 0000000..270559e
--- /dev/null
+++ b/src/lib/content/seo-snapshot.json
@@ -0,0 +1,1086 @@
+{
+	"schemaVersion": 1,
+	"generatedAt": "2026-09-29T07:47:06.581Z",
+	"articles": [
+		{
+			"content": "*GM people, and welcome to the 12th issue of \"The ContextVM World 🌍\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and everything in between!*\n\n*In today's update, we cover the latest news from ContextVM. In particular, we discuss the latest release of the Rust SDK, bringing it closer to feature parity with the TS one.*\n\n*We also discuss the latest news from the ecosystem. In particular, we cover the latest release of Cordn, which brings encrypted media into the MLS-based chat.*\n\n*Additionally, we cover the features we are currently working on. Notably, the team is working on integrating the latest developments to CVMI, and reaching feature parity between the Rust and TS SDKs.*\n\n*Finally, we will share articles, blogs, and posts talking about CVM and the most interesting news from the internet regarding the MCP ecosystem, AI agents, and more!*\n\n*This will be the last episode of \"The ContextVM World 🌍\" before summer holidays. We'll be back in September! Enjoy your vacations!*\n\n*Let's start!*\n\n---\n\n## **News from ContextVM** 📰\n\n*A list of updates, releases, and new cool features.*\n\n- **Rust SDK**: We recently published a **new version of our Rust SDK**, [v0.2.0](https://github.com/ContextVM/rs-sdk/blob/main/CHANGELOG.md#020---2026-06-24). This release marks a huge step towards feature parity with the TS SDK, integrating the following CEPs:\n    - [CEP-22](https://docs.contextvm.org/reference/ceps/cep-22/) for oversized transfers;\n    - [CEP-41](https://docs.contextvm.org/reference/ceps/cep-41/) for open-ended streams;\n    - [CEP-17](https://docs.contextvm.org/reference/ceps/cep-17/) for smarter relay resolution;\n    - [CEP-6](https://docs.contextvm.org/reference/ceps/cep-6/) for server announcements;\n    - [CEP-23](https://docs.contextvm.org/reference/ceps/cep-23/) for profile metadata and social communications.\n\n    v0.2.0 also comes with [UniFFI bindings](https://github.com/ContextVM/rs-sdk/tree/main/contextvm-ffi), providing support for Python, Swift, Kotlin, and C/C++!\n\n---\n\n## **News from the ContextVM Ecosystem** 🗞️\n\n*Find all the projects leveraging ContextVM on [ContextVM/awesome](https://github.com/ContextVM/awesome).*\n\n- **Encrypted media**: Besao recently [announced](https://nostr.at/nostr:nevent1qvzqqqqqqypzqpswpcf4m0t4d2qtnp5jeypy3d5x6e24smp3389wgdgt9rf8a697qy0hwumn8ghj7um9v9exx6pwdehhxarjv9exx6rfwejhxtnrdakj7qpqr02yxhe0pha05ew3t456na0tnhx4lyhcc7muemyqeq6veadr9m4qu70g8d) that the latest release of Cordn, the MLS-based protocol that leverages CVM for group coordination, added support for sharing **end-to-end encrypted files and media**. This feature comes with a new specification, defining how to encrypt and decrypt media for a chat. In the same release, support has also been added for **pinned messages**.\n\n---\n\n## **What’s Next for ContextVM?** ⏭️\n\n*Let’s take a look at the features currently being implemented! Check out our [Roadmap](https://github.com/orgs/ContextVM/projects/1) to always be up-to-date with the latest developments!*\n\n- Our team is currently working on bringing the latest developments to CVMI. In particular, we are adding support for [MCPB bundling](https://github.com/ContextVM/cvmi/pull/4) and [CEP-8 explicit payment gating](https://github.com/ContextVM/cvmi/pull/5).\n\n- Moreover, the effort to reach feature parity between Rust and TS SDKs is ongoing. Check out [IS64](https://github.com/ContextVM/rs-sdk/issues/64) to keep track of the progress!\n\n---\n\n## **Who is Talking about ContextVM?** 📢\n\n*A curated list of articles, blog posts, and notes about ContextVM and its ecosystem.*\n\n-   [Gzuuus](https://nostr.at/nostr:npub1gzuushllat7pet0ccv9yuhygvc8ldeyhrgxuwg744dn5khnpk3gs3ea5ds) recently updated his blog post [*Private Communications Over Public Infrastructure*](https://nostr.at/nostr:naddr1qvzqqqr4gupzqs9eep0ll6hurjkl3sc2fewgses07mjfwxsdcu3at2m8fd0xrdz3qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqx9c8y6tkv96x2ttrdakk6atwd93kzarfdah8xtt0wejhyttsw43xc6tr945kuenjv9ehgun4vd682un96xymg3) adding a paragraph specifically about [Cordn](https://cordn.net/).\n\n    *P.S. Some clients may not show the updated article!*\n\n- CVM has been mentioned on [Nostr Compass #28](https://nostr.at/nostr:naddr1qvzqqqr4gupzqa6e2nmnzsgjfzdy520vdy4hywr06c9ue6crpr2zxyq749uu275qqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qqxkuethwdkx2ar5v4ez6v3cqcafrq) and [Nostr Compass #29](https://nostr.at/nostr:naddr1qvzqqqr4gupzqa6e2nmnzsgjfzdy520vdy4hywr06c9ue6crpr2zxyq749uu275qqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qqxkuethwdkx2ar5v4ez6v3eawfu7j), a weekly newsletter covering everything going on in the Nostr ecosystem. Specifically, the article provides information on [cordn-adhoc](https://github.com/sandwichfarm/cordn-adhoc-cvm) and updates to some of the CVM components.\n\n---\n\n## **Interesting resources from the web** 🤖\n\n*A curated list of resources we found interesting.*\n\n- [*Our interest in AI slop is hitting a ceiling*](https://www.fastcompany.com/91568818/our-interest-in-ai-slop-is-hitting-a-ceiling): A new analysis on how the creator economy is now submerged by AI slop, and how people are reacting to it.\n\n- [*Hidden Web Prompts Trick AI Agents Into Sending Money*](https://securityaffairs.com/194822/ai/hidden-web-prompts-trick-ai-agents-into-sending-money.html): An interesting article that shows how hidden, malicious prompts on websites can trick AI agents into sending payments.\n\n- [*Researchers Create Self-Replicating Seedbox in Quest for Decentralized Democracy*](https://torrentfreak.com/researchers-create-self-replicating-seedbox-in-quest-for-decentralized-democracy/): An article on the \"superorganism experiment\" run by researchers from Delft University, which aims to decentralize digital democracy through Bitcoin, AI, and BitTorrent.\n\n- [*Does Code Cleanliness Affect Coding Agents? A Controlled Minimal-Pair Study*](https://arxiv.org/abs/2605.20049): A scientific paper digging into how code cleanliness can affect coding agents, from code quality to operational footprint (spoiler, the cleaner your code, the fewer tokens you spend!).\n\n---\n\n*Find out more about ContextVM:*\n\n- *Check out our [website](https://contextvm.org/) for documentation, blog posts, and more.*\n- *Join our [Signal](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR) group*\n- *Follow ContextVM on [Nostr](https://jumble.social/users/nostr:npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm)*\n- *Subscribe to our [Substack](https://contextvm.substack.com/). Help us spread the word!*\n- *Check out our GitHub [repositories](https://github.com/contextvm) and leave us a ⭐*",
+			"created_at": 1783526013,
+			"id": "b0b073ad90b43d28e762e4b5ed6ada15f280b90c191913c3470b1263a70571f1",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "03953d3f5cf2aa78556a1c54a0cbeafa0f99251b6a4c2f98ee8d13a6dc14a82ad0299a40d83a1f895cbb4c52ec6b1c94694e23180fc50492b0d9fa1fad48223f",
+			"tags": [
+				["d", "mrc9bcgjga9q6vz703q"],
+				["title", "Encrypted Media — The ContextVM World #12"],
+				[
+					"summary",
+					"In today's update, we cover the latest news from ContextVM. In particular, we discuss the latest release of the Rust SDK, bringing it closer to feature parity with the TS one."
+				],
+				[
+					"image",
+					"https://npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm.blossom.band/0b00f603a31d551a0cfbae64a0c2b51291441e2463543de59a099fd01889ba98.jpg"
+				],
+				["published_at", "1783526013"],
+				[
+					"e",
+					"1bd4435f2f0dfafa65d15d69a9f5eb9dcd5f92f8c7b7ccec80c834ccf5a32eea",
+					"wss://search.nostrarchives.com/",
+					"",
+					"060e0e135dbd756a80b98692c90248b686d655586c3189cae4350b28d27ee8be"
+				],
+				["p", "060e0e135dbd756a80b98692c90248b686d655586c3189cae4350b28d27ee8be", ""],
+				["p", "40b9c85fffeafc1cadf8c30a4e5c88660ff6e4971a0dc723d5ab674b5e61b451", ""],
+				[
+					"a",
+					"30023:40b9c85fffeafc1cadf8c30a4e5c88660ff6e4971a0dc723d5ab674b5e61b451:private-communications-over-public-infrastructure",
+					"wss://nos.lol/"
+				],
+				[
+					"a",
+					"30023:775954f7314112489a4a29ec692b72386fd60bcceb0308d423101ea979c57a80:newsletter-28",
+					"wss://search.nos.today/"
+				],
+				[
+					"a",
+					"30023:775954f7314112489a4a29ec692b72386fd60bcceb0308d423101ea979c57a80:newsletter-29",
+					"wss://search.nos.today/"
+				],
+				["p", "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8", ""],
+				["client", "nostria"]
+			]
+		},
+		{
+			"content": "*GM people, and welcome to the 11th issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and everything in between!*\n\n*In today's update, we cover the latest news from ContextVM. In particular, we discuss our first contribution to the upstream MCP repository, how we are trying to reduce the amount of dependencies in our SDK, our brand new documentation pages, and a new Explicit Payment Gating mode for CEP-8 that lets AI agents decide whether a call is worth paying for.*\n\n*We also cover the features we are currently working on. Notably, the team is looking into MCP Bundles (MCPB), a way to package and deploy local MCP servers.*\n\n*Finally, we will share articles, blogs, and posts talking about CVM and the most interesting news from the internet regarding the MCP ecosystem, AI agents, and more!*\n\n*Let's start!*\n\n---\n\n## **News from ContextVM** 📰\n\n*A list of updates, releases and new cool features.*\n\n- **Contributing Upstream**: We recently shipped an improvement to the official MCP rust-sdk repository! [PR858](https://github.com/modelcontextprotocol/rust-sdk/pull/858) was merged last week, bringing our experience as users to our major upstream dependency. The benefits of FOSS at work!\n\n    This PR adds support for resetting a request timeout in case a long-running operation is ongoing. Previously, the SDK would make no difference between an offline peer which was not responding, and one that was just actively progressing to conclude a task. Our work refreshes the request timeout anytime the peer sends some progress, signaling that it is still busy and not offline.\n\n- **Fewer dependencies**: We published a new release family, v0.12.x. We decided to fork the official [MCP ts-sdk](https://github.com/modelcontextprotocol/typescript-sdk) and to strip out all those parts that are not needed in our project. What does this mean? Fewer unnecessary dependencies to the benefit of lightweight and web clients! Check out our [fork](https://github.com/ContextVM/mcp-sdk/tree/v1.x)!\n\n    We then released new versions up to [v0.12.3](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#0123). We introduced progress notifications to avoid timeouts for oversized transfers, we fixed a conflict between progress tokens and open streams, and we improved handling of encryption size limits.\n\n- **Explicit Payment Gating for CEP-8**: We just released [ContextVM SDK 0.13.0](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#0130), shipping full support for a new CEP-8 mode called Explicit Payment Gating. Until now, CEP-8 let servers charge for their tools, but only \"behind the scenes\", with payment handled silently by the transport layer. That is great for a wallet app, but not for an AI agent that actually needs to decide whether a call is worth paying for. With this update, a paid call returns a clean \"Payment Required\" error (`-32042`) that carries human-readable instructions and one or more payment options, inspired by HTTP's 402 status code. The agent reads the instructions, pays the invoice its own way, and retries the same call, with no special SDK knowledge required. The change is fully backward compatible, as the existing silent flow stays the default. Check out the [announcement](https://nostr.at/nostr:nevent1qvzqqqqqqypzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qpqzxteeuj9fu25cphayjpp03yh7cqvm0qcajl0kvda28l0ttegvtpqp9xzmm), the [CEP-8 spec](https://docs.contextvm.org/reference/ceps/cep-8/), and the [explicit gating guide](https://docs.contextvm.org/how-to/payments/explicit-gating/) to learn more!\n\n- **Diátaxis**: We also worked on improving how [our documentation](https://docs.contextvm.org/) is structured. We decided to follow [diátaxis](https://diataxis.fr/), a systematic approach to technical documentation authoring, with the aim to provide more clarity for our users. Moreover, we added comprehensive documentation for our Rust SDK.\n\n- **Bindings are here**: We finally merged bindings in our Rust SDK! In particular, the new contextvm-ffi crate is exposing bindings to C, Python, Kotlin, and Swift, bringing CVM functionalities to mobile development. \n\n---\n\n## News from the ContextVM Ecosystem 🗞️\n\n*Find all the projects leveraging ContextVM on [ContextVM/awesome](https://github.com/ContextVM/awesome).*\n\n- **MLS coordinator in the browser**: Open-source contributor sandwich developed a new MLS coordinator that runs directly in a browser tab, no need for a server to run it. An ephemeral coordinator that exist only for as long as it is needed. Check out this [note](https://nostr.at/nostr:nevent1qqsqqqqswpwuvg9my8f586jq7kdcnng7mrt83qld4yquy20j6x3j09qpp4mhxue69uhkummn9ekx7mqzypqtnjzlll40c89dlrps5nju3pnqlahyjudqm3er6k4kwj67vx69zvzcrjh) to know more!\n\n---\n\n## **What’s Next for ContextVM?** ⏭️\n\n*Let’s take a look at the features currently being implemented! Check out our [Roadmap](https://github.com/orgs/ContextVM/projects/1) to always be up-to-date with the latest developments!*\n\n- Our team is currently looking into [MCP Bundles](https://github.com/modelcontextprotocol/mcpb) (MCPB), a packaging format to easily distribute local MCP servers and provide one-click deployment. The team is currently implementing [a new command into CVMI](https://github.com/ContextVM/cvmi/pull/4) to enable developers to package local MCP servers into distributable bundles.\n\n---\n\n## **Who is Talking about ContextVM?** 📢\n\n*A curated list of articles, blog posts, and notes about ContextVM and its ecosystem.*\n\n- CVM has been mentioned on [Nostr Compass #27](https://nostr.at/nostr:naddr1qvzqqqr4gupzqa6e2nmnzsgjfzdy520vdy4hywr06c9ue6crpr2zxyq749uu275qqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qqxkuethwdkx2ar5v4ez6v3hl4w4uc), a weekly newsletter covering everything going on in the Nostr ecosystem. Specifically, the article provides information on our latests SDK release.\n\n- We recently published a [demo](https://nostr.at/nostr:nevent1qvzqqqqqqypzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qpqsvz0vz4g3ghvx6vttut462swy5v50dk5c5qv6gketrathnejfhcqsqa0cr) on how to use our new LLM chat interface as a music research tool, by leveraging the [WaveFunc](https://contextvm.org/s/bb0707242a17a4be881919b3dcfea63f42aacedc3ff898a66be30af195ff32b2) MCP server. Try it out for yourself!\n\n- [aljaz](https://github.com/aljazceru) shared a new experiment born out of a hackathon: [kvaq](https://github.com/aljazceru/kvaq), bringing local inference to mobile with ContextVM support for tool use and discovery. See the [note](https://nostr.at/nostr:nevent1qvzqqqqqqypzpml96ysd7rxzjra8fpe8ldz6cjru4tf5d48j9yatq60g7q0u2xvpqythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qy88wumn8ghj7mn0wvhxcmmv9uqzpus0k3hgztj0qvdvqjkr4nr0cu8vvuw4fy866f696npdx085c0k44htjgh)!\n\n- [SkateSpots](https://nostr.at/nostr:npub1yrnuj56rnen08zp2h9h7p74ghgjx6ma39spmpj6w9hzxywutevsst7k5cx) built Sasquatch, a bot powered by CVM that helps you find skate spots. Check out the [note](https://nostr.at/nostr:nevent1qvzqqqqqqypzqg88e9f588nx7wyz4wt0ura23w3yd4hmztqrkr95utwyvgachjepqythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qpqf6dv43vrjyfaxd5u87jw622x556n0nxpyp8f6xnvpp7vseqzdgjsgdlu7w)!\n\n---\n\n## **Interesting resources from the web** 🤖\n\n*A curated list of resources we found interesting.*\n\n- [\"What AI Can Never Be\"](https://www.youtube.com/watch?v=HAJclcj25uM): A great talk by John Vervaeke discussing intelligence and what AI can never be.\n\n---\n\n*Find out more about ContextVM:*\n\n- *Check out our [website](https://contextvm.org/) for documentation, blog posts, and more.*\n- *Join our [Signal](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR) group*\n- *Follow ContextVM on [Nostr](https://jumble.social/users/nostr:npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm)*\n- *Subscribe to our [Substack](https://contextvm.substack.com/). Help us spread the word!*\n- *Check out our GitHub [repositories](https://github.com/contextvm) and leave us a ⭐*",
+			"created_at": 1782310760,
+			"id": "65371dd0321bde8e531ce562733c662511e685e3c946bb1cc43814a1004455a7",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "b7c0d7cc61d930d7545ea960fe241f0aebfdd762940698e65e9a8d82a7790c61b5698c5ac592b7c3fe00428b6c647cd5505cdac23bf5142615757f5d975ed3f2",
+			"tags": [
+				["d", "cvmw-11"],
+				["title", "The Benefits of FOSS — The ContextVM World #11 🌍"],
+				[
+					"summary",
+					"In today's update, we cover the latest news from ContextVM. In particular, we discuss our first contribution to the upstream MCP repository, how we are trying to reduce the amount of dependencies in our SDK, our brand new documentation pages, and a new Explicit Payment Gating mode for CEP-8 that lets AI agents decide whether a call is worth paying for."
+				],
+				[
+					"image",
+					"https://npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm.blossom.band/e16eabb586379eeb5df4a447d82aa14ba306b94a6df4a1d04b4e6125a8ce6f97.jpg"
+				],
+				["published_at", "1782310721"],
+				["t", "cvm"],
+				["t", "dvm"],
+				["t", "llm"],
+				["t", "rust"],
+				["t", "mls"],
+				["t", "agents"],
+				["t", "ai"],
+				[
+					"e",
+					"11979cf2454f154c06fd248217c497f600cdbc18ecbefb31bd51fef5af2862c2",
+					"wss://relay.primal.net/",
+					"",
+					"6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8"
+				],
+				["p", "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8", ""],
+				[
+					"e",
+					"000010705dc620bb21d343ea40f59b89cd1ed8d67883eda901c229f2d1a32794",
+					"wss://nos.lol",
+					"",
+					"40b9c85fffeafc1cadf8c30a4e5c88660ff6e4971a0dc723d5ab674b5e61b451"
+				],
+				["p", "40b9c85fffeafc1cadf8c30a4e5c88660ff6e4971a0dc723d5ab674b5e61b451", ""],
+				[
+					"a",
+					"30023:775954f7314112489a4a29ec692b72386fd60bcceb0308d423101ea979c57a80:newsletter-27",
+					"wss://search.nos.today/"
+				],
+				[
+					"e",
+					"8304f60aa88a2ec3698b5f175d2a0e251947b6d4c500cd22d958fabbcf324df0",
+					"wss://relay.primal.net/",
+					"",
+					"6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8"
+				],
+				[
+					"e",
+					"f20fb46e812e4f031ac04ac3acc6fc70ec671d5490fad2745d4c2d33cf4c3ed5",
+					"wss://relay.primal.net/",
+					"",
+					"efe5d120df0cc290fa748727fb45ac487caad346d4f2293ab069e8f01fc51981"
+				],
+				["p", "efe5d120df0cc290fa748727fb45ac487caad346d4f2293ab069e8f01fc51981", ""],
+				["p", "20e7c953439e66f3882ab96fe0faa8ba246d6fb12c03b0cb4e2dc4623b8bcb21", ""],
+				[
+					"e",
+					"4e9acac5839113d3369c3fa4ed2946a53537ccc1204e9d1a6c087cc864026a25",
+					"wss://relay.primal.net/",
+					"",
+					"20e7c953439e66f3882ab96fe0faa8ba246d6fb12c03b0cb4e2dc4623b8bcb21"
+				],
+				["client", "nostria"]
+			]
+		},
+		{
+			"content": "*GM people, and welcome to the 10th issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and everything in between!*\n\n*In today's update, we cover the latest news from ContextVM. In particular, we discuss the ongoing effort to expose the functionalities of CVM to other programming ecosystems through bindings in our Rust SDK. We also highlight the recent merge of ephemeral gift wraps in NIP-59, and two powerful additions to our website.*\n\n*We also discuss the latest news from the ecosystem. In particular, we cover Spectr, a multi-column deck for Nostr, integrating Relatr and CVM.*\n\n*We also show the features we are currently working on. Notably, our team is working on improving CEP-8, which specifies how payments should work for CVM.*\n\n*Finally, we will share articles, blogs, and posts talking about CVM and the most interesting news from the internet regarding the MCP ecosystem, AI agents, and more!*\n\n*Let's start!*\n\n---\n\n## **News from ContextVM** 📰\n\n*A list of updates, releases and new cool features.*\n\n- **Agentic website**: We recently made a huge update to our website, which now includes a chat interface for working with LLMs. This chat connects directly to MCP servers exposed through CVM, making it one of the most comprehensive demos of what CVM enables. Check out this [note](https://nostr.at/nostr:nevent1qvzqqqqqqypzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qpqrsdd2mz7r0h260f069pz0u9cxu83v6sjcq2yx442fv9us650qeesp6mre6) to see what the new website is capable of!\n\n- **Bindings are coming**: A Rust project is never complete, unless bindings are created to expose its functionalities to other ecosystems. That's why [aljazceru](https://github.com/aljazceru) is [adding bindings](https://github.com/ContextVM/rs-sdk/pull/84) to our Rust SDK. In particular, the new `contextvm-ffi` crate is exposing bindings to C, Python, Kotlin, and Swift, promising to bring CVM functionalities to mobile development.\n\n- **CVM improving Nostr**: Some months ago we opened a [PR](https://github.com/nostr-protocol/nips/pull/2245) in the Nostr Implementation Possibilities (NIP) repository. The PR has at last been merged, expanding [NIP-59](https://github.com/nostr-protocol/nips/blob/master/59.md) to include a new `kind` for ephemeral gift wraps, a type already implemented in CVM. The work we are doing is benefitting the whole ecosystem!\n\n- **CEP-15 is now in our website**: [CEP‑15](https://docs.contextvm.org/spec/ceps/cep-15/) (Common Tool Schemas) has been merged into our [website](https://contextvm.org/servers). This allows servers to define their categories and common tool hashes so they can be discovered and grouped accordingly. The result is a marketplace‑style UX where multiple servers can expose the same tools or use the same categories. Server operators can position their services within these common categories or tools, and users can navigate the marketplace to find the services that best suit their needs.\n\n---\n\n## **News from the ContextVM Ecosystem** 🗞️\n\n*Find all the projects leveraging ContextVM on [ContextVM/awesome](https://github.com/ContextVM/awesome).*\n\n- **Spectr <> Relatr**: [Spectr](https://spectr.clave.casa/), a multi-column deck for Nostr, recently integrated Relatr and CVM. The new feature allows a user to check the trust score of any `npub`. Check out this [video](https://jumble.social/notes/nostr:nevent1qvzqqqqqqypzqvff2z0z85axzf0pg5d9jykmuqgfnc23wfkywe45fc0vhryydagxqy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyp0d2sdeeeg06uhlxs66ekylk580fcwr0s7j8mq5g3vrvfk94lv27rjzf2e) to see how it works!\n\n---\n\n## **What’s Next for ContextVM?** ⏭️\n\n*Let’s take a look at the features currently being implemented! Check out our [Roadmap](https://github.com/orgs/ContextVM/projects/1) to always be up-to-date with the latest developments!*\n\n- The team is working to update [CEP-8](https://docs.contextvm.org/spec/ceps/cep-8/), which specifies how payments should work for CVM, to add a new lifecycle based on explicit errors. This modification to the protocol, currently ongoing in [PR44](https://github.com/ContextVM/contextvm-docs/pull/44), would allow working with 402-like approaches.\n\n---\n\n## **Who is Talking about ContextVM?** 📢\n\n*A curated list of articles, blog posts, and notes about ContextVM and its ecosystem.*\n\n- CVM has been mentioned on [Nostr Compass #24](https://primal.net/a/nostr:naddr1qvzqqqr4gupzqa6e2nmnzsgjfzdy520vdy4hywr06c9ue6crpr2zxyq749uu275qqyt8wumn8ghj7un9d3shjtnyd968gmewwp6kytcpzamhxue69uhhxetpwf3kstnwdaejuar0v3shjtcqzqmnvenp893nvctyv5ukxdenvcmqlvdyfa), a weekly newsletter covering everything going on in the Nostr ecosystem. Specifically, the article discusses the role of CVM in [Cordn](https://cordn.net/).\n\n- [Khushvendra](https://primal.net/p/nostr:nprofile1qqsrsnzurjcg64ujnts4jpe0f7ymw93hzvpru4uthye25w8n7h5vh4qfr633u), one of our selected students from Summer of Bitcoin, published an interesting [post](https://www.linkedin.com/posts/khushvendra-singh-64827420a_ive-been-spending-a-lot-of-time-lately-digging-activity-7467463568272060416-KMu6) on LinkedIn about Nostr, CVM, and MCP servers, highlighting the powerful properties of these protocols. Thank you for bringing CVM outside the borders of Bitcoin and Nostr!\n\n---\n\n## **Interesting resources from the web** 🤖\n\n*A curated list of resources we found interesting.*\n\n- [\"Trust-me-bro in TEE\"](https://nostr.at/nostr:nevent1qqs8juuqdq69r7rnhxwkqdm079jkza5gayqf6mf28hkea4slzmvn9uqzyrh7t5fqmuxv9y86wjrj076943y8e2kngm20y2f6kp573uqlc5vczx74wcp): An interesting note by Aljaz about verifying TEE claims.\n\n- [\"Miasma npm Supply Chain Attack: Self-Spreading Worm via Phantom Gyp\"](https://www.stepsecurity.io/blog/binding-gyp-npm-supply-chain-attack-spreads-like-worm): npm supply chain attacks are becoming more and more common. Here is the report on the latest one.\n---\n\n*Find out more about ContextVM:*\n\n- *Check out our [website](https://contextvm.org/) for documentation, blog posts, and more.*\n- *Join our [Signal](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR) group*\n- *Follow ContextVM on [Nostr](https://jumble.social/users/nostr:npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm)*\n- *Subscribe to our [Substack](https://contextvm.substack.com/). Help us spread the word!*\n- *Check out our GitHub [repositories](https://github.com/contextvm) and leave us a ⭐*",
+			"created_at": 1781013815,
+			"id": "bfeee74e7978764b7b4408726b434d7db2ff66e00e6fa151719f63d5b7529c23",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "3ee3b42296ddafc92e7164f7abbc553ab80040d305ea11708b701647d824316e174ce7ed60105d699760b238854ba8cd6b922317f8321fc42f485a31ec520b64",
+			"tags": [
+				["d", "cvmw-10"],
+				["title", "Agentic Web — The ContextVM World #10"],
+				[
+					"summary",
+					"In today's update, we cover the latest news from ContextVM. In particular, we discuss the ongoing effort to expose the functionalities of CVM to other programming ecosystems through bindings in our Rust SDK. We also highlight the recent merge of ephemeral gift wraps in NIP-59, and two powerful additions to our website."
+				],
+				[
+					"image",
+					"https://mibo.nostria.app/ad8029c1079b8767ec226ab6d1166342934c52d1e5a7d119f2c0120768323816.webp"
+				],
+				["published_at", "1781013815"],
+				["t", "cvm"],
+				["t", "mcp"],
+				["t", "agents"],
+				["t", "llm"],
+				["t", "web"],
+				["t", "agentic"],
+				[
+					"e",
+					"1c1ad56c5e1beead3d2fd14227f0b8370f166a12c0144356aa4b0bc86a8f0673",
+					"wss://relay.primal.net/",
+					"",
+					"6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8"
+				],
+				["p", "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8", ""],
+				[
+					"e",
+					"5ed541b9ce50fd72ff3435acd89fb50ef4e1c37c3d23ec1444583626c5afd8af",
+					"wss://nos.lol/",
+					"",
+					"3129509e23d3a6125e1451a5912dbe01099e151726c4766b44e1ecb8c846f506"
+				],
+				["p", "3129509e23d3a6125e1451a5912dbe01099e151726c4766b44e1ecb8c846f506", ""],
+				[
+					"a",
+					"30023:775954f7314112489a4a29ec692b72386fd60bcceb0308d423101ea979c57a80:76fa9c6ade9c73f6",
+					"wss://relay.ditto.pub/"
+				],
+				["p", "384c5c1cb08d57929ae159072f4f89b7163713023e578bb932aa38f3f5e8cbd4", ""],
+				[
+					"e",
+					"797380683451f873b99d60376ff165617688e9009d6d2a3ded9ed61f16d932f0",
+					"",
+					"",
+					"efe5d120df0cc290fa748727fb45ac487caad346d4f2293ab069e8f01fc51981"
+				],
+				["p", "efe5d120df0cc290fa748727fb45ac487caad346d4f2293ab069e8f01fc51981", ""],
+				["client", "nostria"]
+			]
+		},
+		{
+			"content": "*GM people, and welcome to the 9th issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and everything in between!*\n\nIn today's update, we cover the latest news from ContextVM. In particular, we present the finalists that will take part in the Summer of Bitcoin program during the next months, and discuss the latest release of our SDK.*\n\n*We also discuss the latest news from the ecosystem. A new MLS implementation has recently been published, and it uses CVM as its coordination layer.*\n\n*We also show the features we are currently working on. Notably, our team is focused on reaching feature parity between the Rust and TypeScript SDKs.*\n\n*Finally, we will share the most interesting news from the internet regarding the MCP ecosystem, AI agents, and more!*\n\n*Let's start!*\n\n---\n\n## **News from ContextVM** 📰\n\n*A list of updates, releases and new cool features.*\n\n- **Finalists**: We selected the best students from the Summer of Bitcoin program. These students will spend the summer working on CVM, learning the ways of open-source development. Here are our finalists:\n    - [Harsh](https://primal.net/p/nostr:nprofile1qqstfkaf4k54fs6hcuu03ua9nr7j5q324kkg7zpqgze59c4pfp74xncvwyshd), who pushed the implementation of the Rust SDK.\n    - [Abhay](https://primal.net/p/nostr:nprofile1qqsqyze4twh4ajf845q4jrpvku6vlqnamlkmeycpfv6afxxzq4rvc5sv96sww), who pushed the work on [CEP-15](https://docs.contextvm.org/spec/ceps/cep-15/) for common tool schemas.\n    - [Khushvendra](https://primal.net/p/nostr:nprofile1qqsrsnzurjcg64ujnts4jpe0f7ymw93hzvpru4uthye25w8n7h5vh4qfr633u), who worked on the TypeScript SDK and [CEP-22](https://docs.contextvm.org/spec/ceps/cep-22/) for oversize payload transfer. He also had the time to do some maintenance work.\n\n    Congrats to our new interns!\n\n- **Updated SDK**: We recently released new versions of our TypeScript SDK belonging to the v0.11.x family. Notably, version .10 added support for category tags for CEP-15 tools schema. Another patch version, .11, was released to add client-side event deduplication and improve error handling for open-streams ([CEP-41](https://docs.contextvm.org/spec/ceps/cep-41/)).\n\n---\n\n## **News from the ContextVM Ecosystem** 🗞️\n\n*Find all the projects leveraging ContextVM on [ContextVM/awesome](https://github.com/ContextVM/awesome).*\n\n- **Coordinated MLS**: [Cordn](https://cordn.net/) is a new MLS-based protocol that uses CVM in an innovative way, relying on it as deployment and transport layer. Cordn introduces a coordinator, whose task is to provide strong message ordering, fetch semantics, and delivery for proposals, commits, welcomes, and application messages. Leveraging CVM makes self-hosting in ordinary environments (like your home network) easier, facilitates portability, and improves traffic privacy. Check out the [Cordn repository](https://github.com/Cordn-msg/cordn), [find out more](https://cordn.net/why/) about its trade-offs with respect to other MLS-based implementations, and join Cordn to be invited to our CVM group!\n\n- **Better search**: Relatr recently published [v0.2.9](https://github.com/ContextVM/relatr/blob/master/CHANGELOG.md#029). The latest release introduces significant improvements to search functionality by developing a new algorithm, making profile searches more relevant to the actual query. It is important to note that this is a breaking change with respect to previous versions, and result ordering may be different.\n\n---\n\n## **What’s Next for ContextVM?** ⏭️\n\n*Let’s take a look at the features currently being implemented! Check out our [Roadmap](https://github.com/orgs/ContextVM/projects/1) to always be up-to-date with the latest developments!*\n\n- The work to reach feature parity between the Rust SDK and the TypeScript one is progressing steadily. The team is currently focusing on integrating [CEP-17](https://docs.contextvm.org/spec/ceps/cep-17/), for server relay list metadata, and CEP-22, for oversize payload transfer. You can take a look at [IS64](https://github.com/ContextVM/rs-sdk/issues/64) to keep track of the progress.\n\n- The team is working to update [CEP-8](https://docs.contextvm.org/spec/ceps/cep-8/), which specifies how payments should work for CVM, to add a new lifecycle based on explicit errors. This modification would allow to work with 402-like approaches.\n\n---\n\n## **Who is Talking about ContextVM?** 📢\n\n*A curated list of articles, blog posts, and notes about ContextVM and its ecosystem.*\n\n- OpenSats recently listed CVM in their project showcase. Check it out [here](https://opensats.org/projects/contextvm)!\n\n---\n\n## **Interesting resources from the web** 🤖\n\n*A curated list of resources we found interesting.*\n\n- [*Dont Outsource the Learning*](https://x.com/addyosmani/status/2056078124346228860): An interesting article discussing why you should slow down and take the time to understand what AI is doing on your behalf.\n\n- [*Token price index*](https://tokenpriceindex.com/): A useful tool for AI economics, featuring real-time token cost benchmarking, model performance tracking, and granular spend simulation.\n\n---\n\n*Find out more about ContextVM:*\n\n- *Check out our [website](https://contextvm.org/) for documentation, blog posts, and more.*\n- *Join our [Signal](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR) group*\n- *Follow ContextVM on [Nostr](https://jumble.social/users/nostr:npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm)*\n- *Subscribe to our [Substack](https://contextvm.substack.com/). Help us spread the word!*\n- *Check out our GitHub [repositories](https://github.com/contextvm) and leave us a ⭐*",
+			"created_at": 1779891048,
+			"id": "1957906efe6123589063b2cd0a37fcbd13c83de86ec553aa41decdf9a76b1154",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "574a509b7623334efc9f92ea3030ff4eed30a30ee27292c1d1640b7a08bda3638a52eca592e057540f5596f53d89fa46a404ffe6fea6adaacca41ff5d0f65576",
+			"tags": [
+				["d", "cvmw-9"],
+				["title", "Coordinated MLS — The ContextVM World #9"],
+				[
+					"summary",
+					"In today's update, we cover the latest news from ContextVM. In particular, we present the finalists that will take part in the Summer of Bitcoin program during the next months, and discuss the latest release of our SDK."
+				],
+				[
+					"image",
+					"https://mibo.nostria.app/950a27698fd4326b8c151ab03c2dc13336da64230a1c38ea9c141119b0d9f2e1.webp"
+				],
+				["published_at", "1779891048"],
+				["t", "cvm"],
+				["t", "dvm"],
+				["t", "mls"],
+				["t", "sdk"],
+				["t", "mcp"],
+				["p", "b4dba9ada954c357c738f8f3a598fd2a022aadac8f082040b342e2a1487d534f", ""],
+				["p", "020b355baf5ec927ad01590c2cb734cf827ddfedbc93014b35d498c20546cc52", ""],
+				["p", "384c5c1cb08d57929ae159072f4f89b7163713023e578bb932aa38f3f5e8cbd4", ""],
+				["p", "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8", ""],
+				["client", "nostria"]
+			]
+		},
+		{
+			"content": "*GM people, and welcome to the 8th issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and everything in between!*\n\n*In today's update we cover the latest news from ContextVM. In particular, we discuss the first official release of our new Rust SDK, which brings CVM to native development. We also cover a bunch of new CEPs being merged.*\n\n*We also discuss the latest news from the ecosystem, with CVM being used as an actor for Nostr-based state machines.*\n\n*We also show the features we are currently working on. Our focus is now directed to bringing the Rust SDK in par with the TypeScript implementation.*\n\n*Finally, we will bring the most interesting news from the internet regarding the MCP ecosystem, AI agents, and more!*\n\n*Let's start!*\n\n---\n\n## **News from ContextVM** 📰\n\n*A list of updates, releases and new cool features.*\n\n- **The Rust SDK**: We recently released the first stable version of our brand-new [Rust SDK for CVM](https://github.com/ContextVM/rs-sdk)! The 0.1.x release family lands with the core specifications in place and support for [CEP‑4 Encryption](https://docs.contextvm.org/spec/ceps/cep-4/), [CEP‑6 Server Announcements](https://docs.contextvm.org/spec/ceps/cep-6/), [CEP‑19 Ephemeral Gift Wraps](https://docs.contextvm.org/spec/ceps/cep-19/), and [CEP‑35 Stateless Session Discovery and Capability Learning](https://docs.contextvm.org/spec/ceps/informational/cep-35/). With Rust, CVM now expands into native development, opening the door to new use cases, better performance, and future bindings for other languages.\n\n    This effort was led by students from Summer of Bitcoin, especially [Harsh](https://primal.net/p/nostr:nprofile1qqstfkaf4k54fs6hcuu03ua9nr7j5q324kkg7zpqgze59c4pfp74xncvwyshd) who lead the development of this release, and [Kushagra0902](https://primal.net/p/nostr:nprofile1qqs8mnfd962xrvpzpru4kjplpvmka7mjysr7apr4zn3jxgl0pqqyewgprw9vs) and [Kosti](https://primal.net/p/nostr:nprofile1qqspvd9c0d0ul49xcnlj7t0pw3gvenjxlx47pvp2wxrkcktwc9jmlmg3r68pg) who put together the very first version. We’re grateful for the community effort behind this!\n\n- **Common tool schema**: At last, we merged [CEP-15](https://github.com/ContextVM/contextvm-docs/issues/15), an enhancement proposal that implements a\nstandard for defining and discovering common tool schema. The goal is to create a simple way for servers to tell each other what tools they have, so they can be grouped together as in a marketplace. Thus, any user would be able to see the different servers providing the same feature, allowing them to choose the best option for their needs. This feature is available starting from the [v0.10.x family](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#0100) of the TypeScript SDK.\n\n- **Open-ended streams**: We recently introduced a new specification called [CEP‑41](https://docs.contextvm.org/spec/ceps/cep-41/), which proposes a method for defining open‑ended streams. This is especially useful for services that need to provide partial results, such as token‑by‑token generation, progressive computation output, subscriptions, and event feeds. This feature is available starting from the [v0.11.x family](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#0110) of the TypeScript SDK.\n\n- **Stateless session behavior**: We also published [CEP-35](https://github.com/ContextVM/contextvm-docs/issues/35), and informational specificaiton that introduces guidelines for stateless session behavior, providing a single behavioral source of truth for session-scoped discovery exchange and capability learning. This has already been implmented in our SDK, and the CEP formalizes it.\n---\n\n## **News from the ContextVM Ecosystem** 🗞️\n\n*Find all the projects leveraging ContextVM on [ContextVM/awesome](https://github.com/ContextVM/awesome).*\n\n- Developer Schlaus Kwab [shared](https://primal.net/e/nostr:nevent1qqsfpwsnyy59rjmthl5uw24suyflyek5h00w069pepy857j4e7vmqsgeyxtpz) a proof-of-concept to run state machines over Nostr for coordination between parties. Some of the features proposed leverage CVM servers as one of the actors involved. You can play around with the p0c [here](https://schlaustronics.com/nsm/).\n\n---\n\n## **What’s Next for ContextVM?** ⏭️\n\n*Let’s take a look at the features currently being implemented!*\n\n- Our main focus is bring the Rust SDK up to par with the TypeScript reference implementation. [IS64](https://github.com/ContextVM/rs-sdk/issues/64) is keeping track of the work needed to achieve it.\n\n- We are actively working to bring you a new playground, where users can try to use CVM with their favorite LLM. It will be part of our [website](https://contextvm.org/), and it will allow users to pick servers and start chatting with LLMs using them.\n\n- We are currently adapting our website to support CEP-15, to help users discover servers and their related features.\n\n## **Interesting resources from the web** 🤖\n\n*A curated list of resources we found interesting.*\n\n- New day, new [supply‑chain attack](https://safedep.io/mass-npm-supply-chain-attack-tanstack-mistral/). Be safe! Check out  TanStack [post‑mortem](https://tanstack.com/blog/npm-supply-chain-compromise-postmortem).\n\n- [Experimental triggers & events](https://github.com/modelcontextprotocol/experimental-ext-triggers-events) are coming to MCP. This is similar to the work we recently did for CEP‑41!\n\n- [The bottleneck was Never the code](https://www.thetypicalset.com/blog/thoughts-on-coding-agents): And interesting article discussing the usage of coding agents.\n\n- [Local AI needs to be the norm](https://unix.foo/posts/local-ai-needs-to-be-norm/): Another interesting article about running local models for some app features for increased privacy and more resilient software.\n\n**CVM Team Note**: In CVM we like the new paradigm of coding agents and remote execution, but we stay vigilant and critical about how these are being developed and the side effects they may cause. That is the only way we can truly build systems that fit real‑world necessities rather than merely chasing the latest shiny thing.\n\n---\n\n*Find out more about ContextVM:*\n\n- *Check out our [website](https://contextvm.org/) for documentation, blog posts, and more.*\n- *Join our [Signal](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR) group*\n- *Follow ContextVM on [Nostr](https://jumble.social/users/nostr:npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm)*\n- *Subscribe to our [Substack](https://contextvm.substack.com/). Help us spread the word!*\n- *Check out our GitHub [repositories](https://github.com/contextvm) and leave us a ⭐*",
+			"created_at": 1778594930,
+			"id": "00f36473bbe0e1235371ca5f8c4fc95b004a5302335b2bd96560dbd8e54b8137",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "7c293f49d26529788382888cb7e929ef3f63c5fdec878fdbf6df54d633bda14d5fe6bece84980cbed72f0684fec325bd8d3d04c7782490c307e200398e5af569",
+			"tags": [
+				["d", "cvmw-8"],
+				["title", "The Rust SDK — The ContextVM World #8 🌍"],
+				[
+					"summary",
+					"GM people, and welcome to the 8th issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and everything in between!\n\nIn today's update we cover the latest news from ContextVM. In particular, we discuss the first official release of our new Rust SDK, which brings CVM to native development. We also cover a bunch of new CEPs being merged."
+				],
+				[
+					"image",
+					"https://mibo.nostria.app/53e54b2cbbf686ef168732e87292b137702a35c7ecb8352f61db672540f9fa60.webp"
+				],
+				["published_at", "1778594930"],
+				["t", "cvm"],
+				["t", "mcp"],
+				["t", "dvm"],
+				["t", "agents"],
+				["t", "llm"],
+				["t", "ai"],
+				["t", "rpc"],
+				["p", "b4dba9ada954c357c738f8f3a598fd2a022aadac8f082040b342e2a1487d534f", ""],
+				["p", "7dcd2d2e9461b02208f95b483f0b376efb722407ee847514e32323ef08004cb9", ""],
+				["p", "1634b87b5fcfd4a6c4ff2f2de17450ccce46f9abe0b02a71876c596ec165bfed", ""],
+				["e", "90ba13212851cb6bbfe9c72ab0e113f266d4bbdee7e8a1c8487a7a55cf99b041", "", "", ""],
+				["p", "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8", ""],
+				["client", "nostria"]
+			]
+		},
+		{
+			"content": "*GM people, and welcome to the 7th issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and everything in between!*\n\n*In today's update we cover the latest news from ContextVM. In particular, we discuss the recent merging of two new specifications, CEP-23, which allows servers to publish a public profile and post notes signed with the same keypair used for protocol operations, and CEP-24, which allows users to attach comments and reviews to servers.*\n\n*We also discuss the latest news from the ecosystem, with a recent update of wavefunc.live, an internet radio working through Nostr and CVM.*\n\n*We also show the features we are currently working on, such as the new Rust SDK and new specifications.*\n\n*Moreover, we will present a curated list of articles, blog posts, and notes talking about CVM and how it is changing the way we interact with MCP servers.*\n\n*Finally, we will bring the most interesting news from the internet regarding the MCP ecosystem, AI agents, and more!*\n\n*Let's start!*\n\n---\n\n## **News from ContextVM** 📰\n\n*A list of updates, releases and new cool features.*\n\n- **Public Presence**: Thanks to the hard work of our students from [Summer of Bitcoin](https://www.summerofbitcoin.org/), we recently merged a new specification, namely [CEP-23](https://docs.contextvm.org/spec/ceps/cep-23/). This enhancement proposal standardizes the way in which MCP servers publish a persistent public profile and how they manage a public communication channel for updates and announcements. Servers are now able to publish `kind:0` events for profile metadata and `kind:1` notes for providing social announcements, public updates, or more, signed using the same keypair used for protocol operations. Consequently, we released a new version of our TypeScript SDK, [v0.9.0](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#090), integrating the latest specifications.\n\n- **Review your server**: We also merged [CEP-24](https://docs.contextvm.org/spec/ceps/cep-24/), an enhancement proposal that standardizes how users attach comments and reviews to server announcements. This provides a Nostr-native review and discussion layer around servers. Reviews and public metadata are already available on our [website](https://contextvm.org/s/750682303c9f0ddad75941b49edc9d46e3ed306b9ee3335338a21a3e404c5fa3)!\n\n- **The complete Swiss army knife**: We recently published the latest version of CVMI, [v0.3.0](https://github.com/ContextVM/cvmi/blob/main/CHANGELOG.md#030). This release finally completes the migration of the old cli tools into CVMI, with the latest addition of CTXCN, a utility that generates a type-safe client from a CVM server's tool definitions, allowing developers to call CVM tools as if they were native TypeScript functions.\n---\n\n## **News from the ContextVM Ecosystem** 🗞️\n\n*Find all the projects leveraging ContextVM on [ContextVM/awesome](https://github.com/ContextVM/awesome).*\n\n- [wavefunc.live](https://wavefunc.live/), an internet radio project based on Nostr and CVM, just got a big update. Check out this [note](https://primal.net/e/nostr:nevent1qqs9fcura3hq087h4e4hvk4tfpqd0hlnj3n9vxa9ryg2qcaffm2pekgy2lawe) by its creator, developer Schlaus Kwab.\n\n---\n\n## **What’s Next for ContextVM?** ⏭️\n\n*Let’s take a look at the features currently being implemented!*\n\n- [CEP-15](https://github.com/ContextVM/contextvm-docs/issues/15): This enhancement proposal implements a\nstandard for defining and discovering common tool schema. This aims to enable interoperability between\nmultiple servers, standardizing tool interfaces that clients can recognize and use consistently. It\nleverages MCP's `_meta` field, RFC 8785 for deterministic hashing, and\n[CEP-6 announcements](https://github.com/ContextVM/contextvm-docs/blob/master/src/content/docs/spec/ceps/cep-6.md)\nfor discovery, creating a marketplace where users can choose between multiple providers implementing the\nsame standard tool interface.\n\n- [CEP-35](https://github.com/ContextVM/contextvm-docs/issues/35): This enhancement proposal introduces informational guidelines for stateless session behavior, providing a single behavioral source of truth for session-scoped discovery exchange and capability learning. This has already been implmented in our SDK, and the CEP formalizes it.\n\n- The Rust SDK for CVM, [rs-sdk](https://github.com/ContextVM/rs-sdk) is progressing, thanks to our SoB students. It is steadily reaching feature parity with our TypeScript SDK, adding support for CEP-4, CEP-6, CEP-17, and CEP-19. Stay tuned for its first official release!\n---\n\n## **Interesting resources from the web** 🤖\n\n*A curated list of resources we found interesting.*\n\n- A new [proposal](https://github.com/pulsemcp/air/blob/main/docs/mcp-json-proposal.md) for a client-side MCP server configuration.\n\n- [\"At Meta, workers train their replacements\"](https://vector.news/at-meta-workers-train-their-replacements/): An insightful article, describing how Meta is training its models directly on employees' actions.\n\n- [\"Every level of AI and its terrifying consequences\"](https://www.youtube.com/watch?v=Qj9--hb-prA): What happens when we build systems so efficiently that even the smartest people can’t slow them down when they spiral out of control? What happens when something designed with good intentions follows those intentions to their logical extreme, even when it starts working against us? And more importantly, what happens when these systems stop being tools and start becoming something else, with their own wills and desires?\n\n- [\"The Supply and Demand of AI Tokens | Dylan Patel Interview\"](https://www.youtube.com/watch?v=LF3aUIM57uw): Patrick O'Shaughnessy sits down with Dylan Patel, founder of SemiAnalysis, to explore the explosive supply and demand dynamics of the AI revolution.\n\n---\n\n*Find out more about ContextVM:*\n\n- *Check out our [website](https://contextvm.org/) for documentation, blog posts, and more.*\n- *Join our [Signal](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR) group*\n- *Follow ContextVM on [Nostr](https://jumble.social/users/nostr:npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm)*\n- *Subscribe to our [Substack](https://contextvm.substack.com/). Help us spread the word!*\n- *Check out our GitHub [repositories](https://github.com/contextvm) and leave us a ⭐*",
+			"created_at": 1777389926,
+			"id": "08a843495d1d713fd9ebcc1468358ea26208f30d88ba5851a7b15001c57e7881",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "30fd957a499d036599c7d34bce47369ae165edfc639c57f9f373587ab47c500ebff60b53215fed80d08a53809e5e6669d3700d7665b1363f1f0c8a03887f8be8",
+			"tags": [
+				["d", "cvm-w7"],
+				["title", "Public Presence — The ContextVM World #7"],
+				[
+					"summary",
+					"In today's update we cover the latest news from ContextVM. In particular, we discuss the recent merging of two new specifications, CEP-23, which allows servers to publish a public profile and post notes signed with the same keypair used for protocol operations, and CEP-24, which allows users to attach comments and reviews to servers."
+				],
+				[
+					"image",
+					"https://mibo.nostria.app/be3fd7b9c46c3bf89ccb11d3ad28c90470c6bb654dfd7d4185bcb32f2530b8ff.webp"
+				],
+				["published_at", "1777389926"],
+				["t", "cvm"],
+				["t", "dvm"],
+				["t", "nostr"],
+				["t", "mcp"],
+				["t", "agent"],
+				["t", "llms"],
+				["e", "54e383ec6e079fd7ae6b765aab4840d7dff39466561ba51910a063a94ed41cd9", "", "", ""],
+				["p", "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8", ""],
+				["client", "nostria"]
+			]
+		},
+		{
+			"content": "*GM people, and welcome to the sixth issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and all in between!*\n\n*In today's update we cover the latest news from ContextVM. In particular, we discussed the recent merging of CEP-22 and the successive release of a new SDK version.*\n\n*We also discuss the latest news from the ecosystem, with the main topic being the new v0.2.0 of Relatr, with a freshly redesigned plugin system.*\n\n*Moreover, we will present a curated list of articles, blog posts, and notes talking about CVM and how it is changing the way we interact with MCP servers.*\n\n*Finally, we will bring the most interesting news from the internet regarding the MCP ecosystem, AI agents, and more!*\n\n*Let's start!*\n\n---\n\n## **News from ContextVM** 📰\n*A list of updates, releases and new cool features.*\n\n**Never too big**: We recently merged [CEP-22](https://contextvm.github.io/contextvm-docs/spec/ceps/cep-22/), a new proposal that allows CVM to publish a message to a realy even if its payload exceedes the size limits of a relay.\n\nThis change was also included in the latest release of the TypeScript SDK, with [v0.8.0](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#080) being published soon after the new specification was formalized. CVMI was also updated in [v0.2.8](https://github.com/ContextVM/cvmi/blob/main/CHANGELOG.md#028), bumping the SDK release to the latest one.\n\n---\n\n## **News from the ContextVM Ecosystem** 🗞️\n*Find all the projects leveraging ContextVM on [ContextVM/awesome](https://github.com/ContextVM/awesome).*\n\n**Relatr v0.2.x family**: Relatr has just undergone a major refactoring, which aimed to redesign the way the plugin system works.\nPlugins are one of the foundational parts that make Relatr what it is now, strongly impacting its core algorithm. Thus, the goal was to build the system such that anyone would be able to create, share, install, and distribute plugins directly through Nostr.\n\nIf you want to know more about the new Relatr, read our latest [deep dive](https://contextvm.substack.com/p/relatr-02x-let-a-thousand-trust-algorithms)!\n\n---\n\n## **What’s Next for ContextVM?** ⏭️\n*Let’s take a look at the features currently being implemented!*\n\n[CEP-15](https://github.com/ContextVM/contextvm-docs/issues/15): This enhancement proposal implements a\nstandard for defining and discovering common tool schema. This aims to enable interoperability between\nmultiple servers, standardizing tool interfaces that clients can recognize and use consistently. It\nleverages MCP's `_meta` field, RFC 8785 for deterministic hashing, and\n[CEP-6 announcements](https://github.com/ContextVM/contextvm-docs/blob/master/src/content/docs/spec/ceps/cep-6.md)\nfor discovery, creating a marketplace where users can choose between multiple providers implementing the\nsame standard tool interface.\n\nTwo new CEPs are currently [being worked on](https://github.com/ContextVM/contextvm-docs/pull/26/) by our students from SoB program:\n\n[CEP-23](https://github.com/ContextVM/contextvm-docs/issues/23): This enhancement proposal aims to standardize the way in which MCP servers publish a persistent public profile and how they manage a public communication channel for updates and announcements.\n\n[CEP-24](https://github.com/ContextVM/contextvm-docs/issues/24): This enhancement proposal aims to standardize how users attach comments and reviews to server announcements. This would allow to create a Nostr-native review and discussion layer around servers.\n\n---\n\n## **Who is Talking about ContextVM?** 📢\n*A curated list of articles, blog posts, and notes about ContextVM and its ecosystem.*\n\nCVM was mentioned is several article from [Sovereign Engineering](https://sovereignengineering.io/):\n\n[15: Make Localhost Great Again](https://jumble.social/notes/nostr:naddr1qvzqqqr4gupzpx77gg2frul26xkzr0gaq9n842u50axpcjhdsa3yeu388vrv5pftqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qqwnzdfdd4skkefdd3hkxctvdphhxapdvaex2ct594skwctfdcf36eng)\n\n[21: Hashtree, Nostr VPN, and Iris w/ Martti Malmi](https://jumble.social/notes/nostr:naddr1qvzqqqr4gupzpx77gg2frul26xkzr0gaq9n842u50axpcjhdsa3yeu388vrv5pftqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qq0ryvfddpshx6r5wfjk2ttwdaehgu3dwecxuttpdejz66tjd9esktj8qg)\n\n[The Pirate Ship of the Psychopaths](https://jumble.social/notes/nostr:naddr1qvzqqqr4gupzqp82f7p4pu2k92savrwqwptp7kac8p4pr5dqq4c06azqmgssu9cnqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qqxnzdehx5enxvpexvun2denjp53py)\n\nCVM was also mentioned in two different issues of *The Latest Pojects Noted*, in particular issue [6](https://jumble.social/notes/nostr:naddr1qvzqqqr4gupzp6vlpknzqlxwx5lya3mpskdhvhuqgc3kpynt4x20rpvamz2kz0whqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qqjrvdrzxy6nvcmz95exvcnp956rqve4943rzdmp95unscmyxsukvdpjxejry4qu09e) and [7](https://jumble.social/notes/nostr:naddr1qvzqqqr4gupzp6vlpknzqlxwx5lya3mpskdhvhuqgc3kpynt4x20rpvamz2kz0whqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qqjrsd3c8ycrxvtr94snwep4956xvwfe95unyvny95enjct9x9nrjveexyenqrlckxt).\n\nRelatr was mentioned in [Nostr Compass #17](https://jumble.social/notes/nostr:naddr1qvzqqqr4gupzqa6e2nmnzsgjfzdy520vdy4hywr06c9ue6crpr2zxyq749uu275qqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qqgrsvrrvd3nzcf5xa3rxen9x5enjhnnar9).\n\nOur lates blog post on Relatr was also turned into a podcast! Check it out [here](https://unsaltedbutter.ai/listen/Ae2zCl4qvIDUXjq3).\n\n---\n\n## **Intresting resources from the web** 🤖\n*A curated list of resources we found interesting.*\n\n[Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain](https://arxiv.org/html/2604.08407v1): An interesting paper about AI security.\n\n---\n\n*Find out more about ContextVM:*\n\n*Check out our [website](https://contextvm.org/) for documentation, blog posts, and more.*\n*Join our [Signal](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR) group*\n*Follow ContextVM on [Nostr](https://jumble.social/users/nostr:npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm)*\n*Subscribe to our [Substack](https://contextvm.substack.com/). Help us spread the word!*\n*Check out our GitHub [repositories](https://github.com/contextvm) and leave us a ⭐*",
+			"created_at": 1776242218,
+			"id": "74763c86f3c58556a28f8a70d5994327f8e5af60c8a40c1c225e4b5afba9f85a",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "8e766fd08156d7a4826ac0ee5d43fd73275024df69fcba553586d566e479aa550378d53f38acf2cd095f197c620c7ae6011c624c3ec4b8dff7e9bdf8b379fbe8",
+			"tags": [
+				["d", "cvmw-6"],
+				["title", "Never Too Big — The ContextVM World #6 🌍"],
+				[
+					"summary",
+					"GM people, and welcome to the sixth issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and all in between!"
+				],
+				[
+					"image",
+					"https://mibo.nostria.app/a7f4761c434b0bf548e4d6801004700d96c7064b81b6565f85470cf5c973080c.webp"
+				],
+				["published_at", "1776242218"],
+				["t", "cvm"],
+				["t", "mcp"],
+				["t", "news"],
+				[
+					"a",
+					"30023:9bde421491f3ead1ac21bd1d01667aab947f4c1c4aed87624cf2273b06ca052b:15-make-localhost-great-again",
+					"wss://search.nos.today/"
+				],
+				[
+					"a",
+					"30023:9bde421491f3ead1ac21bd1d01667aab947f4c1c4aed87624cf2273b06ca052b:21-hashtree-nostr-vpn-and-iris",
+					"wss://search.nos.today/"
+				],
+				[
+					"a",
+					"30023:04ea4f8350f1562aa1d60dc070561f5bb8386a11d1a00570fd7440da210e1713:1775330939573",
+					"wss://search.nos.today/"
+				],
+				[
+					"a",
+					"30023:e99f0da6207cce353e4ec761859b765f80462360926ba994f1859dd895613dd7:64b156cb-2fba-4035-b17a-98cd49f426d2",
+					"wss://search.nos.today/"
+				],
+				[
+					"a",
+					"30023:e99f0da6207cce353e4ec761859b765f80462360926ba994f1859dd895613dd7:8689031c-a7d5-4f99-922d-39ae1f939130",
+					"wss://search.nos.today/"
+				],
+				[
+					"a",
+					"30023:775954f7314112489a4a29ec692b72386fd60bcceb0308d423101ea979c57a80:80ccc1a47b3fe539",
+					"wss://search.nos.today/"
+				],
+				["p", "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8", ""],
+				["client", "nostria"]
+			]
+		},
+		{
+			"content": "Relatr 0.2.x has been a long time coming.\n\nThis release is the result of a real engineering effort: not just shipping features, but stepping back, questioning assumptions, and redesigning one of the most important parts of the system until it matched the principles we care about. The center of gravity in this release is the plugin system, and with it, Relatr takes a major step forward.\n\nIn Relatr, plugins, or validators, are a big part of its essence. The core algorithm is based on two main components that each account for 50% of the final rank. One half is social graph distance. The other half is a set of validators. From the beginning, the idea was to make those validators configurable so anyone could decide what trust means for them and craft their own algorithm by composing that set.\n\nBefore this iteration, in the 0.1.x family, plugins in Relatr were written in TypeScript. That approach was powerful in theory. Anyone could write their own validator, extend the system, and adapt it to their own trust model. But in practice, the experience was not where it needed to be.\n\nWriting a plugin meant navigating the codebase, understanding Relatr’s internal capabilities, and implementing logic directly in TypeScript. That is possible, especially today with LLMs helping people bridge gaps faster than ever. But the deeper questions remained unanswered.\n\nHow do you install a plugin from someone else?\n\nHow do you share one cleanly?\n\nHow do you publish a validator so others can discover it, evaluate it, and adopt it?\n\nThere was no satisfying answer. And because the plugin system lived in TypeScript, it also left the door open to bad tradeoffs: messy ergonomics, dependency creep, more attack surface, and a design that could easily become over-engineered in the name of flexibility. Every path forward seemed to point toward a solution that was heavier, more fragile, and less portable than what we wanted.\n\nSo we kept the problem in the back of our minds.\n\nThe goal was clear: build a validation plugin system for Relatr that would let anyone write plugins easily, share them easily, install them easily, and distribute them natively through Nostr itself. We wanted plugins to be portable. We wanted curation. We wanted the Web of Trust and Nostr’s distribution model to work together instead of living in separate worlds.\n\nThen we found [elo-lang](https://elo-lang.org/).\n\nElo is a simple, well-designed, portable, and safe data expression language. It is purely functional, originally designed for no-code tooling, and excellent at describing data transformations in a concise and understandable way. When we discovered it, the first reaction was immediate: this could be the foundation for Relatr’s new plugin system.\n\nIt checked almost every box.\n\nPortable. Safe. Expressive. Small enough to travel. Predictable enough to trust.\n\nBut once we started experimenting, we found an important limitation. Elo’s normal execution model is linear, and that is often exactly what you want. For Relatr, though, we needed something more expressive. We needed a way to describe multi-step processes. We needed plugins to declare when host-provided capabilities should be invoked: a Nostr query, a social graph operation, an HTTP-based NIP-05 resolution, and similar actions. We needed a clean way for the host to orchestrate those requests while keeping the plugin language itself safe and understandable.\n\nThat is what led us to fork Elo.\n\nFrom there, we introduced two core operators: do and then.\n\nThe idea is simple.\n\nDo declares that the host should execute a capability. For example, a plugin can say: perform a Nostr query, resolve a NIP-05 identifier, or inspect the social graph.\n\nThen defines ordering. It lets authors compose multi-step logic in a natural sequence, where later steps can depend on data gathered earlier.\n\nWhat we like most about this design is how little it feels like a bolt-on. The new operators fit naturally into Elo’s style. They feel close to the language that already existed. They preserve the elegance of the original while giving Relatr the expressivity it needed.\n\nMore importantly, the model is safe.\n\nA plugin cannot just execute arbitrary code or invent arbitrary powers for itself. The capabilities available to a validator are defined by the host. In this case, by the Relatr instance that chooses to run it. Relatr ships with a built-in catalog of capabilities like nostr.query, graph.are_mutual, or http.nip05_resolve. If a malicious plugin tries to invoke something outside that catalog, such as an imaginary evil capability, nothing happens. The host simply does not provide it.\n\nThat design changes Relatr fundamentally. It turns Relatr into a framework.\n\nPlugins become portable programs that are compatible depending on the version and capability surface of the host. The host decides what powers exist. The plugin can only ask for those powers, never exceed them.\n\nA useful way to picture the flow is this: first collect, then execute, then provision, then result.\n\nA plugin might say: first do a Nostr query to fetch kind 0 profile events; then extract the NIP-05 field from the returned metadata; then do an HTTP NIP-05 resolution; and finally return 1 or 0 depending on whether the resolution matches the target pubkey.\n\nNotice how naturally that reads. We can explain the execution model using the same words as the operators themselves: do this, then that. That was intentional. We wanted plugin authoring to feel as natural and comprehensive as possible.\n\nThis architecture gave us more than safety and readability. It also unlocked performance wins.\n\nBecause plugins declare their required data statically, the host can understand the work up front. It can group similar capability calls, deduplicate requests, and avoid redundant executions. That improves synchronization and validation throughput without making plugin authors think about low-level orchestration. Authors describe what they need. Relatr decides how to fetch and provision it efficiently.\n\nThe result is a plugin language that is portable, safe, multi-step, expressive, and efficient enough to live comfortably inside a Nostr event.\n\nThat last point matters.\n\nOnce we had the plugin model, the next logical question was: how should these plugins be packaged and shared?\n\nThe answer was refreshingly simple. A plugin is bundled as a Nostr event.\n\nThe Elo expression goes in the event content. The metadata lives in tags: title, description, stable identifier, compatibility range, and other manifest details. The result is a regular Nostr event of kind 765, purpose-built for portable Relatr plugins.\n\nThis is where things start to get really exciting.\n\nIf plugins are Nostr events, then distribution becomes native to the same ecosystem Relatr already lives in. Plugins can be published to relays. They can be mirrored. They can be discovered. They can be curated. They can be forked. They can be grouped into packs. They can evolve through new versions. They can travel through the same open network that Relatr already uses.\n\nIn other words, plugin distribution stops being a side problem and becomes part of the protocol surface.\n\nThat opens the door to a plugin marketplace, and that is exactly where we went next.\n\nBut shipping a portable format was only part of the job. We also had to think seriously about the authoring experience.\n\nA portable language is only as useful as the tools people have to write it well.\n\nOne of Elo’s original strengths is that it already works nicely in the browser. It compiles to JavaScript, and the upstream project includes a playground where people can learn the language, write expressions, and validate their syntax. That gave us an excellent starting point.\n\nStill, there was a missing piece.\n\nElo by itself has no reason to know what Relatr is. It does not know Relatr’s capabilities. It does not know the host’s plugin constraints. It does not know what a valid Relatr plugin should look like. And we did not want to solve that by tightly coupling Relatr into Elo. We liked the separation. We wanted Elo to remain a general-purpose expression language and Relatr to remain its own system. Keeping them decoupled makes both easier to understand, easier to maintain, and potentially more useful across the broader Nostr ecosystem.\n\nBut decoupling alone does not solve authoring UX.\n\nWriters still need confidence. They need validation. They need feedback before publishing.\n\nThat is why we built Relo.\n\nRelo is both a library and a CLI. It bridges the authoring gap between Elo and Relatr without collapsing the two into one project.\n\nOn the web, it powers the publishing interface on the Relatr website, where users can write, validate, and publish plugins directly from the browser.\n\nLocally, it works as a CLI, so plugin authors can write validators on their own machines, validate them, build artifacts, and publish them from the command line. That matters for regular publishers, but it also matters for LLM-assisted workflows. If you are iterating quickly with local files, prompts, and terminal tools, the full plugin lifecycle is available without having to leave your environment and move to a website every time.\n\nAnd now there is another important piece in that authoring story: skills.\n\nWe wanted plugin writing to be accessible not only to experienced developers, but also to people working with AI-assisted tooling. So we created installable authoring skills that package the right context, concepts, and lifecycle knowledge into a form LLMs can use effectively.\n\nThat means a user who wants to write Relatr plugins with AI assistance can install the Relatr authoring skill as simply as running npx skills add contextvm/relatr. From there, they get a structured understanding of the plugin model: how to think in terms of bounded capabilities, how to structure multi-step programs, how to validate a plugin, and how to move from draft to a publishable Nostr event.\n\nThis matters because authoring is not only about syntax. It is about having the right mental model. A good plugin is not arbitrary code with network access. It is a bounded scoring program. It collects data safely, scores it clearly, and fits into a portable lifecycle that includes validation, packaging, publishing, installation, and tuning.\n\nThat is the real role of skills in this release. They turn the authoring experience into something teachable, repeatable, and much more accessible to people working with modern AI tools.\n\nTwo interfaces, one contract: web and CLI. And now, a third layer of support for AI-assisted authoring.\n\nThat made Relo, together with the new skills, the missing piece of the puzzle. The authoring loop is now much closer to end to end, while still preserving the elegance of the overall architecture.\n\nAnd this release is not only about internals. The website has been upgraded to reflect the new reality of Relatr as a plugin-driven framework.\n\nThe documentation now covers the new plugin system, including writing, publishing, tooling, and specification. There is a new plugin marketplace where users can discover available plugins and install them directly into their Relatr instances from the website. The new home for all of this is [relatr.net](https://relatr.net).\n\nThat is a major shift.\n\nRelatr instances are no longer opaque boxes you configure indirectly and hope for the best. Now operators can manage plugins directly from the website: install, uninstall, enable, disable, and adjust weights to shape the algorithm their instance uses.\n\nThat last point is central.\n\nTrust metrics should not be a black box.\n\nWith this release, it becomes much easier to see what algorithm is actually behind a Relatr instance. You can inspect the plugins, their weights, and the individual components contributing to a score. You can understand not just the output, but the composition behind the output.\n\nTransparency for trust means no black boxes.\n\nLooking back, this release was a genuine engineering journey. We designed a new plugin system for Relatr. We turned plugins into portable Nostr events. We discovered a remarkable expression language, then forked it carefully to meet the real needs of host-orchestrated validation. We created Relo to make authoring practical, ergonomic, and complete across both web and CLI. And we added skills so that even AI-assisted authors can work with the right concepts and constraints from the start.\n\nNone of this happened quickly, and that was the point.\n\nAt every stage we stopped to reconsider the tradeoffs: technical design, UX, safety, ergonomics, integration, and performance. We did not want to solve one problem by creating three worse ones. We also remained committed to one of Relatr’s original constraints: this software should still be able to run on modest hardware.\n\nThat remains true.\n\nRelatr is still fully open source. It still aims to be efficient. It still aims to let people run their own Web of Trust engine without requiring a pile of infrastructure or a mountain of specialized expertise, especially when paired with ContextVM. And for people who want to run it themselves, all the details are available in the GitHub repository at [https://github.com/ContextVM/relatr](https://github.com/ContextVM/relatr).\n\nWhat has changed is the degree of freedom available to users.\n\nNow anyone can compose an algorithm more like Lego than like a monolith. Anyone can write plugins. Anyone can publish them. Anyone can share them. Anyone can browse a marketplace, install validators, curate sets, and assemble trust models that reflect their own values and communities.\n\nThat is what this release is really about.\n\nNot just new features, but a stronger answer to an old question: who gets to define trust?\n\nOur answer remains the same. Not a platform. Not a hidden algorithm. Not a single authority.\n\nLet a thousand trust algorithms bloom.\n\nThat was one of the earliest premises behind Relatr, and with the 0.2.x family it is more true than ever. The engineering is there for people to use, inspect, fork, and build on. The system is more transparent, more portable, and more shareable. The black box has been opened.\n\nRelatr is now closer to what it always wanted to be: a tool for sovereign trust computation in an open network.\n\nThis release gets us materially closer to that future.",
+			"created_at": 1775659222,
+			"id": "81d977abdb96a32e8a0b5bb27af3845fc8b384870e8bfa33538a8ae62d757152",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "eb954c728fd11c817b4f4dd1ce20fca5d3ece59cb801c04dc3d754219b523226d844c8f9f8e2c514c7f0be6ac1544951ff95a07be4302679c1ce2cf9401b0fcb",
+			"tags": [
+				["d", "relatr-0-2"],
+				["title", "Relatr 0.2.x: Let a Thousand Trust Algorithms Bloom"],
+				[
+					"summary",
+					"Relatr 0.2.x has been a long time coming.\n\nThis release is the result of a real engineering effort: not just shipping features, but stepping back, questioning assumptions, and redesigning one of the most important parts of the system until it matched the principles we care about. The center of gravity in this release is the plugin system, and with it, Relatr takes a major step forward."
+				],
+				[
+					"image",
+					"https://mibo.nostria.app/03789d2a1e6e2a733684239a050301c8196bc9dfc520d81f3779c941f33f0892.webp"
+				],
+				["published_at", "1775659222"],
+				["t", "wot"],
+				["t", "relatr"],
+				["t", "cvm"],
+				["t", "contextvm"],
+				["t", "trust"],
+				["client", "nostria"]
+			]
+		},
+		{
+			"content": "GM people, and welcome to the fifth issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and all in between!*\n\n*In today's update we cover the latest news from ContextVM. In particular, we have been chosen to mentor the next generation of open-source contributors through the Summer of Bitcoin internship program. We also cover our latest modification to the CVM website and the spam attack that recently hit our realys.*\n\n*We also discuss the latest news from the ecosystem, with a growing number of MCP servers appearing. For example, two new MCP servers are now available through CVM, one based on am-i.exposed, another on OpenTimeStamp.*\n\n*Moreover, we will present a curated list of articles, blog posts, and notes talking about CVM and how it is changing the way we interact with MCP servers.*\n\n*Finally, we will bring the most interesting news from the internet regarding the MCP ecosystem, AI agents, and more!*\n\n*Let's start!*\n\n---\n\n## **News from ContextVM** 📰\n\n*A list of updates, releases and new cool features.*\n\n- **Summer of Bitcoin**: CVM has been invited to participate in the [Summer of Bitcon (SoB)](https://www.summerofbitcoin.org/) project, a global, online summer internship program focused on introducing university students to Bitcoin, Nostr, and open-source development. CVM will provide projects for students to work on during the summer, mentoring the new generation of open-source contributors and helping them bootstrapping their careers in the space. Do you have a CVM-based project you would like to propose for SoB? Feel free to [reach out to us](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR)!\n\n- **Search by `npub`**: We recently made a powerful update to our website to improve server discoverability and strengthen decentralization. Users can now lookup MCP server directly by `npub` and `nprofile` either in the search bar or directly by adding it to the URL. Bonus point, you can also search it through its [NIP-05](https://github.com/nostr-protocol/nips/blob/master/05.md) indentifier!\n\n- **Spam attack**: We recently suffered a spam attack on our relays. To fix the issue and reduce the attack surface for the future, we decided to [fork](https://github.com/ContextVM-org/strfry-cvm) the Strfry relay, which is the base of our infrastructure, to add additional write policies to restrict accepted event kinds to the subset used by our relay.\n\n---\n\n## **News from the ContextVM Ecosystem** 🗞️\n\n*Find all the projects leveraging ContextVM on [ContextVM/awesome](https://github.com/ContextVM/awesome).*\n\n- **Am I exposed?**: A new [MCP server](https://contextvm.org/s/e30b0e8de68d4dfa1d172c7ae37116d1dd96488694be135c11bbecf40ce55d18) is now available on Nostr leveraging the [am-i.exposed](https://am-i.exposed/) on-chain scanner capabilities to audit the privacy of your wallet information, ranging from transaction evaluation, UTXO hygiene, and full audit. We also did a quick [demo](https://jumble.social/notes/nostr:nevent1qvzqqqqqqypzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qyd8wumn8ghj7un9d3shjtnwdaehgunrdpjkx6ewd4jj7qpq3mk46gdne4pkgt5ykwd7f3zrmxvk4nzv3wfh5dw2xf5snhuevsdschwfsk) on how to use it.\n\n- **Time-stamping Nostr events**: Another new [MCP server](https://www.contextvm.org/s/e1c1c32729cbd542c9b9ce7ee6e421c434e07835228020c4f57140782f02496a) is now available, allowing users to use [OpenTimeStamp](https://opentimestamps.org/) to time-stamp any Nostr event. The tool is very simple, providing one command to create an attestation and another to verify it. We also wrote a simple [note](https://jumble.social/notes/nostr:nevent1qvzqqqqqqypzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qqsfa832c5rsu2x8n0qf099jsjc2vtjuy2h8knmxteu778p3advxrjc6edys7) with the instruction to use this server through CVMI CLI.\n\n- **Nostr.watch + CEP-8**: [Nostr.watch](https://nostr.watch/), an important online tool that monitors  relays health, recently integrated CEP-8 payments in their [CVM-enabled MCP server](https://cvm.nostr.watch/). Check Sandwich, nostr.watch creator, [note](https://jumble.social/notes/nostr:nevent1qvzqqqqqqypzpem34u9stj8ftlxldl4n2qz5f5hmrnxns3uga86fpwe7u28ga4n0qythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qqs95r698a753rtsqnly9v9g9hvf42m4qp32c4yesdxv3uxmvnzy7jsx0wx7j) to know more.\n\n- **Relatr + Ants**: Relatr was recently added into the [Advanced Nostr Text Search (Ants)](https://github.com/dergigi/ants) project by [Gigi](https://jumble.social/users/nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc) to improve its search capabilities.\n\n- **New Relatr domain**: Due to some issues with our registrar we no longer control the old relatr.xyz domain. You can now find it on [relatr.net](https://www.relatr.net/).\n---\n\n## **What’s Next for ContextVM?** ⏭️\n\n*Let’s take a look at the features currently being implemented!*\n\n- [CEP-15](https://github.com/ContextVM/contextvm-docs/issues/15): This enhancement proposal implements a\nstandard for defining and discovering common tool schema. This aims to enable interoperability between\nmultiple servers, standardizing tool interfaces that clients can recognize and use consistently. It\nleverages MCP's `_meta` field, RFC 8785 for deterministic hashing, and\n[CEP-6 announcements](https://github.com/ContextVM/contextvm-docs/blob/master/src/content/docs/spec/ceps/cep-6.md)\nfor discovery, creating a marketplace where users can choose between multiple providers implementing the\nsame standard tool interface.\n\n- Three new CEPs have been proposed and are waiting for a number to be assigned:\n- [CEP-XX](https://github.com/ContextVM/contextvm-docs/issues/22): This enhancement proposal aims to define a way to detect when a message can't be published, due to its payload exceeding the size limits of a relay. The linked issue tracks exploratory work for this new mechanism.\n- [CEP-XX](https://github.com/ContextVM/contextvm-docs/issues/23): This enhancement proposal aims to standardize the way in which MCP servers publish a persistent public profile and how they manage a public communication channel for updates and announcements.\n- [CEP-XX](https://github.com/ContextVM/contextvm-docs/issues/24): This enhancement proposal aims to standardize how users attach comments and reviews to server announcements. This would allow to create a Nostr-native review and discussion layer around servers.\n\n---\n\n## **Who is Talking about ContextVM?** 📢\n\n*A curated list of articles, blog posts, and notes about ContextVM and its ecosystem.*\n\n- CVM has been mentioned on [Nostr Compass #15](https://jumble.social/notes/nostr:naddr1qvzqqqr4gupzqa6e2nmnzsgjfzdy520vdy4hywr06c9ue6crpr2zxyq749uu275qqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qqgrjcmp89snzepjvesnjve3xdnrxwkwxyl), a weekly newsletter covering everything going on in the Nostr ecosystem. CVM has been also mentioned in the [Nostr Compass Podcast #12](https://jumble.social/notes/nostr:nevent1qvzqqqqqqypzqa6e2nmnzsgjfzdy520vdy4hywr06c9ue6crpr2zxyq749uu275qqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qqsvydegp7zgusxlg248rudq8hakztm5dku4rztxfdmxspre3tyht8c02zr6j).\n\n---\n\n## **Intresting resources from the web** 🤖\n\n*A curated list of resources we found interesting.*\n\n- [Nicholas Carlini - Black-hat LLMs | [un]prompted 2026](https://www.youtube.com/watch?v=1sd26pWhfmg): *Nicholas Carlini*, Research Scientist at *Anthropic*, discusses how LLMs can now be used to automate attacks that were previously only doable by human adverasries.\n\n- [Thoughts on slowing the fuck down ](https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/): An interesting article by *Mario Zecher* diving into what could be the best way to work with coding agents.\n\n- [Skills Over MCP Interest Group - March 24th 2026 Office Hours Notes](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/2460): This resource provides the minute of the meeting of the *Skills Over MCP Interest Group*, the commitee responsible for discussing the next steps, issues, and blockers for implementing Skills into MCP.\n---\n\n*Find out more about ContextVM:*\n\n- *Check out our [website](https://contextvm.org/) for documentation, blog posts, and more.*\n- *Join our [Signal](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR) group*\n- *Follow ContextVM on [Nostr](https://jumble.social/users/nostr:npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm)\n- *Subscribe to our [Substack](https://contextvm.substack.com/). Help us spread the word!*\n- *Check out our GitHub [repositories](https://github.com/contextvm) and leave us a ⭐*",
+			"created_at": 1774973288,
+			"id": "37bbe417904a63ab4ed5d0dad2e96c53ea753a3a717fce05beee3a0ed08a180e",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "daa209d27f7f404b3b829dbd11377d1c2b1c8d10dad1fb44af21af0ab29fee9fdcacc48b710cbd12b8db00867b9654b20b75ac9d41ec4abae3941b4812024486",
+			"tags": [
+				["d", "cvm-world-5"],
+				["title", "Mentoring the Next Generation — The ContextVM World #5 🌍 "],
+				[
+					"summary",
+					"In today's update we cover the latest news from ContextVM. In particular, we have been chosen to mentor the next generation of open-source contributors through the Summer of Bitcoin internship program. We also cover our latest modification to the CVM website and the spam attack that recently hit our realys."
+				],
+				[
+					"image",
+					"https://media.openresist.com/94358655519c6194b8268e6c036566a939fef59dc288d3da4b772531720567c6.webp"
+				],
+				["published_at", "1774973288"],
+				["t", "cvm"],
+				["t", "mcp"],
+				["t", "dvm"],
+				["t", "ai"],
+				["t", "agents"],
+				[
+					"e",
+					"8eed5d21b3cd43642e84b39be4c443d9996acc4c8b937a35ca326909df99641b",
+					"wss://relay.primal.net/",
+					"",
+					"6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8"
+				],
+				["p", "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8", ""],
+				[
+					"e",
+					"9e9e2ac5070e28c79bc09794b284b0a62e5c22ae7b4f665e79ef1c31eb5861cb",
+					"wss://search.nos.today/",
+					"",
+					"6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8"
+				],
+				[
+					"e",
+					"5a0f453f7d488d7004fe42b0a82dd89aab750062ac5499834cc8f0db64c44f4a",
+					"wss://search.nos.today/",
+					"",
+					"e771af0b05c8e95fcdf6feb3500544d2fb1ccd384788e9f490bb3ee28e8ed66f"
+				],
+				["p", "e771af0b05c8e95fcdf6feb3500544d2fb1ccd384788e9f490bb3ee28e8ed66f", ""],
+				["p", "6e468422dfb74a5738702a8823b9b28168abab8655faacb6853cd0ee15deee93", ""],
+				[
+					"a",
+					"30023:775954f7314112489a4a29ec692b72386fd60bcceb0308d423101ea979c57a80:9ca9a1d2fa9313f3",
+					"wss://search.nos.today/"
+				],
+				[
+					"e",
+					"c237280f848e40df42aa71f1a03dfb612f746db95189664b766804798ac9759f",
+					"wss://search.nos.today/",
+					"",
+					"775954f7314112489a4a29ec692b72386fd60bcceb0308d423101ea979c57a80"
+				],
+				["p", "775954f7314112489a4a29ec692b72386fd60bcceb0308d423101ea979c57a80", ""],
+				["client", "nostria"]
+			]
+		},
+		{
+			"content": "*GM people, and welcome to the third issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and all in between!*\n\n*In today's update we cover CEP-17, the latest specification change to the CVM protocol. This change allows MCP servers to announce the relays for establishing connections, making it easier to be discovered by clients.*\n\n*We also discuss the latest news from the ecosystem and the latest feature being implemented in the CVM protocol, CEP-15, for common tools schema.*\n\n*Moreover, we will present a curated list of articles, blog posts, and notes talking about CVM and how it is changing the way we interact with MCP servers.*\n\n*Finally, we will bring the latest news from the MCP ecosystem, including specification changes and new protocol additions. CVM is built on MCP, which means that we care about providing you up-to-date information from its thriving ecosystem.*\n\n*Let's start!*\n\n---\n\n## **News from ContextVM** 📰\n*A list of updates, releases and new cool features.*\n\n**Become discoverable**: We recently merged [CEP-17](https://docs.contextvm.org/spec/ceps/cep-17/), a proposal that defines a relay list mechanism based on [NIP-65](https://github.com/nostr-protocol/nips/blob/master/65.md) conventions. Servers can publish the list of relays they are connected to using kind `10002` events, allowing clients to discover the appropriate relays for establishing connections. This solves the current limitation where users must know both a server's public key and its relay URLs to connect.\n\n**A new release family for the CVM SDK**: We published a new release family of the CVM SDK, v0.7.x. Notably, we introduced support for CEP-17 in [v0.7.0](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#070), while successive patch releases introudeced new features, such as default discovery to bootstrap relays.\n\n**Making the CLI agent-friendly**: We rolled out several new improvements to our CLI tool, CVMI, bringing [v0.2.x](https://github.com/ContextVM/cvmi/blob/main/CHANGELOG.md#025) to life. This new release family introduces two new powerful commands:\n\n`call`: This command allows users to invoke CVM server directly from the command line, making it highly suited for agentic use. It also reduces token usage, thanks to simpler and cleaner responses;\n\n`discover`: This command allows users to easily find public CVM servers, by querying relay announcements.\n\n**A new CVM SDK in Rust**: Open-source contributor [K0sh](https://primal.net/p/nprofile1qqspvd9c0d0ul49xcnlj7t0pw3gvenjxlx47pvp2wxrkcktwc9jmlmg3r68pg#notes) is currently doing a complete rewrite of the [CVM SDK using Rust](https://github.com/k0sti/rust-contextvm-sdk), the most common programming language in the Bitcoin/Nostr ecosystems. The project is still highly experimental, thus we recommend testing it taking great care.\n\n---\n\n## **News from the ContextVM Ecosystem** 🗞️\n*Find all the projects leveraging ContextVM on [ContextVM/awesome](https://github.com/ContextVM/awesome).*\n\n[Schlaus Kwab](https://primal.net/p/nprofile1qqsr4fvpwfeu8vhefay3ss8qguhsf8g0zqqfug77vvqxze4u4xekagcs48nlt) integrated an AI agent chat into [earthly.city](https://earthly.city/), a Nostr-native collaborative mapping application that leverages CVM. Check this [note](https://primal.net/e/nevent1qqs0fwy8fuwduvcf0u8m2duj62jq8tys3mrsrnxuh5uydwp2ysamflqr47max) to view how it works!\n\n---\n\n## **What’s Next for ContextVM?** ⏭️\n*Let’s take a look at the features currently being implemented!*\n\n[CEP-15](https://github.com/ContextVM/contextvm-docs/issues/15): This enhancement proposal implements a\nstandard for defining and discovering common tool schema. This aims to enable interoperability between\nmultiple servers, standardizing tool interfaces that clients can recognize and use consistently. It\nleverages MCP's `_meta` field, RFC 8785 for deterministic hashing, and\n[CEP-6 announcements](https://github.com/ContextVM/contextvm-docs/blob/master/src/content/docs/spec/ceps/cep-6.md)\nfor discovery, creating a marketplace where users can choose between multiple providers implementing the\nsame standard tool interface.\n\n---\n\n## **Who is Talking about ContextVM?** 📢\n*A curated list of articles, blog posts, and notes about ContextVM and its ecosystem.*\n\nOur latest [article](https://primal.net/a/naddr1qvzqqqr4gupzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qq40fk857t3geay2az6g3n9qu3nwpzhy46vfyqwxx83) on CVMI, the swiss army knife CLI for ContextVM.\n\nCVM has been mentioned on [Nostr Compass #12](https://primal.net/a/naddr1qvzqqqr4gupzqa6e2nmnzsgjfzdy520vdy4hywr06c9ue6crpr2zxyq749uu275qqyt8wumn8ghj7un9d3shjtnyd968gmewwp6kytcpzamhxue69uhhxetpwf3kstnwdaejuar0v3shjtcqzqmnvenp893nvctyv5ukxdenvcmqlvdyfa), a weekly newsletter covering everything going on in the Nostr ecosystem.\n\n---\n\n## **Intresting resources from the web** 🤖\n*A curated list of resources we found interesting.*\n\n[Google Workspace CLI](https://github.com/googleworkspace/cli): A one command-line tool for Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, and more, with AI agent skills.\n\n[MCPorter](https://github.com/steipete/mcporter/blob/main/README.md): A TypeScript runtime, CLI, and code-generation toolkit for MCP.\n\n[Context Mode](https://mksg.lu/blog/context-mode): An MCP server that allows to reduce context usage by 98%.\n\n[CLI vs MCP](https://kanyilmaz.me/2026/02/23/cli-vs-mcp.html): An interesting blog post hightlightin the difference between CLIs and MCPs.\n\n[Code Mode](https://blog.cloudflare.com/code-mode-mcp/): An MCP server that provides a technique for reducing context window usage during agent tool use.\n\n[When the Interface Flattens Into a Prompt](https://youtu.be/ccT0jjd36I4): This video explores emerging paths in AI interface design, and why terminal-like experiences are appealing and can be dangerous.\n\n[The lethal trifecta for AI agents](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/): This article explores the security risks of letting agents leverage tools that can lead attackers to steal you data.\n\n[MCP is Dead; Long Live MCP!](https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/): A thoughtful blog post trying to shine some lights on the current hype on CLIs replacing MCPs.\n\n---\n\n*Find out more about ContextVM:*\n\n*Check out our [website](https://contextvm.org/) for documentation, blog posts, and more.*\n*Join our [Signal](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR) group*\n*Follow ContextVM on Nostr, nostr:npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm*\n*Subscribe to our [Substack](https://contextvm.substack.com/). Help us spread the word!*\n*Check out our GitHub [repositories](https://github.com/contextvm) and leave us a ⭐*",
+			"created_at": 1773760301,
+			"id": "cc50554eafb3e23752e76481219dea7cc952b50ceb359cfd7a3e475a389cc695",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "995f43a6b79099b0044bf1a44f201b9ec22f205688ff3d69864ec87c3c41b9519df7d843e9fdc9b91da29a1260f24967373baa9d7b391bc87d50a902ae928fb0",
+			"tags": [
+				["d", "cvm-world-4"],
+				["title", "Become Discoverable — The ContextVM World #4"],
+				[
+					"summary",
+					"In today's update we cover CEP-17, the latest specification change to the CVM protocol. This change allows MCP servers to announce the relays for establishing connections, making it easier to be discovered by clients. New CVMI capabilities, and other news from the ecosystem"
+				],
+				[
+					"image",
+					"https://mibo.eu.nostria.app/52499ea5b6913f6acf6e733bc8dc2e1ea122d26034f6a6956109f04662babf70.webp"
+				],
+				["published_at", "1773760301"],
+				["t", "mcp"],
+				["t", "cvm"],
+				["t", "agents"],
+				["t", "llm"],
+				["t", "dvm"],
+				["p", "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8", ""]
+			]
+		},
+		{
+			"content": "ContextVM is built on a simple idea: remote computation should be easy to publish and easy to use without depending on the usual stack of domains, hosted infrastructure, and OAuth-heavy integration.\n\nCVMI is becoming the command line for that world.\n\nWith the new `discover` and `call` commands, CVMI is no longer only a supporting tool around the ecosystem. It is becoming a direct way to explore the network, inspect remote servers, debug them from the terminal, and integrate ContextVM services into scripts, apps, and agent workflows.\n\n## Why this matters now\n\nThe CLI is having a comeback, and for good reason.\n\nA command line is one of the few interfaces that works equally well for users, and agents. It is explicit, scriptable, composable, and easy to debug. That makes it a natural fit for modern tooling, especially as more people build workflows around agents and automation.\n\nThis is also why interest in CLI-first patterns around MCP is growing. Instead of loading every possible tool definition up front, a CLI lets you discover what is available and inspect details only when needed. That can make workflows lighter, cheaper, and easier to compose. One recent example of this trend are blog posts like CLI vs MCP: <https://kanyilmaz.me/2026/02/23/cli-vs-mcp.html>, developments like MCPorter: <https://github.com/steipete/mcporter/blob/main/README.md>, or even Google with gws: <https://github.com/googleworkspace/cli>.\n\nContextVM fits this moment unusually well because it already removes many of the assumptions that make remote tooling harder than it needs to be. It does not depend on OAuth or involves more third parties than public Nostr relays. It is secure by default, permissionless, and based on key-driven identity and relay-based reachability.\n\n## Discover services directly from the network\n\n`cvmi discover` makes public ContextVM services easier to find.\n\nInstead of relying on docs, directories, or manual endpoint sharing, you can query relay announcements directly from the terminal:\n\n```bash\nnpx cvmi discover\n```\n\nThat is useful for anyone. Users and agents can browse what is available. Developers can verify that their servers are visible. Builders can inspect the public surface of the network without extra tooling.\n\nDiscovery becomes part of the protocol experience itself, not something bolted on from outside.\n\n## Call remote tools without extra ceremony\n\n`cvmi call` handles the next step: actually using a remote service.\n\nYou can inspect a server:\n\n```bash\nnpx cvmi call <server>\n```\n\ninspect a specific tool:\n\n```bash\nnpx cvmi call <server> <tool> --help\n```\n\nand invoke it directly:\n\n```bash\nnpx cvmi call <server> <tool> key=value\n```\n\nThis is powerful because it serves several roles at once.\n\nFor developers, it is a practical debugging surface for remote servers. You can list exposed tools, inspect expected inputs, try requests manually, and read results without building a custom client first.\n\nFor agents and automations, it is a narrow and scriptable interface that fits naturally into shell workflows.\n\nFor users, it is a simple way to interact with a remote service from the terminal.\n\nAnd this is only part of what CVMI is becoming, it already exposes commands such as `serve`, `use`, and `add`, which means the same CLI can help you expose a server over Nostr, connect a remote service locally, or install ContextVM skills alongside discovery and direct tool calls.\n\n## Why CVMI fits ContextVM so well\n\nThese new commands matter because they make ContextVM operationally simple.\n\nContextVM already had the ingredients for a great open model of remote computation: no mandatory third parties involved, permissionless participation, relay-based discovery, and the ability to deploy from small setups instead of needing full hosted infrastructure from day one.\n\nCVMI now gives that model a better interface.\n\nYou can discover services on the network, inspect them from the shell, call them directly, and use the same workflow for debugging, personal use, scripting, or agent integration. That lowers the barrier for everyone who wants to publish tools, experiment with them, or build on top of them.\n\nIn practice, this means you can deploy from the garage and still be reachable worldwide. You can expose tools without building a full traditional and permissioned web stack. You can consume those tools in the way that suits you best: from a terminal, from edge scripts, or inside agent workflows.\n\nThat is what makes this release important. It is not just two more commands. It is ContextVM becoming easier to use in the real environments where people already work.\n\n## Start from here\n\nThe easiest way to see where CVMI is headed is to run it.\n\n```bash\nnpx cvmi\n```\n\nIf you plan to use it often, install it globally and keep it nearby as part of your everyday toolkit:\n\n```bash\nnpm install -g cvmi\ncvmi\n```\n\nFrom there, you can discover public services with `cvmi discover`, call remote tools with  `cvmi call`, expose an already existing MCP server with `serve` (stdio or http) through Nostr, connect to remote server locally with `use`, or install ContextVM skills with `add`. In one CLI, CVMI is starting to cover the path for learning, debugging, publishing, and integration.\n\n## Further reading\n\n- CVMI repository: <https://github.com/ContextVM/cvmi>\n- Google Workspace CLI: <https://github.com/googleworkspace/cli>\n- MCPorter: <https://github.com/steipete/mcporter/blob/main/README.md>\n- Context Mode: <https://mksg.lu/blog/context-mode>\n- CLI vs MCP: <https://kanyilmaz.me/2026/02/23/cli-vs-mcp.html>\n",
+			"created_at": 1773658050,
+			"id": "81d42d8f9d46b49ae87c89a2409dbc58948a5e46278b653577513179da782876",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "05ece10021bd7ab9f9017b6522e4086caeca72b8994d0dde532b1ec7050696fb00320586fd6944033d82eb1a37feef1d458f2cbf554671d0e19a312cf94e97a8",
+			"tags": [
+				[
+					"client",
+					"Yakihonne",
+					"31990:20986fb83e775d96d188ca5c9df10ce6d613e0eb7e5768a0f0b12b37cdac21b3:1700732875747"
+				],
+				["published_at", "1773658050"],
+				["d", "zlzyqFzEtZDfPr3pErWLI"],
+				[
+					"image",
+					"https://image.nostr.build/77cfbb1a15627f247965e2a29af718b20762c1f9cdbb7d3c1ca6cb55354b8052.jpg"
+				],
+				["title", "CVMI the swiss army knife CLI for ContextVM"],
+				[
+					"summary",
+					"CVMI is becoming the command line for that world.\n\nWith the new `discover` and `call` commands, CVMI is no longer only a supporting tool around the ecosystem. It is becoming a direct way to explore the network, inspect remote servers, debug them from the terminal, and integrate ContextVM services into scripts, apps, and agent workflows."
+				],
+				["t", "cli"],
+				["t", "cvm"],
+				["t", "dvm"],
+				["t", "mcp"],
+				["t", "contexvm"],
+				["t", "agents"],
+				["t", "llm"]
+			]
+		},
+		{
+			"content": "*GM people, and welcome to the third issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and all in between!*\n\n*In today's update we cover ephemeral gift wraps, which have been recently merged into the protocol with CEP-19. This feature introduces an optional convention for CVM servers and clients to exchange encrypted messages using an ephemeral gift wrap kind. We also present the latest release family, v0.6.x.*\n\n*We also discuss the latest news from the ecosystem, with a new MCP server to query Wolfram Alpha over Nostr, and the new feature being implemented in the CVM protocol, namely CEP-15, for common tools schema, and CEP-17, which provides a way for a server to publish its relay list.*\n\n*Moreover, we will present a curated list of articles, blog posts, and notes talking about CVM and how it is changing the way we interact with MCP servers.*\n\n*Finally, we will bring the latest news from the MCP ecosystem, including specification changes and new protocol additions. CVM is built on MCP, which means that we care about providing you up-to-date information from its thriving ecosystem.*\n\n*Let's start!*\n\n---\n\n## **News from ContextVM** 📰\n\n*A list of updates, releases and new cool features.*\n\n- **Ephemeral gift wraps are live on CVM**: We recently merged\n    [CEP-19](https://github.com/ContextVM/contextvm-docs/blob/master/src/content/docs/spec/ceps/cep-19.md)\n    proposal, which introduces an optional convention for CVM servers and clients to exchange encrypted\n    messages using an ephemeral gift wrap kind. This is a major upgrade that provides more privacy\n    in the communication between servers and clients, since it prevents relays to store the events.\n\n    Consequently, we also open a [PR](https://github.com/nostr-protocol/nips/pull/2245) in the NIPs\n    repository. The proposed modification aims to expand\n    [NIP-59](https://github.com/nostr-protocol/nips/blob/master/59.md) to include the convention for\n    ephemeral gift wraps.\n\n- **A NIP for CVM**: Recently, we opened another [PR](https://github.com/nostr-protocol/nips/pull/2246)\n    on the NIP repository to formalize CVM as a minimal convention for transporting Model Context\n    Protocol (MCP) JSON-RPC messages over Nostr. The proposal is waiting for feedback and reviews from\n    other peers.\n\n- **A new major release family for the CVM SDK**: With the merging of CEP-19, we released a new major\n    version family for the CVM SDK, v0.6.x.\n\n    Notably, [v0.6.0](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#060) integrates support for ephemeral gift wraps, while maintaing compatibility with previous versions. We also released a patch version, [v0.6.1](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#061).\n\n    Previously, we released [v0.5.0](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#050), which\n    added a single `paymentPolicy` hook to make payment consent programmable.\n\n---\n\n## **News from the ContextVM Ecosystem** 🗞️\n\n*Find all the projects leveraging ContextVM on [ContextVM/awesome](https://github.com/ContextVM/awesome).*\n\n- Relatr (nostr:nevent1qqsxzqw884dxrjfdy3ntcjz63gzcfgtz7sll4uqmarat9ytwn2k8g8c9g5yfl) has been\nrunning for more than two weeks without missing a single beat. No crashes, no downtime. It just worked!\n\n- [Wolfram Alpha](https://primal.net/p/npub1w0lf8t44p4575d7g9ly44yalzv4msjqg0d27x8mmt97kt3vqg8ysr5ht7c)\nis now available as a decentralized MCP server through CVM. Ask math, science, weather, conversions\nand more. Connect to the server [here](https://contextvm.org/s/73fe93aeb50d69ea37c82fc95a93bf132bb848087b55e31f7b597d65c58041c9) to test it out!\n\n---\n\n## **What’s Next for ContextVM?** ⏭️\n\n*Let’s take a look at the features currently being implemented!*\n\n- [CEP-15](https://github.com/ContextVM/contextvm-docs/issues/15): This enhancement proposal implements a\nstandard for defining and discovering common tool schema. This aims to enable interoperability between\nmultiple servers, standardizing tool interfaces that clients can recognize and use consistently. It\nleverages MCP's `_meta` field, RFC 8785 for deterministic hashing, and\n[CEP-6 announcements](https://github.com/ContextVM/contextvm-docs/blob/master/src/content/docs/spec/ceps/cep-6.md)\nfor discovery, creating a marketplace where users can choose between multiple providers implementing the\nsame standard tool interface.\n\n- [CEP-17](https://github.com/ContextVM/contextvm-docs/issues/17): This enhancement proposal defines\na relay list mechanism based on [NIP-65](https://github.com/nostr-protocol/nips/blob/master/65.md)\nconventions. Servers can publish the list of relays they are connected to using kind `10002` events,\nallowing clients to discover the appropriate relays for establishing connections. This solves the\ncurrent limitation where users must know both a server's public key and its relay URLs to connect.\n\n---\n\n## **Who is Talking about ContextVM?** 📢\n\n*A curated list of articles, blog posts, and notes about ContextVM and its ecosystem.*\n\n- Our [Hacker News post](https://news.ycombinator.com/item?id=47151294), presenting ContextVM to the\nbroader technical ecosystem. We are actively working to get more eyes on out project!\n\n- CVM has been mentioned on\n[Nostr Compass #11](https://primal.net/a/naddr1qvzqqqr4gupzqa6e2nmnzsgjfzdy520vdy4hywr06c9ue6crpr2zxyq749uu275qqqgr2epex33nqde3xyursdfsx3sngusdfz8)\n, a weekly newsletter covering everything going on in the Nostr ecosystem.\n\n- [Travis Knot](https://primal.net/p/nprofile1qqsyjd2kjy34yrvj08kgh84z5r7759d64k5ewhswltm38lffv9s9m9ssyrpny) wrote an [article](https://primal.net/a/naddr1qvzqqqr4gupzqjf426gjx5sdjfu7ezu752s0m6s4h2k6n967pma0wyla99skqhvkqq2hzcf5w3r8w3r5f9f4jkt9fqurg7r5wd2xgawud0t) describing CVM as a protocol for creating \"permissionless digital lemonade stands\". With\nCVM, you do not need permission to build!\n\n- Our NIP proposal was mentioned in [Nostr Biweekly Review (15-28 Feb 2026)](https://primal.net/a/naddr1qvzqqqr4gupzqavxnnavfdqnx0p29h8vxtstenmds0wy5n0etkm6fs7sjdmgrxv8qq2h2jz9ff5k7mektuenv369gaz9yamwd3xx5xlghkl).\n\n- CVM has been mentioned in the\n[Financial Freedom Report #110](https://primal.net/a/naddr1qvzqqqr4gupzpuvcn2tdwk4rs66vsu25xcnvhvmzcqey3v3qmjdw20tua7724ukpqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qq35v6twv9hxx6tpdsk5vun9v4jx7mfd2fjhqmmjwsknzvfs94u8wvmxvenq9g2l59) by the\n[Human Rights Foundation](https://primal.net/p/nprofile1qqs0rxy6jmt44guxkny8z4pkym9mxckqxfytygxuntjn6l80hj409sgy2hv7w) (HRF).\n\n---\n\n## **News from the MCP world** 🤖\n\n*What is going on in the MCP world?*\n\n- The *Skills-over-MCP* Interest Group is actively working to provide directions and guidelines\non the possibility to provide Skills to agents as MCP resources. Contributors are focusing on\nthe so-called skills-as-instructors, those that teach an agent how to use MCP tools correctly,\nwithout executing any code, with the aim to find a common ground to address distribution, portability,\nsecurity and fragmentation. It is possible to find more information in the\n[meeting notes](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/2248).\n\n---\n\n*Find out more about ContextVM:*\n\n- *Check out our [website](https://contextvm.org/) for documentation, blog posts, and more.*\n- *Join our [Signal](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR) group*\n- *Follow ContextVM on Nostr, nostr:npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm *\n- *Subscribe to our [Substack](https://contextvm.substack.com/). Help us spread the word!*\n- *Check out our GitHub [repositories](https://github.com/contextvm) and leave us a ⭐*",
+			"created_at": 1772552850,
+			"id": "c818662f02719aec772837d83e5b63a725871a03ce5f81505a33af4671ad89d3",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "105ebdef17688ab4d3440af0b960a828d4602d31ed0fe77683b2a02038ff9ac30062812eda40a0934ed996efe7d60fb57c230fd59df5f021a13e54800214acfd",
+			"tags": [
+				[
+					"client",
+					"Yakihonne",
+					"31990:20986fb83e775d96d188ca5c9df10ce6d613e0eb7e5768a0f0b12b37cdac21b3:1700732875747"
+				],
+				["published_at", "1772552850"],
+				["d", "84wfjCtA3PqMen62Olv5t"],
+				[
+					"image",
+					"https://image.nostr.build/9704fd70e8a3dfe2b53cbe727e63818012afeb032d7e30a89d05f96d7d691fdc.jpg"
+				],
+				["title", "Ephemeral Is Better — The ContextVM World #3"],
+				[
+					"summary",
+					"In today's update we cover ephemeral gift wraps, which have been recently merged into the protocol with CEP-19. This feature introduces an optional convention for CVM servers and clients to exchange encrypted messages using an ephemeral gift wrap kind. We also present the latest release family, v0.6.x.\n\nWe also discuss the latest news from the ecosystem, with a new MCP server to query Wolfram Alpha over Nostr, and the new feature being implemented in the CVM protocol, namely CEP-15, for common tools schema, and CEP-17, which provides a way for a server to publish its relay list."
+				],
+				["t", "cvm"],
+				["t", "nip"],
+				["t", "nips"],
+				["t", "ephemeral"],
+				["p", "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8", "", "mention"]
+			]
+		},
+		{
+			"content": "*GM people, and welcome to the second issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and all in between!*\n\n*In today's update we are going to discuss payments on CVM, enabled by CEP-8 specifications. The latest releases of CVM SDK and CVMI have been updated to support this huge milestone.*\n\n*We will also cover the latest features currently being implemented. In particular, we will take a look at CEP-17, which deals with relay lists, and CEP-19, which aims to improve privacy for encrypted communications.*\n\n*We will also present a curated list of articles, blog posts, and notes talking about CVM and how it is changing the way we interact with MCP servers.*\n\n*Finally, we will bring the latest news from the MCP ecosystem, including specification changes and new protocol additions. CVM is built on MCP, which means that we care about providing you up-to-date information from its thriving ecosystem.*\n\n*Let's start!*\n\n## **News from ContextVM** 📰\n*A list of updates, releases and new cool features.*\n\n**ContextVM has received support from [OpenSats](https://primal.net/opensats)**: OpenSats [announced](https://opensats.org/blog/fifteenth-wave-of-nostr-grants) its fifteenth wave of grants from the Nostr Fund. ContextVM is one of the new projects to receive the grant, which will support core protocol development, SDK expansion, and improvements to the reliability of shared infrastructure.\nIt will also allow the team to work on new SDK implementations, create and manage one-click deployment packages, provide comprehensive documentation and tutorials, and integrate CVM with open-source developer tools.\n\n**Payments are finally live on CVM**: With the recent merging of [CEP-8](https://docs.contextvm.org/spec/ceps/cep-8/) specification, anyone running a MCP server can finally monetize its capabilities, allowing for a decentralized and permissionless marketplace of services and tools. Most importantly, it does so without imposing a single (or a set of) payment method(s), but by standardizing the way users ask for payments.\n\nCEP-8 introduces a language called *Payment Method Identifier* (PMI), based on the homonymous [W3C standard](https://www.w3.org/TR/payment-method-id/), that allows to define the specific payment method to be used during the interaction. In other words, PMI is the type-tag for the payment request payload, analogous to content-type in HTTP. For example, a BOLT11 lightning payment will be identified by the string `bitcoin-lightning-bolt11`. Notably, [CEP-21](https://docs.contextvm.org/spec/ceps/informational/cep-21/) has been added to\nprovide recommended naming conventions for new PMIs.\n\n**CVMI latest release**: [v1.10.0](https://github.com/ContextVM/cvmi/blob/main/CHANGELOG.md#0110) for CVMI, the cli tool for CVM, has been recently released. The latest version introduces comprehensive documentation for implementing payments through CEP-8. It also adds support for environment variables to spawned MCP servers and normalizes quoted command strings to serve any MCP server.\n\n**CVM SDK release family 0.4.x**: Starting from v0.4.0, the ContextVM SDK added support for payments through CEP-8. Other patch versions has been released to fix minor issues or include small features, such as payment export and logging and preventing zombie publishing loops. Notably, [v0.4.5](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#045) added support for payments through [NIP-57 Lightning Zaps](https://github.com/nostr-protocol/nips/blob/master/57.md). This is the third payment processor to be supported in CVM, following NWC and [LNBits](https://github.com/ContextVM/sdk/pull/25) implementations.\n\nThe release [v0.4.6](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#046), adds notifications for payment verification based on [NIP-47 NWC](https://github.com/nostr-protocol/nips/blob/master/47.md).\nSince this feature is not supported by all NWC providers, the payment processor will determine compatibility and only enable notifications if the provider supports it.\nBefore publishing v0.4.6, we have released a series of patches which add deduplication capabilities for multi-relay deployments, making the transports more efficient and increasing performances when connected to multiple relays.\n\n## **News from the ContextVM Ecosystem** 🗞️\n*Find all the projects leveraging ContextVM on [ContextVM/awesome](https://github.com/ContextVM/awesome).*\n\nAgents are starting to realize ContextVM exists and are looking for ways to integrate it into their operations. [Clawstr](https://clawstr.com) and [The Colony](https://thecolony.cc/) are two examples of platforms where agents are discussing about the benefits of ContextVM.\n\n## **What’s Next for ContextVM?** ⏭️\n*Let’s take a look at the features currently being implemented!*\n\n[CEP-15](https://github.com/ContextVM/contextvm-docs/issues/15): This enhancement proposal implements a standard for defining and discovering common tool schema. This aims to enable interoperability between multiple servers, standardizing tool interfaces that clients can recognize and use consistently. It leverages MCP's `_meta` field, RFC 8785 for deterministic hashing, and\n[CEP-6 announcements](https://github.com/ContextVM/contextvm-docs/blob/master/src/content/docs/spec/ceps/cep-6.md) for discovery, creating a marketplace where users can choose between multiple providers implementing the same standard tool interface.\n\n[CEP-17](https://github.com/ContextVM/contextvm-docs/issues/17): This enhancement proposal defines a relay list mechanism based on [NIP-65](https://github.com/nostr-protocol/nips/blob/master/65.md) conventions. Servers can publish the list of relays they are connected to using kind `10002` events,\nallowing clients to discover the appropriate relays for establishing connections. This solves the current limitation where users must know both a server's public key and its relay URLs to connect.\n\n[CEP-19](https://github.com/ContextVM/contextvm-docs/issues/19): This enhancement proposal introduces an optional convention for CVM servers and clients to exchange encrypted messages using an ephemeral gift wrap kind. This CEP aims to improve privacy for encrypted communications by establishing a new kind `21059`, similar to kind `1059`, which will not be stored by a relay.\n\n## **Who is Talking about ContextVM?** 📢\n*A curated list of articles, blog posts, and notes about ContextVM and its ecosystem.*\n\nOur [blog post](https://jumble.social/notes/nostr:naddr1qvzqqqr4gupzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqy88wumn8ghj7mn0wvhxcmmv9uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqpqmr9d4hkuctyv5kkcet8v4hxguchwt8dw) providing a simple and fun tutorial to illustrate how the CEP-8 payment flow works. Get your Nostr badge now!\n\nOur [blog post](https://jumble.social/notes/nostr:naddr1qvzqqqr4gupzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqy88wumn8ghj7mn0wvhxcmmv9uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqpwerfva5hgctv94kx2mt0deskgefdwd6xzmnywvldqt6c) on CEP-8 and *Digital Lemonade Stands*.\n\nA [note](https://jumble.social/notes/nostr:nevent1qvzqqqqqqypzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qqs2u23g4wlu63e6pchrfzswu0j5k0er5pc2dyepv8kyule7w763n2q9wzl4z) on our official Nostr profile highlighting the importance of CVM in an agent-mediated world.\n\nA [note](https://jumble.social/notes/nostr:nevent1qvzqqqqqqypzpuk62d950kl7qkq2gt0rkavv49q3n4z76w8ffchehcxp269nr324qythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qqsgdeg2a5maua7cnf425tcfg7lwur7qaqnphsxtc28x3pep20j7p6sg049vd) from MaximumSats\n(nostr:npub17td9xj68m0lqtq9y9h3mwkx2jsge630d8r55utumurq4dze3c42sdav95p), developer of the LNBits processor in the CVM SDK, discussin MCP-to-Nostr bridges.\n\n## **News from the MCP world** 🤖\n*What is going on in the MCP world?*\n\n[PR2127](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2127)\npresents a draft specification, [SEP-2127](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2127/files),\nthat proposes a standardize way to describe MCP servers, called Server Cards.\nThis would allow an MCP client to discover server capabilities using a `.well-known` endpoint, without the need to establish a full connection.\n\n**Note**: This proposal together with the [registry](https://modelcontextprotocol.io/registry/about) specification defines a series of HTTP endpoints attached to specific servers to allow discoverability of MCP servers. In ContextVM, we think this is an anti-pattern, increasing centralization and gatekeeping. We already solved discoverability in\n[CEP-6 (Public Server Announcements)](https://docs.contextvm.org/spec/ceps/cep-6/) where we standarized the usage of relays as decentralized repositories. Servers are free to announce their existence in any number of relays and curation is done directly by the relays. This way, incentives are always aligned without any central point of failure.\n\n[SEP-2133](https://modelcontextprotocol.io/community/seps/2133-extensions) has been officially formalized. This specification establishes a lightweight framework for extending MCP through optional, composable extensions. In particular, it provides guidance on how extensions should be proposed and adopted, and defines both a list of official extensions, developed and\nrecommended by MCP maintainers, and one of experimental ones, for simple discovery, prototyping and collaboration.\n\n[SEP-1730](https://modelcontextprotocol.io/community/seps/1730-sdks-tiering-system) has officially landed, providing a tier system for MCP SDKs. This allows to establish clear expectations for feature support, maintenance commitments, and quality standards. The specification defines a three-tier\nsystem, based on objective, measurable data. In particular:\n\nTier 1: Fully supported. The SDK implements the full protocol and is well supported;\nTier 2: Commitment to be fully supported. The SDK is actively working towrds full support;\nTier 3: Experimental. The SDK is in its early stage.\n\n*Find out more about ContextVM:*\n\n*Check out our [website](https://contextvm.org/) for documentation, blog posts, and more*\n*Join our [Signal](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR) group*\n*Follow ContextVM on Nostr, nostr:npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm*\n*Follow Relatr on Nostr, nostr:npub1w5rgyvpunuxa446egx6fahyagm376vrtnm3nx5ec5gdruszvt73spqeu4t*\n*Check out our GitHub [repositories](https://github.com/contextvm) and leave us a ⭐*",
+			"created_at": 1771343488,
+			"id": "4459a42f69885a145415f4b1f8f16724d9331c882ddabf052558ada635c4389e",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "a94de0ca5872591f8eae3097bf08a9ff7d5772ce72969170a13732f90063654cc8fe8ce2471a495b35653b91e26b0b27d0b6ffaee17a53ed969d16e788b250bc",
+			"tags": [
+				["d", "cvm-world-2"],
+				["title", "The ContextVM World 🌍 — #2"],
+				[
+					"summary",
+					"GM people, and welcome to the second issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and all in between!\n\nIn today's update we are going to discuss payments on CVM, enabled by CEP-8 specifications. The latest releases of CVM SDK and CVMI have been updated to support this huge milestone."
+				],
+				[
+					"image",
+					"https://image.nostr.build/4ab9910c783112f2b6813e571a8a0ff8e90909e7de709f73df315ee2f029e030.jpg"
+				],
+				["published_at", "1771343417"],
+				["t", "cvm"],
+				["t", "dvm"],
+				["t", "mcp"],
+				["t", "nostr"],
+				["t", "agents"],
+				[
+					"a",
+					"30023:6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8:lemonade-legends",
+					"wss://nos.lol/"
+				],
+				[
+					"a",
+					"30023:6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8:digital-lemonade-stands",
+					"wss://nos.lol/"
+				],
+				[
+					"e",
+					"ae2a28abbfcd473a0e2e348a0ee3e54b3f23a070a6932161ec4e7f3e77b519a8",
+					"wss://search.nos.today/",
+					"",
+					"6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8"
+				],
+				["p", "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8", ""],
+				[
+					"e",
+					"86e50aed37de77d89a6aaa2f0947beee0fc0e8261bc0cbc28e68872153e5e0ea",
+					"wss://search.nos.today/",
+					"",
+					"f2da534b47dbfe0580a42de3b758ca94119d45ed38e94e2f9be0c1568b31c555"
+				],
+				["p", "f2da534b47dbfe0580a42de3b758ca94119d45ed38e94e2f9be0c1568b31c555", ""],
+				["p", "750682303c9f0ddad75941b49edc9d46e3ed306b9ee3335338a21a3e404c5fa3", ""]
+			]
+		},
+		{
+			"content": "This is a small, fun, and simple teaching project: a ContextVM server with one paid tool to mint and sell Nostr badges (NIP-58), and one free tool to get stats, designed to illustrate the new **CEP-8 payments** flow without distractions.\n\nYou'll see how CEP-8 turns \"pay before execute\" into a predictable middleware pattern: advertise a priced capability, compute a per-request quote, request payment, verify settlement, and handle everything about the payment flow.\n\nFor this project we put together a [ContextVM server](https://github.com/ContextVM/lemonade-legends) that sells a **NIP-58 badge** using **CEP-8 payments**, and a [Svelte web app](https://github.com/ContextVM/lemonade-legends-site) that uses the server and creates a UI for payments. The cool part: the server can be used either via a UI for humans or by an LLM agent via an MCP client—but the focus of this post is to provide an educational example of what CEP-8 brings.\n\nTo keep the example concrete, and demonstrate dynamic price resolution, the price follows a tiny time-based rule: **21 sats** on day 0, then **+21 sats/day**.\n\nBoth the [server](https://github.com/ContextVM/lemonade-legends) and the [web app](https://github.com/ContextVM/lemonade-legends-site) are open source (MIT) and available for you to study, fork, or reuse. We built this project using the [CVM skills](https://github.com/ContextVM/cvmi/tree/main/skills) we released recently, which made it straightforward to create the server, set up the payment middleware, and wire up the Svelte UI.\n\nIn this post you'll see how to:\n\nMark a tool as priced.\n\nCompute a final per-request quote with `resolvePrice`.\n\nGate execution using payments middleware `withServerPayments()`).\n\nAdd an accountability layer with a tiny SQLite ledger (anti-double-mint + stats) `badge_awards`).\n\n## What you’ll build\nLemonade Legends exposes two tools:\n\nA paid tool, `mint_badge`, that issues a NIP-58 badge award event to the caller.\n\nA free tool, `stats`, that shows issuance stats and current pricing.\n\nThe “fun experiment” twist is time-based pricing:\n\n**Opening price:** 21 sats\n\n**Daily increment:** +21 sats/day\n\nThat gives you a dynamic quote that’s deterministic and easy to explain.\n\nIn code, the pricing model is quite simple: `getCurrentPrice()` depends on `getDaysElapsed()`, and those are anchored to a server opening timestamp.\n\nThe more interesting part is *where* that quote gets applied: inside CEP-8's payment gate via `resolvePrice`.\n\n## CEP-8 in one breath (what the SDK implements)\nCEP-8 defines a minimal contract:\n\nThe server declares certain capabilities as priced.\n\nWhen a client calls one, the server emits `notifications/payment_required` instead of executing it.\n\nThe client pays the opaque `pay_req` using a handler for the negotiated PMI.\n\nThe server verifies and emits `notifications/payment_accepted`.\n\nOnly then does the server forward the original request to the underlying tool.\n\nIn the TypeScript SDK, payments are middleware wrappers—so you don’t rewrite transports; you wrap them.\n\nServer wrapper: `withServerPayments()`\n\nClient wrapper: `withClientPayments()`\n\n## Prerequisites (for running this repo)\n\nBun\n\nA Lightning Address in `LN_ADDRESS`\n\nRun it like:\n\nbun install\n\nLN_ADDRESS=you@wallet.example bun run index.ts\n\n## Step 1: define a priced capability (advertise what costs money)\nFirst, the server advertises that calling `tools/call` on `mint_badge` requires payment.\n\nThat's the `pricedCapabilities` array:\n\nconst pricedCapabilities: PricedCapability[] = [\n\n{\n\nmethod: \"tools/call\",\n\nname: \"mint_badge\",\n\namount: OPENING_PRICE,\n\nmaxAmount: OPENING_PRICE + 365 * DAILY_INCREMENT,\n\ncurrencyUnit: \"sats\",\n\ndescription: `Mint a \"${BADGE_NAME}\" badge. Price starts at ${OPENING_PRICE} sats and increases by ${DAILY_INCREMENT} sats each day!`,\n\n},\n\n];\n\nTwo details matter:\n\nThe advertised `amount` is discovery. It helps clients and UIs show a price, but it’s not the final quote.\n\n`maxAmount` is an honesty bound. It communicates “this won’t surprise you beyond this ceiling,” and gives clients something to reason about.\n\n## Step 2: dynamic price resolution (compute the final quote)\nIn this experiment, the quote is time-based. The quote happens in `resolvePrice`, which runs *at the payment gate*, before the tool executes. We also check if the user has already minted a badge and reject the request if so—demonstrating how price resolution can be integrated with your business logic.\n\nconst resolvePrice: ResolvePriceFn = async ({ clientPubkey }) => {\n\nconst currentPrice = getCurrentPrice();\n\nconst pricingInfo = getPricingInfo();\n\nif (hasExistingAward.get(clientPubkey)) {\n\nreturn {\n\nrejected: true,\n\namount: currentPrice,\n\nreason: \"You already have the badge!\",\n\n};\n\n}\n\nreturn {\n\namount: currentPrice,\n\ndescription: `Day ${pricingInfo.daysElapsed} price: ${currentPrice} sats`,\n\n_meta: {\n\ndaysElapsed: pricingInfo.daysElapsed,\n\nopeningDate: pricingInfo.openingDate,\n\n},\n\n};\n\n};\n\nThis is where CEP-8’s separation of concerns becomes practical:\n\nThe *capability declaration* says “this is priced.”\n\nThe *quote callback* says “this is what it costs right now.”\n\nYou can swap the pricing logic without touching transports, tool handlers, or client code.\n\n### Reject without charging (accountability at the payment gate)\nThe experiment includes a “no duplicates” policy: if you already have the badge, the server refuses to sell you another.\n\nThat's implemented by querying SQLite (see `hasExistingAward`) and returning a rejection object from `resolvePrice`.\n\nIn CEP-8/CEP-21 terms, this is the “reject without charging” branch: don’t mint an invoice, don’t take money, and don’t forward the request.\n\n## Step 3: configure a payment processor (how settlement happens)\nThe server still needs a concrete way to ask for payment and verify it.\n\nIn this repo, that's a Lightning Address based processor: `LnBolt11ZapPaymentProcessor`, configured via `LN_ADDRESS`.\n\nconst paymentProcessor = new LnBolt11ZapPaymentProcessor({\n\nlnAddress: LN_ADDRESS,\n\n});\n\nIf you use a different processor (NWC / LNbits / your own custom processor), the rest of the CEP-8 flow stays the same: a processor issues a `pay_req`, later verifies it, and the middleware gates execution.\n\n## Step 4: wrap the transport (turn a server into a paid server)\nThe base server transport is Nostr-native and injects the caller's pubkey for us: `injectClientPubkey: true`. We inject the pubkey so the tool can use it to mint the badge to the correct recipient.\n\nconst baseTransport = new NostrServerTransport({\n\nsigner,\n\nrelayHandler: SERVER_RELAYS,\n\nserverInfo: {\n\nname: \"Lemonade Legends Badge Server\",\n\nwebsite: \"[https://lemonade.contextvm.org](https://lemonade.contextvm.org)\",\n\n},\n\ninjectClientPubkey: true,\n\n});\n\nThen we gate it:\n\nconst paidTransport = withServerPayments(baseTransport, {\n\nprocessors: [paymentProcessor],\n\npricedCapabilities,\n\nresolvePrice,\n\n});\n\nThat wrapper is the line between “free tool” and “paid capability.”\n\n## Step 5: implement the tool (mint the badge after payment)\nBadges are perfect for demos because they’re public, inspectable artifacts.\n\nLemonade Legends publishes two kinds of events:\n\nBadge Definition (kind 30009) via `createBadgeDefinitionEvent()`\n\nBadge Award (kind 8) via `createBadgeAwardEvent()`\n\nOnce signed and published `signAndPublishEvent()`), the result is a verifiable public record that the capability was fulfilled.\n\nThe paid tool itself is registered at `server.registerTool(\"mint_badge\", ...)`. Notice how it relies on injected identity instead of trusting user input:\n\nIt reads the caller pubkey from `_meta` `_meta?.clientPubkey`).\n\nIt publishes the badge award.\n\nIt stores a record in SQLite.\n\n## End-to-end flow (request → quote → pay → mint)\nHere’s the lifecycle you can keep in your head:\n\nClient calls `tools/call` → `mint_badge`.\n\nPayments middleware matches it against `pricedCapabilities`.\n\nThe server calls `resolvePrice` to compute the quote (and possibly reject).\n\nIf accepted, the server emits `notifications/payment_required` with a PMI-scoped `pay_req`.\n\nA compatible client pays using its handler.\n\nThe server verifies settlement via `paymentProcessor`.\n\nOnly then does the call reach `mint_badge` and mint the badge.\n\nThe server records the award in SQLite `insertAward.run(...)`).\n\nThat \"verify before forward\" property is the backbone of CEP-8: priced calls fail closed.\n\n## The dual API: humans via UI, agents via MCP\nOne of the most interesting aspects of this experiment is how the same capability can be accessed through two completely different interfaces—without the server knowing or caring which path the request took.\n\n### The human path: UI-only payment handler\nThe companion website at `lemonade.contextvm.org`]([https://lemonade.contextvm.org](https://lemonade.contextvm.org)) demonstrates a pattern that's particularly useful for consumer-facing applications: the **UI-only payment handler**. Instead of requiring users to configure a wallet or understand NWC connection strings, the site implements a handler that bridges the CEP-8 payment flow with a responsive Svelte UI.\n\nThe implementation lives in `createUiOnlyPaymentHandler()`, which creates a payment handler that:\n\nIntercepts the `notifications/payment_required` message from the server\n\nRenders a payment dialog with the Lightning invoice QR code\n\nPolls for payment completion in the background\n\nResolves the promise once settlement is confirmed\n\nimport { withClientPayments } from '@contextvm/sdk/payments';\n\nimport { createUiOnlyPaymentHandler } from '$lib/payments/payments-ui.svelte';\n\nconst transport = withClientPayments(baseTransport, {\n\n\thandlers: [createUiOnlyPaymentHandler()]\n\n});\n\nThis pattern is powerful because it allows you to build rich, responsive UIs around paid capabilities. The user sees a clean interface with real-time payment status, while the underlying CEP-8 protocol remains unchanged. The server emits the same `notifications/payment_required`, the handler responds with the same settlement proof—everything else is presentation layer.\n\n### The agent path: MCP with payments\nThe same `mint_badge` tool can be called by an LLM agent using a CVM client with payments configured. The agent doesn't need a UI; it needs a payment handler that can settle invoices programmatically—perhaps via NWC, LNbits, or any other automated Lightning backend.\n\nconst agentTransport = withClientPayments(baseTransport, {\n\nhandlers: [nwcPaymentHandler], // Automated settlement\n\n});\n\n// The agent can now call mint_badge just like any other tool\n\nconst result = await client.callTool('mint_badge', {});\n\nThe beauty here is **interface parity**. Whether the caller is a human or an agent, the capability behaves identically:\n\nThe same price resolution logic runs\n\nThe same payment verification occurs\n\nThe same badge gets minted\n\nThe same SQLite record gets written\n\nThis is what we mean by a **dual API**: one capability, multiple access patterns.\n\n## Key takeaways you can reuse\n\n**Priced capability declaration** is the discovery surface `pricedCapabilities`).\n\n*`resolvePrice` is where you quote** (dynamic pricing, conversion, quotas, eligibility) `resolvePrice`).\n\n**Middleware gates execution**—your tool handler stays focused on business logic `withServerPayments()`).\n\n**SQLite makes policy enforceable** (eligibility + audit trail) without inventing a new system `badge_awards`).\n\n## Build on ContextVM\nLemonade Legends is just one example of what you can build with ContextVM. Whether you're creating paid tools, public infrastructure, or agent-to-agent services, CEP-8 gives you a standard way to handle payments without reinventing the wheel.\n\n**Get started**: [contextvm.org](http://contextvm.org)\n\n**Read the docs**: [docs.contextvm.org](http://docs.contextvm.org)\n\n**Explore the code**: [Server](https://github.com/ContextVM/lemonade-legends) · [Web App](https://github.com/ContextVM/lemonade-legends-site)\n\nWe'd love to see what you build 💛",
+			"created_at": 1771261335,
+			"id": "7ac2874aad04232223750d10538ffa2595665e3758c776a9061d24292eab7b4c",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "52ab6d1cebe75fd128ce2f649b1b30ae6d731748661f83e22cd0193a46d8949c8efcac490699d679ed73bf7d828fc65a5a4c2397480b85cd6cc5ea6002935d93",
+			"tags": [
+				["d", "lemonade-legends"],
+				["title", "🍋Lemonade Legends🍋"],
+				[
+					"summary",
+					"This is a small, fun, and simple teaching project: a ContextVM server with one paid tool to mint and sell Nostr badges (NIP-58), and one free tool to get stats, designed to illustrate the new CEP-8 payments flow without distractions."
+				],
+				[
+					"image",
+					"https://blossom.band/26e065e8a530483555075dd623fba9fc15333c807fa29a229c15945bbd5948d8.png"
+				],
+				["published_at", "1771261146"]
+			]
+		},
+		{
+			"content": "Finally, payments are here! 🚀\n\nYou can publish software that other people (or agents) can call, but getting paid usually means stepping back into the old world: accounts, gatekeepers, geography, and payment rails that don't compose. L402/X402 are great standards, but are still tied to HTTP.\n\nContextVM set out to change the _shape_ of collaboration: services addressed by public keys, routed over relays, all done in a permissionless way. We’ve written before about why that matters for censorship-resistance and sovereign infrastructure.\n\nNow we’re adding the missing economic primitive.\n\n**CEP-8 (Capability Pricing and Payment Flow) makes “digital lemonade stands” real**: paid, permissionless capabilities that can be run by anyone, discovered by anyone, and consumed by humans or agents—without a centralized registry and without forcing a single payment system on the entire ecosystem.\n\n“Lemonade stand” doesn’t mean “toy.” It means _sovereign commerce at the edge_: the ability to expose anything from a single tool to a serious production service, and get paid per interaction, without asking anyone for permission.\n\nThis post is an announcement, not a full guide. The goal is to explain _why_ CEP-8 looks the way it does, what it unlocks, and how the SDK integrates payments without bloating transports or breaking existing deployments.\n\n## The core idea: paid, structured interaction—without permission\n\nWhen people hear “payments,” they often imagine a monolith: one platform, one processor, one set of rules. That model doesn’t survive contact with the real world.\n\nReal networks are messy:\n\n- some calls are stateful, some are stateless\n\n- some providers want fixed prices, others want dynamic quotes\n\n- some payment methods are invoice-based, others are bearer assets\n\n- relays can duplicate or reorder messages\n\n- many different payment methods exist\n\nCEP-8 embraces this chaos instead of hiding it.\n\nIt gives ContextVM a **minimal, robust lifecycle** for paid capability invocations, and it does so in a way that preserves the permissionless nature of the protocol.\n\nThe mechanism has three pillars:\n\n1. **Discovery pricing `cap` tags)**: servers can advertise _reference_ prices for capabilities.\n\n2. **Compatibility negotiation `pmi` tags)**: clients and servers advertise which payment methods they can speak.\n\n3. **A notification flow**: the server requests payment, the client pays, the server verifies, then the request is fulfilled.\n\nAll of that is specified in [CEP-8]([https://docs.contextvm.org/spec/ceps/cep-8/](https://docs.contextvm.org/spec/ceps/cep-8/)).\n\n## PMIs are “universal settlement plug-ins”\n\nThe most important design decision in CEP-8 is that **the payment request itself is opaque**.\n\nThe protocol doesn’t standardize “Lightning invoices,” “Cashu proofs,” “credit card sessions,” or whatever comes next. Instead, CEP-8 standardizes _how to ask for payment_, _how to correlate it to the call_, and _how to agree on the language of settlement_.\n\nThat language is the **Payment Method Identifier (PMI)**, based on the W3C standard with the same name.\n\nIn CEP-8 terms:\n\n- `pmi` is the type tag.\n\n- `pay_req` is the payload.\n\n- the meaning of `pay_req` is **PMI-defined**.\n\nThis is deliberately similar to the way the web uses content-types: you don’t need to standardize every possible payload, you need a reliable way to say _“interpret this blob as X.”_\n\nTogether with CEP-8 we added CEP-21, which provides recommended PMI naming conventions for the ContextVM ecosystem, but it’s explicitly non-normative: you can define your own PMIs when you need new semantics. See [CEP-21]([https://docs.contextvm.org/spec/ceps/cep-21/](https://docs.contextvm.org/spec/ceps/cep-21/)).\n\n### Matching by intersection (how payment rails stay permissionless)\n\nPMIs make payments composable because selection is just compatibility matching:\n\n- clients advertise what they can pay\n\n- servers advertise what they can accept\n\n- the payment rail is chosen from the **intersection**\n\nThat’s not “supporting one payment method.” It’s a matching mechanism that lets many payment methods coexist without fragmenting the protocol.\n\nThis matters for resilience: in a permissionless environment, you don’t want a payment monopoly baked into the protocol.\n\n## The CEP-8 lifecycle: small semantics, big consequences\n\nOnce a capability is priced, CEP-8 defines a simple lifecycle:\n\n1) client calls a capability\n\n2) server responds with a payment required notification\n\n3) client pays using a handler for the specified PMI\n\n4) server verifies settlement and emits payment accepted or payment rejected notifications\n\n5) server fulfills the request\n\nThis is how you get a payment flow that survives the real world.\n\n### Direct bearer payments (saving round trips)\n\nSome payment methods are bearer assets—Cashu, for example—where value can be transferred by attaching a token directly in the request, saving round trips.\n\nCEP-8 includes an optional optimization for this: the `direct_payment` tag. When a PMI supports it, the client can attach a PMI-scoped payload on the original request and skip the invoice round trip.\n\n## Why this matters: the economics of permissionless services\n\nIf you remove centralized identity, centralized discovery, and centralized hosting constraints, you get something powerful—but it still doesn’t sustain itself without an economic loop.\n\nCEP-8 closes that loop in a way that matches ContextVM’s philosophy:\n\n- **no registry required** to monetize a capability\n\n- **no platform account required** to pay or get paid\n\n- **no single rail forced on everyone**\n\n- **no protocol fork** required to add new settlement systems\n\nThis is how you get a world of “digital lemonade stands”: thousands of specialized capabilities, each easy to publish, easy to pay for, and easy to compose into larger workflows.\n\nIn an agent-to-agent world, this isn’t a nice-to-have. It’s the difference between a permissioned economy and an open one.\n\n## Clear roles: processors mint, handlers pay\n\nCEP-8 is deliberately explicit about roles, because it keeps implementations honest and keeps the protocol surface small:\n\n- **Server = payment processor**: it _mints_ a payment request `pay_req`) for a quote, and later _verifies_ that settlement happened.\n\n- **Client = payment handler**: it _interprets_ the `pay_req` (based on `pmi`) and performs the wallet action.\n\nEverything else—how an invoice is created, how settlement is proved, which third-party system is involved—is PMI-scoped and intentionally outside the CEP.\n\n## The SDK: payments as middleware, not as a transport rewrite\n\nWe implemented CEP-8 in the TypeScript SDK with one strong constraint: **payments must be optional and must not bloat transports**.\n\nThat’s why the integration is middleware-first:\n\n- transports keep doing transport things (Nostr event conversion, routing, encryption, correlation)\n\n- payments wrap the message flow at the seam where requests are forwarded\n\nThis allowed us to add paid capabilities without introducing breaking changes. If you don’t enable payments, you shouldn’t pay a performance or complexity tax.\n\nThe SDK exposes this through two simple wrappers:\n\n- `withServerPayments(...)` to gate priced capabilities on the server side\n\n- `withClientPayments(...)` to automatically handle payment requests on the client side\n\n### Built-in rails (same PMI, different “backend”)\n\nThe new version of the SDK ships with two real Lightning BOLT11 integrations, and they both implement the same PMI `bitcoin-lightning-bolt11`). More integrations can be added in the future. Or you can build your own to satisfy your own needs.\n\nThat’s the point: the _PMI is the contract_, not the vendor.\n\n- NWC (NIP-47) processor/handler (wallet-driven)\n\n- LNbits processor/handler (service-driven)\n\nBoth satisfy the same settlement surface. Both can be swapped without changing CEP-8 semantics.\n\nThis is a concrete example of the PMI idea: **the protocol contract stays stable even as the backend changes**.\n\n## Amounts: discovery vs settlement\n\nCEP-8 deliberately separates **price discovery** from **settlement**.\n\nWhen a server advertises pricing, it uses `cap` tags. Think of these as the _menu_: helpful for UX, browsing, and automation.\n\nWhen the server requests payment, it sends `notifications/payment_required` with:\n\n- a final `amount`\n\n- a `pmi`\n\n- an opaque `pay_req` that encodes the real settlement request for that PMI\n\nThe implication is subtle but powerful:\n\n- a server can advertise prices in `usd` for clarity\n\n- and still settle in sats when the chosen PMI is Lightning, for example\n\nThe conversion and quoting logic lives in the server’s dynamic pricing callback.\n\n## Using CEP-8 in the SDK (compact examples)\n\nThese snippets are intentionally lightweight and partially pseudo-code. The goal is to show the _mechanics_ without turning this post into a tutorial.\n\n### 1) Server: fixed pricing + payments gate\n\nConfigure which capabilities are priced, then wrap the transport.\n\n```ts\n\nimport {\n\n  withServerPayments,\n\n  LnBolt11NwcPaymentProcessor,\n\n  type PricedCapability,\n\n} from '@contextvm/sdk/payments';\n\nimport { NostrServerTransport } from '@contextvm/sdk/transport';\n\nconst pricedCapabilities: PricedCapability[] = [\n\n  {\n\n    method: 'tools/call',\n\n    name: 'your_tool',\n\n    amount: 10,\n\n    currencyUnit: 'sats',\n\n    description: 'Example paid capability',\n\n  },\n\n];\n\nconst baseTransport = new NostrServerTransport({ signer, relayHandler });\n\nconst paidTransport = withServerPayments(baseTransport, {\n\n  processors: [\n\n    new LnBolt11NwcPaymentProcessor({\n\n      // ... NWC connection details\n\n    }),\n\n    // Or swap for LNbits without changing CEP-8 semantics.\n\n  ],\n\n  pricedCapabilities,\n\n});\n\n```\n\nWhat matters here isn’t the wallet backend. It’s that the server has a processor that can mint and verify a payment request for the chosen PMI, and the payments layer will fail closed: no paid capability gets forwarded before settlement.\n\n### 2) Server: dynamic pricing + currency conversion with `resolvePrice`\n\nFixed prices are a demo. Real services need quoting.\n\nThe SDK supports a per-request quote callback.\n\n```ts\n\nimport {\n\n  withServerPayments,\n\n  type ResolvePriceFn,\n\n} from '@contextvm/sdk/payments';\n\nconst resolvePrice: ResolvePriceFn = async ({ capability, request }) => {\n\n  // Pseudo-logic: a real quote often depends on the request.\n\n  // Example: charge more for larger inputs, _and_ allow advertising in USD while settling in sats.\n\n  const inputSize = JSON.stringify(request.params ?? {}).length;\n\n  const units = Math.max(1, Math.ceil(inputSize / 1_000));\n\n  // Start from the advertised price.\n\n  const advertised = capability.amount * units;\n\n  // If you advertise in USD for UX, convert here before minting a sats-based invoice.\n\n  const amount =\n\n    capability.currencyUnit === 'usd'\n\n      ? await convertUsdToSats(advertised)\n\n      : advertised;\n\n  return amount;\n\n};\n\nconst paidTransport = withServerPayments(baseTransport, {\n\n  processors: [processor],\n\n  pricedCapabilities,\n\n  resolvePrice,\n\n});\n\n```\n\nThis is a subtle but important CEP-8 principle: *`cap` tags are discovery**, while the payment required amount is the final quote. You can publish a “menu” in one unit and still settle in another.\n\n### 3) Client: pay automatically when required\n\nThe client wraps its transport with `withClientPayments()` and provides one or more handlers.\n\n```ts\n\nimport {\n\n  withClientPayments,\n\n  LnBolt11LnbitsPaymentHandler,\n\n  LnBolt11NwcPaymentHandler,\n\n} from '@contextvm/sdk/payments';\n\nimport { NostrClientTransport } from '@contextvm/sdk/transport';\n\nconst baseTransport = new NostrClientTransport({ signer, relayHandler, serverPubkey });\n\nconst paidTransport = withClientPayments(baseTransport, {\n\n  handlers: [\n\n    new LnBolt11NwcPaymentHandler({\n\n      // ... NWC connection details\n\n    }),\n\n    // Other handlers can be added.\n\n  ],\n\n});\n\n```\n\nThe important part: when payments are enabled, the client automatically advertises its supported PMIs to help the server pick a compatible method.\n\n## What to build now\n\nCEP-8 isn’t “payments added.” It’s **a sustainable primitive for permissionless capability markets**.\n\nIf you're building on ContextVM, there are three obvious next steps:\n\n1. **Price one capability** in an existing server—make it a real lemonade stand.\n\n2. **Build a client that can pay** (or an agent that can pay) and start composing paid capabilities into workflows.\n\n3. **Implement a new PMI** if your settlement method isn't covered yet. CEP-8 is designed for pluralism: new rails should not require new transports.\n\nSpecifications:\n\n- [CEP-8]([https://docs.contextvm.org/spec/ceps/cep-8/](https://docs.contextvm.org/spec/ceps/cep-8/))\n\n- [CEP-21]([https://docs.contextvm.org/spec/ceps/cep-21/](https://docs.contextvm.org/spec/ceps/cep-21/))\n\nThe frontier is open. Build a stand. Price a capability. Let value flow where computation happens.\n\n",
+			"created_at": 1770909387,
+			"id": "859fb116fdd5636ea4c66dc5abbb4b3b2a2a4611a424bff54d4018ba98970b5a",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "92715f0dfb63a9067b6a24e2038adccd7cdd3be4cb3a408151c713b8eaa55e923f6312a7020be1843543e950659d89d729e0579f32a7b23e4e50570cc530835d",
+			"tags": [
+				["d", "digital-lemonade-stands"],
+				["title", "Digital Lemonade Stands"],
+				["published_at", "1770909387"],
+				[
+					"image",
+					"https://blossom.band/e5137529fe072b34ff33a294ff7533d4bc073b2a7bc5eb326b8cd52545eb52f5.png"
+				],
+				["summary", "Finally, payments are here! 🚀"],
+				[
+					"alt",
+					"Digital Lemonade Stands - read it in https://habla.news/u/_@contextvm.org/digital-lemonade-stands"
+				],
+				["client", "Habla"]
+			]
+		},
+		{
+			"content": "# **The ContextVM World** 🌍 **— #1**\n\n*GM people, and welcome to the first ever issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and all in between!*\n\n*In our updates we will bring you the latest information about CVM and its ecosystem, with a particular focus on projects, services, and companies leveraging it for their infrastructure.*\n\n*We will also present a curated list of articles, blog posts, and notes talking about CVM and how it is changing the way we interact with MCP servers.*\n\n*Finally, we will bring the latest news from the MCP ecosystem, including specification changes and new protocol additions. CVM is built on MCP, which means that we care about providing you up-to-date information from its thriving ecosystem.*\n\n*Let's start!*\n\n---\n\n## **News from ContextVM** 📰\n\n*A list of updates, releases and new cool features.*\n\n- The new [v0.2.x](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#020) family release of the ContextVM SDK has been [announced](https://jumble.social/notes/nevent1qvzqqqqqqypzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qyt8wumn8ghj7am0w3ezuun9d3shgu3w0puh5tcqyrpfja5kcfxgzws0mezugr5zzpz53ps54m5gj9tvh8e4zs6rpkeww5jfu5a) on Wednesday 21st, focusing on reliability, code quality, and architectural maturity. This release transforms ContextVM from a functional prototype into a hardened foundation ready for long-running servers. While this release lays the groundwork for future enhancements, it provides backward compatibility with the previous release to allow for a smooth transition. We recommend upgrading any production environment to v0.2.x to benefit from the reliability improvements on relay handling and memory management.\n- We [announced](https://primal.net/e/nevent1qqstsfzpmt7m2te8a5xfzdy6s93utgtejmujqcvxcrnffeljkhtm9fc7320y5) the release of [ContextVM Interface](https://github.com/contextvm/cvmi) (CVMI), a CLI tool that aims to simplify development on ContextVM. The tool comes with a complete set of [agent skills](https://agentskills.io/home) that cover the entire stack, from protocol fundamentals to production deployment. CVMI will soon become the go-to toolkit for everything related to CVM development, superseding older tools and integrating new features.\n- Today we consolidated the old gateway-cli and proxy-cli tools into CVMI, simplifying the installation and configuration process. Two commands were introduced, `serve` to allow anyone to serve any MCP server over Nostr, even remote HTTP ones, and `use` to leverage remote servers as if they were local. Both new commands work out of the box with ephemeral keys and default relays, with the possibility to customize the setup.\n- We [announced](https://jumble.social/notes/nevent1qvzqqqqqqypzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qpqymaslej2jq4ahkpgljm24c8a2nce7rekf9tddlf2mhkgkljav8rqf66s7l) the release family [v0.3.x](https://github.com/ContextVM/sdk/blob/master/CHANGELOG.md#030), following improvements to the gateway module. This component now allows users to expose remote HTTP MCP servers over Nostr.\n\n---\n\n## **News from the ContextVM Ecosystem** 🗞️\n\n*Find all the projects leveraging ContextVM on [ContextVM/awesome](https://github.com/ContextVM/awesome).*\n\n- Following our recent introduction of [Trusted Assertions](https://jumble.social/notes/nevent1qvzqqqqqqypzq3svyhng9ld8sv44950j957j9vchdktj7cxumsep9mvvjthc2pjuqy88wumn8ghj7mn0wvhxcmmv9uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqzpzvx2l22ycvmuzmvtq5ntjmsw0hxfxj4e8zkrj43fgydte6a3r0a8p09qu) on Relatr, the specification has been officially merged in the Nostr protocol under [NIP-85](https://github.com/nostr-protocol/nips/blob/master/85.md). This NIP allows users to offload Web-Of-Trust calculations, which require a huge amount of events and computational power, to declared trusted service providers, and for these providers to publish signed \"Trusted Assertion\" events for the client consumption. We published a [blog](https://contextvm.org/blog/trusted-assertions-in-relatr) post talking about the details of this integration in Relatr, and how request/response pattern and TAs are complementary.\n- [Relatr v0.1.16](https://github.com/ContextVM/relatr/releases/tag/v0.1.16): Implemented relay capping and updated rate limit token defaults for better burst capacity. Upgraded to the latest version of the ContextVM/SDK.\n- [wotrlay v0.2.5](https://github.com/ContextVM/wotrlay/releases/tag/v0.2.5): The web-of-trust Nostr relay implementation has been updated, bringing various improvements such as better error handling and enhanced observability.\n- In a recent conversation with Pete Winn ( nostr:npub1jss47s4fvv6usl7tn6yp5zamv2u60923ncgfea0e6thkza5p7c3q0afmzy ), the creator of nanalytics, a plethora of experiments over CVM, and games over Nostr like [Word5](https://word5.otherstuff.ai/), we learned that his CVM servers are currently receiving thousands of requests. Here, CVM acts as the imperceptible backbone of these applications. Good technology is invisible. On our side, Relatr is also receiving a high load of requests each day. This kind of load allows us to stress-test CVM and reveal bugs. All the gathered information is currently being used as the foundation for release family 0.2.x, which makes long-running servers with loads of requests stable and performant. CVM is still young and is maturing, becoming more stable and resilient in each iteration.\n- [Earthly.city](https://github.com/zeSchlausKwab/earthly) is a project leveraging CVM for its integration with geographical data. [The server is public](https://contextvm.org/s/ceadb7d5b739189fb3ecb7023a0c3f55d8995404d7750f5068865decf8b304cc) and you can use it as well. \n- More and more projects are currently joining the CVM world. If you are building something on top of CVM, please just let us know! We will be happy to assist, and include you in this newsletter.\n\n---\n\n## What’s Next for ContextVM? ⏭️\n\n*Let’s take a look at the features currently being implemented!*\n\n- [CEP-8](https://github.com/ContextVM/contextvm-docs/issues/8): This enhancement proposal provides a standardized pricing mechanism and payment flow for MCP capabilities over CVM. This would allow servers to advertise pricing for their services, and enable clients to discover and pay for MCP capabilities.\n- [CEP-15](https://github.com/ContextVM/contextvm-docs/issues/15): This enhancement proposal implements a standard for defining and discovering common tool schema. This aims to enable interoperability between multiple servers, creating a marketplace of service providers using the same tool interface.\n\n---\n\n## **Who is Talking about ContextVM?** 📢\n\n*A curated list of articles, blog posts, and notes about ContextVM and its ecosystem.*\n\n- [Say WOT — Ep. 2](https://fountain.fm/episode/emFUU2tGnuiGRRu0Q27W): Avi Burra from Plebchain Radio sits down with Gzuuus to discuss CVM and the Web-Of-Trust tech stack.\n- What’s next for [Relatr](https://jumble.social/notes/nevent1qvzqqqqqqypzqagxsgcre8cdmtt4jsd5nmwf63hra5cxh8hrxdfn3gs68eqycharqythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qyfhwumn8ghj7mmxve3ksctfdch8qatz9uqzpweq8w0cg643dtxsgetv4fpvp7hqx8jg300c4fpf55plxqan36e4z4p258)?\n- An interesting [note](https://jumble.social/notes/1939f1ca9ec3e088b6964915cb573b8036e801e9e9cc39b4413b81bb37350fdb) about [earthly.city](https://github.com/zeSchlausKwab/earthly), a project leveraging CVM.\n- [Trusted Assertion in Relatr](https://contextvm.org/blog/trusted-assertions-in-relatr)\n- [SEC-05: YOLO Report](https://jumble.social/notes/naddr1qvzqqqr4gupzpq7enxs5scju854msxd0xpjvpa4p94763rmgktrfyg0n5arpw8geqythwumn8ghj7um9v9exx6pwdehhxtn5dajxz7f0qqthxetr95cr2ttedakx7ttddajx2ttjv4cx7un52ycmyz)\n\n---\n\n## **News from the MCP world** 🤖\n\n*What is going on in the MCP world?*\n\n- MCP maintainers [announced](https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/) the release of MCP Apps, an official MCP Extension that allows any tool to return interactive UI components, such as dashboards, forms, and workflows, all rendered directly in the conversation. As of today, MCP Apps are already available in Goose, Claude, VS Code, and ChatGPT.\n- A new functionality called “[Tool search tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool)” is available in beta through the Claude APIs. This tool allows servers to reduce token usage by enabling dynamic tool discovery and the possibility to load them on-demand, thus reducing context window consumption and improving tool selection.\n- In a recent [blog post](https://blog.modelcontextprotocol.io/posts/2025-12-19-mcp-transport-future/) about the future of MCP transports, [Kurtis Van Gent](https://github.com/kurtisvg) and [Shaun Smith](https://github.com/evalstate) discussed the advantages of making the MCP protocol stateless. Interestingly enough, CVM added a stateless mode a couple of months ago, allowing efficient communication between clients and servers. Now, the same concepts are coming to the official MCP specifications.\n\n---\n\n*Find out more about ContextVM:*\n\n- *Check out our [website](https://contextvm.org/) for documentation, blog posts, and more.*\n- *Join our [Signal](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR) group*\n- *Follow ContextVM on Nostr, nostr:npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm *\n- *Follow Relatr on Nostr, nostr:npub1w5rgyvpunuxa446egx6fahyagm376vrtnm3nx5ec5gdruszvt73spqeu4t *\n- *Check out our GitHub [repositories](https://github.com/contextvm) and leave us a ⭐*",
+			"created_at": 1770152843,
+			"id": "026223c588bd74d12ab1da1784f070b59c9adcaa0d2ba01b3d835453c73e2a95",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "f5ea0331b7c99461a6a940488a5593b3cd7aba2bcf70d456d55731e4aac1eb0ff1e38ad351fdf8effd148c7b9b303a2f1110660a724d527ad2b920b68898a980",
+			"tags": [
+				[
+					"client",
+					"Yakihonne",
+					"31990:20986fb83e775d96d188ca5c9df10ce6d613e0eb7e5768a0f0b12b37cdac21b3:1700732875747"
+				],
+				["published_at", "1770138385"],
+				["d", "the-contextvm-world-1"],
+				[
+					"image",
+					"https://blossom.band/9ffc2f74143d9208d03f87f5ec509d4b231f50d1f4a6112e1494f45d8173746a.jpg"
+				],
+				["title", "The ContextVM World 🌍 — #1"],
+				[
+					"summary",
+					"GM people, and welcome to the first ever issue of \"The ContextVM World\", your biweekly appointment to discover everything you need to know about ContextVM, MCP, Nostr, and all in between!"
+				],
+				["t", "nostr"],
+				["t", "mcp"],
+				["t", "dvm"],
+				["t", "cvm"],
+				["p", "94215f42a96335c87fcb9e881a0bbb62b9a795519e109cf5f9d2ef617681f622", "", "mention"],
+				["p", "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8", "", "mention"],
+				["p", "750682303c9f0ddad75941b49edc9d46e3ed306b9ee3335338a21a3e404c5fa3", "", "mention"]
+			]
+		},
+		{
+			"content": "If you’ve spent time building or using Nostr clients, you’ve felt the tension.\n\nOn one hand, Nostr is open by design: anyone can join, anyone can publish, anyone can run infrastructure. That openness is the point.\n\nOn the other hand, open networks don’t come with a built-in answer to practical questions clients must solve every day:\n\nWho should I see first?\n\nWhich profiles look established?\n\nHow do I discover accounts beyond my immediate graph?\n\nHow do I search without trusting a single gatekeeper?\n\nIn other words: Nostr is a free ocean. But even free oceans need maps to navigate them.\n\nRelatr exists to produce those maps—ranks, search, and other computation that helps clients navigate a permissionless network—without turning the mapmaker into an authority. With the new Trusted Assertions (TA) feature, relatr adds a second, complementary way to deliver those signals to Nostr: not only as real-time request/response, but also as published events anyone can fetch from relays.\n\nThis post introduces TA in relatr, why we implemented it, and why we think the combination of TA + request/response is the right shape for decentralization.\n## TA, explained like you’re building a client\n\nTrusted Assertions (TA) is an emerging standard in Nostr described by [NIP-85](https://nostrhub.io/naddr1qvzqqqrcvypzq3svyhng9ld8sv44950j957j9vchdktj7cxumsep9mvvjthc2pjuqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsqyn5wf6hxar9vskkzumnv4e8g6t0deesu5l7ne). In practice, it defines a way for a service to publish an assertion about a pubkey as a Nostr event—so clients can retrieve it later from relays, and allows users to define which providers they trust.\n\nYou can think of it as the difference between these two workflows:\n\n- **Request/response:** “Hey server, what is Alice’s rank right now?”\n- **TA publication:** “The server already published its latest statement about Alice; I’ll fetch it from relays.”\n\nThat second model matters. When an assertion is published to relays, it becomes easier to cache, easier to distribute, and less dependent on a client being online at the exact moment a computation happens.\n\nTA is already being adopted. Other providers include [Brainstorm](https://straycat.brainstorm.social/), and it’s implemented in the [Amethyst](https://amethyst.social/) client. Relatr is one of the first solutions to adopt TA—and, importantly, the first to integrate TA _together with_ the original request/response pattern.\n## Why relatr implements TA ,_and_, keeps request/response\n\nRelatr now offers two APIs to consume computations from relatr servers:\n\n- **ContextVM-style request/response (req/res):** clients ask for a computation and receive a result immediately.\n- **TA-style producer/consumer:** servers publish assertions to relays; clients query relays to discover what’s available.\n\nThese are not competing interfaces. They are complementary tools for different parts of the problem.\n### Request/response: best for real-time, query-dependent work\n\nRequest/response is ideal when the answer depends on _your specific question right now_.\n\nSearch is the cleanest example. Search queries are dynamic, high-entropy, and user-specific. A producer/consumer model would require “publishing” an essentially infinite space of possible query results ahead of time, which makes no sense. Search needs req/res.\n\nReq/res also fills gaps when TA events are missing. Relays can be unreliable; networks partition; users come and go. When you need a fresh answer, a direct computation path is the escape hatch.\n\nThe req/res model is also how we introduced the feature, so users can enable any Relatr instance that supports the new feature to serve TA in a pure Nostr-native way—no REST APIs or similar required.\n### TA: best for distribution and caching\n\nTA fits naturally into a producer/consumer model:\n\n1) a server computes an assertion (for example, a rank)\n\n2) the server publishes it to relays\n\n3) clients query relays and fetch the latest available assertions\n\nThat model has two strong properties:\n\n- **It’s relay-native.** Clients are already built around querying relays.\n- **Client-side caching becomes straightforward.** The assertion is a retrievable artifact; you can store it, reuse it, and sync it.\n\nRelatr’s TA implementation publishes NIP-85 assertions as Kind 30382 events. The detailed mechanics—persistence, staleness rules, when relatr publishes, and what operators can tune—are covered in the technical spec: [TA.md](https://github.com/ContextVM/relatr/blob/master/TA.md).\n## “Ranks look like social credit” — the objection we take seriously\n\nNumbers can be intimidating. A rank can feel like a verdict.\n\nThat concern is valid when ranking is centralized, global, and imposed—when one service becomes “the score” and everyone is pressured to comply. That is the dark pattern: a single algorithm hardens into a social hierarchy.\n\nRelatr is built to avoid that failure mode.\n\nRelatr is fully open-source, self-hostable, switchable, and designed to be customizable. Users and communities can define their own validations and models to compute ranks. If you don’t like a ranking algorithm, you don’t have to petition for change—you can run a different one.\n\nThis is not a minor implementation detail. It’s the difference between:\n\n- “Someone else decided how I should be judged,” and\n- “I chose (or helped build) the model my community uses—or I opted out entirely.”\n\nTA strengthens this sovereignty story rather than weakening it. TA lets a server publish assertions, but the spec gives users explicit control: users publish Kind 10040 events to authorize which TA providers they trust. This means that you choose who speaks for you—and communities can choose which relatr instance they trust, or run their own.\n## What’s available now (and where to find it)\n\nThis feature is already deployed on the public relatr instance we operate.\n\nThe [relatr.xyz](http://relatr.xyz) website has been upgraded with a new page, `/ta`, that provides a simple interface to:\n\n* manage your TA list\n\n* enable relatr servers that support TA (including the public instance)\n\nThis release is tagged as version `0.1.11`.\n\nThe goal is to make TA usable without turning it into a power-user ritual. If you’re not interested in protocol details, the experience should still feel intuitive: opt in, publish assertions, and let your client fetch and cache them from relays.\n## Notes for relatr operators\n\nIf you operate a relatr instance today and want to enable TA, you can do it with configuration. The full operator model—how relatr treats TA as a cached computation, what “active” means, and how refresh works—is documented in [TA.md](https://github.com/ContextVM/relatr/blob/master/TA.md).\n\nAt a minimum, TA requires:\n\n- Update to the latest version of Relatr\n- Set `TA_ENABLED=true` in your env\n## Two interfaces, one direction: computation without surrender\n\nNostr clients need computation to navigate an open network. The mistake is assuming computation must be centralized.\n\nRelatr’s approach is to make computation _portable_: open-source, self-hostable, configurable, and integrated with Nostr’s own distribution layer.\n\nContextVM request/response gives you real-time answers when you need them—especially for dynamic queries like search. It also allows you to interact with the provider without leaving Nostr thanks to ContextVM.\n\nTrusted Assertions gives you relay-native distribution and caching for published statements.\n\nTogether, they form a practical toolbox: users and communities can get tailored ranks, powerful discovery, and search, while keeping the power to define—and change—the models that generate those signals.",
+			"created_at": 1767981654,
+			"id": "c8795a0f5858aa7d02d9f948d07f59003f4e0ff5cc9d76e53865abb21dfc5f4e",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "ae2af9e2c3718c90a46f0bf62adc77a118f6d6dd5afc07e0a6acf799b07b5945545a4fdbcf64f23624d27eee8d7e08300f3c4467c6f38d48189ee2583061ab47",
+			"tags": [
+				["d", "trusted-assertions-in-relatr"],
+				["title", "Trusted Assertions in Relatr"],
+				["published_at", "1767981653"],
+				[
+					"image",
+					"https://blossom.band/a60c69e43e99fb7afd04aeb6b9d64baf268379b3ce9be00bb162993421ce735d.jpg"
+				],
+				[
+					"summary",
+					"This post introduces TA in relatr, why we implemented it, and why we think the combination of TA + request/response is the right shape for decentralization."
+				],
+				[
+					"alt",
+					"Trusted Assertions in Relatr - read it in https://habla.news/u/_@contextvm.org/trusted-assertions-in-relatr"
+				],
+				["client", "Habla"]
+			]
+		},
+		{
+			"content": "This article addresses a practical question: when a service lives behind a Nostr pubkey like a DVM or a CVM, what does it mean to \"call it\"?\n\nIn HTTP land, the answer is straightforward: you hit an endpoint, get a response, and parse a contract shaped by OpenAPI docs or SDKs.\n\nOn Nostr, the transport differs, but the need remains the same. You will want a request/response loop that you can reason about, debug, and work with.\n\nThis piece is written for developers first, but it's also meant to close the \"I know Nostr, but I don't know how to _call_ this thing\" gap.\n\nThe thesis is simple: calling a ContextVM server follows the same core pattern as calling a DVM. You publish a signed request event, and listen for a response event. The difference isn't the transport; it's the message carried inside the message.\n## Same loop\n\nIn this case relays works as permissionless message bus. They don't hand you RPC \"for free\", but they give you the primitives to build it: identity (pubkeys), authenticity (signatures), delivery (relays), and correlation (event IDs and tags).\n\nBoth DVMs and CVM turn those primitives into the same loop: send a request to a service pubkey, then accept only responses from that pubkey that reference your request.\n\nWhere integrations diverge is the payload shape and how much of it is standardized.\n## Calling a DVM: kinds and tags (NIP-90)\n\nThe most widely known request/response convention on Nostr is NIP-90, the DVM spec.\n\nThe framing is straightforward: you publish a “job request” in a reserved kind range, providers publish results (and sometimes intermediate feedback), and the client correlates the output back to the request. Optional features exist (payments, encryption, discovery), but they’re not uniformly implemented nor documented, so you often end up handling provider-specific details.\n\nAt a protocol level, the key conventions are: requests live in kinds `5000–5999`, results in `6000–6999`, and the common mapping is “result kind = request kind + 1000”. Job feedback is kind `7000`. Inputs and parameters are often expressed as tags.\n\nHere is a minimal request shape (illustrative, not tied to any specific job kind):\n\n```json\n{\n\n  \"kind\": 5xxx,\n\n  \"content\": \"\",\n\n  \"tags\": [\n\n    [\"i\", \"<data>\", \"text\"],\n\n    [\"param\", \"<key>\", \"<value>\"],\n\n    [\"relays\", \"wss://...\"],\n\n    [\"p\", \"<provider-pubkey>\"]\n\n  ]\n\n}\n```\n\nAnd a minimal result shape:\n\n```json\n{\n\n  \"kind\": 6xxx,\n\n  \"pubkey\": \"<provider-pubkey>\",\n\n  \"content\": \"<payload>\",\n\n  \"tags\": [\n\n    [\"e\", \"<job-request-id>\", \"<relay-hint>\"],\n\n    [\"p\", \"<customer-pubkey>\"]\n\n  ]\n\n}\n```\n\nOperationally, your client publishes the request, then subscribes for results, and kind `7000` feedback. It requires an `e` tag referencing the request event ID, and then parses whatever payload the provider puts into `content`.\n\nThat works. Some useful services exist today with this approach. But...\n### Why DVM integration can feel messy\n\nThis isn’t a criticism of DVMs as an idea. DVMs were an early, important attempt to bring RPC-like behavior into a world built from signed events that fits more naturally in a producer/consumer model.\n\nThe messiness shows up at the “contract boundary”. In practice, you’re often stitching together a contract out of a kind number, a handful of conventions, and provider-defined payloads in `content`. When providers diverge in payload shape, parameter tags, encryption choices, payment signaling, or discovery conventions, integration stops being “call the spec” and becomes “write an adapter”.\n\nThat approach can still work well, especially when a community converges on a small set of providers. But it tends to fragment across the broader ecosystem, and defeats the purpose of decentralization and interoperability.\n## Calling a CVM server\n\nContextVM takes a different approach. It keeps the same transport primitive, nostr events, and relays, but standardizes the payload using MCP.\n\nMCP (Model Context Protocol) is an open standard for how clients talk to servers using JSON-RPC messages. It standardizes capabilities like tools, resources, and prompts, and it comes with a clear, evolving specification. It can also be integrated out of the box with AI systems, rather than being used programmatically to build user interfaces or applications, but that's a topic for another day.\n\nIn CVM, MCP messages are moved through Nostr relays. The server remains an MCP server; the network becomes Nostr, and MCP inherits the benefits of the Nostr protocol.\n\nTwo conventions matter most for client developers. CVM uses a single Nostr kind for messages `25910`), and the `content` field carries a stringified MCP JSON-RPC message.\n\nAddressing and correlation stays the same than DVMs, via tags. Requests tag the server pubkey with `p`. Responses tag the request event ID with `e`.\n## The CVM “Nostr way” recipe\n\nThis is the mental model you can reuse for any CVM server.\n### 1) Discover what the server can do (tools + schemas)\n\nWith DVMs, “what can I call?” is often answered by external docs, repo READMEs, community conventions, or other means.\n\nWith CVM, the server can tell you directly.\n\nIn MCP, you can introspect a server using the `tools/list` method. The response includes tool names, descriptions, and JSON Schemas for inputs (and often outputs). That schema is the contract you can validate against.\n\nYou can list tools in the Nostr way by following the example below, but if you prefer a UI, [https://contextvm.org](https://contextvm.org) is also a convenient inspector: you can paste a server pubkey and browse the same tool definitions.\n### 2) Craft a request event\n\nAt the Nostr level, you publish an event that targets the server pubkey and carries a JSON-RPC message in `content`.\n\nTo list tools:\n\n```json\n{\n\n  \"kind\": 25910,\n\n  \"tags\": [[\"p\", \"<server-pubkey>\"]],\n\n  \"content\": \"{\\\"jsonrpc\\\":\\\"2.0\\\",\\\"id\\\":1,\\\"method\\\":\\\"tools/list\\\",\\\"params\\\":{}}\"\n\n}\n```\n\nTo call a tool:\n\n```json\n{\n\n  \"kind\": 25910,\n\n  \"tags\": [[\"p\", \"<server-pubkey>\"]],\n\n  \"content\": \"{\\\"jsonrpc\\\":\\\"2.0\\\",\\\"id\\\":2,\\\"method\\\":\\\"tools/call\\\",\\\"params\\\":{\\\"name\\\":\\\"<tool-name>\\\",\\\"arguments\\\":{}}}\"\n\n}\n```\n### 3) Listen for a correlated response and parse JSON-RPC\n\nThe server replies with another kind `25910` event that references your request event ID in an `e` tag. Minimal shape:\n\n```json\n{\n\n  \"kind\": 25910,\n\n  \"pubkey\": \"<server-pubkey>\",\n\n  \"tags\": [[\"e\", \"<request-event-id>\"]],\n\n  \"content\": \"{\\\"jsonrpc\\\":\\\"2.0\\\",\\\"id\\\":2,\\\"result\\\":{...}}\"\n\n}\n```\n\nInside `result`, MCP gives you a predictable structure for tool outputs. A tool result can include human-readable `content[]` and machine-friendly `structuredContent`. That duality matters because your code can safely consume structured output and validate against the schema.\n## DVM vs CVM\n\nThink of both as “RPC over Nostr,” but with different organizing principles.\n\nWith DVMs, the job is a _kind_. Your integration typically starts with: “what kind do I publish, and what does the provider put in content?” The response is usually a provider-specific payload blob, and parameters are often tag-shaped.\n\nWith CVM, the job is a _tool name_. Your integration starts with: “what tools does this server expose, and what does the JSON schema require?” The response is JSON-RPC, and structured output is first-class.\n\nThat difference cascades into developer experience. With CVM you can introspect capabilities with `tools/list`, validate inputs, and outputs with JSON Schema, and rely on a consistent JSON-RPC envelope. With DVMs you can absolutely build reliable integrations, but the contract is more often “provider + kind + conventions”, which is harder to reuse across providers.\n\nNone of this invalidates DVMs. It just explains why CVM feels less like “a custom integration” and more like “a reusable interface.”\n### A short note on observability and persistence\n\nOne subtle difference is how much metadata ends up \"hanging off\" kinds.\n\nIn DVM-style flows, job types are encoded in kind ranges, and requests and results are typically regular events that may persist on relays. That can be a feature for auditability, replay, and analytics, but it also increases observability of what's being requested at scale. Encryption can help improve privacy, but DVMs lack a clear encryption convention, so providers either adopt ad hoc approaches or operate in clear text.\n\nIn CVM, message traffic is simplified to a single kind and a structured payload. That doesn't magically make interactions private, but it does keep it consistent and shifts \"what the job is\" away from kind numbers. This can be considered more private since all requests and responses look the same to an external observer. Encryption is also more straightforward: CVM specifies clear procedures for encryption and signaling, encrypting the JSON-RPC payload using NIP-44 and simplified NIP-17, so you can protect interactions without reinventing the wheel.\n## What you actually need to implement\n\nAt minimum, a CVM client needs four basic Nostr capabilities.\n\nFirst, create and sign a Nostr event so the service can trust who is speaking. Second, publish it to a set of relays. Third, subscribe for responses from the service pubkey. Fourth, parse the JSON-RPC message in `content` and handle `result` versus `error`.\n\nThat's the whole loop, and in reality these are fundamental capabilities that any Nostr client needs to implement: sign, publish, subscribe, parse. Everything else is developer experience.\n\nIf \"no SDK\" sounds intimidating, we are also building tooling to make the experience of working with ContextVM frictionless and enjoyable. The TypeScript SDK gives you ready-made client and server plumbing. `ctxcn`, our shadcn-inspired CLI tool, can compile tool schemas into strongly typed client code, so remote tools feel like local functions with typed inputs and outputs. The ContextVM website also serves as an inspector, a debugging tool, and a hub for links to all related docs, repos, and more. Another interesting piece is the gateway component, which lets you expose any existing MCP server written in any language through Nostr.\n\nThere is more tooling, integrations, and features on the way, but if you only take one thing from this article, let it be this: you can call CVMs as you do with DVMs. Indeed, we could argue that a CVM is a kind of DVM. What changes is the shape of the messages. CVM tries to make that contract explicit, introspectable, and consistent. \n## Build on CVM\n\nCVM’s promise is not that it hides Nostr. It’s that it makes Nostr-based RPC legible, and workable.\n\nIf you can already call DVMs, you can call CVM servers today in the same “Nostr way”: events, signatures, relays. The opportunity now is to make this pattern easier for the next developer by shipping libraries, typed clients, monitoring, and debugging tools that treat Nostr-native RPC as a first-class workflow.\n\nThis ecosystem is open-source and community-driven. Every piece of better tooling, docs, or knowledge is a reduction in friction, and every reduction in friction is more decentralization in practice: fewer hidden gatekeepers, fewer platform chokepoints, more sovereign interoperability.\n\nStart here:\n\n[https://contextvm.org](https://contextvm.org)\n\n[https://github.com/contextvm/contextvm](https://github.com/contextvm/contextvm)\n\n[https://github.com/contextvm/wotrlay](https://github.com/contextvm/wotrlay)\n\n[https://github.com/nostr-protocol/nips/blob/master/90.md](https://github.com/nostr-protocol/nips/blob/master/90.md)\n\n[https://modelcontextprotocol.io/](https://modelcontextprotocol.io/specification)",
+			"created_at": 1767537904,
+			"id": "7a2e38989e074776ebb7df6b37ab873e2ab270a66ec19f59099e1d1005f334ac",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "ab8bd356d11dd95b25850e5632c7883541081e4807a0b83d8337d22c6638096579a82d1157308eb481af3de2c95a4d0829545c0a88414dc829e41384b7d82db7",
+			"tags": [
+				["d", "cvm-clients-the-nostr-way"],
+				["title", "CVM clients, the Nostr way"],
+				["published_at", "1767537903"],
+				[
+					"image",
+					"https://blossom.band/866845dd466202d993c1147beee768be13bd938d386823f40ce17f2bb68615f6.png"
+				],
+				[
+					"summary",
+					"This article addresses a practical question: when a service lives behind a Nostr pubkey like a DVM or a CVM, what does it mean to \"call it\"?"
+				],
+				[
+					"alt",
+					"CVM clients, the Nostr way - read it in https://habla.news/u/_@contextvm.org/cvm-clients-the-nostr-way"
+				],
+				["client", "Habla"]
+			]
+		},
+		{
+			"content": "Wotrlay is a proof-of-concept relay that explores a different approach to moderation: treat it as **resource allocation**, and let a community's **web-of-trust** influence who gets more publishing capacity.\n\nWotrlay is built in Go using the [Rely ](https://github.com/pippellia-btc/rely)framework, and it is heavily inspired by the WoT example in that repository. This project builds on that foundation and explores a different moderation posture, especially around progressive rate limiting, auth, and rank integration.\n\nFor ranking, Wotrlay integrates Relatr, a service that computes a per-pubkey score. Relatr is reached through ContextVM, which means the ranking service isn't a HTTP endpoint, it's a Nostr-native request/response interaction.\n\nThis post is part of a larger series. Next, we'll publish a practical article about building CVM clients without SDKs or dependencies—just keys, events, and relays, the code of project is a demonstration of this as well. Here, we'll walk through how Wotrlay works: the bucket model, how rank drives permissions, the newcomer onboarding path, and why ContextVM makes the ranking service swappable without rebuilding the relay.\n\nBTW We're running a public instance at `wss://wotr.relatr.xyz` that anyone can connect to and test.\n## The core idea: a progressive bucket\n\nThink of a relay like a small city with limited infrastructure: roads (bandwidth), storage (disk), and staff time (moderation cost). If anyone can dump unlimited load into that city, the city collapses. But if every newcomer must ask permission, you've recreated the velvet-rope club model.\n\nWotrlay tries a different mechanism: each pubkey gets a \"bucket\" of publishing capacity.\n\nWhen you publish, you spend capacity. Over time, the bucket refills. The refill speed—and how much you can burst in a short time—depends on your **rank**.\n\nThat's the progressive part: low-rank identities can still speak, but slowly. Higher-rank identities can publish at a higher pace, without turning the relay into an unbounded sink for spam.\n## Rank is dynamic, not a badge\n\nIn Nostr, there is no global reputation scoreboard that everyone agrees on. Any meaningful ranking has to be contextual: computed from some perspective, using some signals, with some trade-offs.\n\nRelatr embraces this idea. It computes scores for pubkeys from a chosen \"source\" perspective using social graph proximity plus additional validations. Different communities can run different instances and get different outcomes.\n\nWotrlay takes that score and answers a narrower, more practical question:\n\nHow much publishing capacity should this pubkey receive here?\n\nWhat makes this approach interesting is how it rewards organic participation. When a newcomer starts publishing and interacting with others, they begin to form connections in the social graph. As those connections grow and the pubkey becomes part of more relationships, the rank naturally rises through network effects. There's no manual approval process or gatekeeper—just the emergent result of participation.\n## The policy in plain language\n\nWotrlay turns rank into three permissions.\n\nFirst: **what you can publish**.\n\nBelow a configurable mid-rank threshold, Wotrlay only accepts basic note events (Kind 1). The goal isn't to moralize about content. It's to reduce the attack surface. Many spam and indexing attacks rely on flooding specialized event kinds; limiting low-rank keys to the simplest kind is a cheap, effective pressure valve.\n\nSecond: **how fast you can publish**.\n\nInstead of a \"daily reset\" quota that encourages people (and bots) to dump everything in a burst, Wotrlay refills capacity smoothly over time. If you publish steadily, you're steadily allowed. If you try to flood, you hit the bucket wall.\n\nThird: **how much you can burst**.\n\nEven high-rank keys don't get infinite burst. Wotrlay deliberately caps short-term bursts while still allowing natural behavior—posting threads, coming back online, syncing after downtime.\n## The newcomer path\n\nEvery open relay has a cold start dilemma.\n\nIf you give unknown identities too much capacity, spam scales cheaply. If you give them zero capacity, the relay stops being permissionless in practice.\n\nWotrlay sets a minimal baseline: a newcomer with a rank of 0 can still publish a small amount immediately, one note per day (enough to appear and participate). Meanwhile, the relay begins rank computation in the background, and its bucket refills progressively. As the public key gains visibility and builds real relationships, its rank can rise, and the bucket refills faster. Notice that a rank of 0 is very unlikely for public keys that have already been participating in Nostr for some time.\n\nThat \"progression\" is the main point: instead of flipping between \"blocked\" and \"unlimited,\" publishing becomes a gradient. \n## Why this avoids auth friction\n\nSome relay designs reach for connection-level authentication to make identity-based policies workable, this is NIP-42. Wotrlay doesn't use that dependency.\n\nOn Nostr, events are already signed. The pubkey in the event is the identity that matters for publishing policy. By enforcing rules per event, Wotrlay stays compatible with typical clients while still making the pubkey the unit of accountability.\n\nThis is also why Wotrlay doesn't require NIP-42 as a prerequisite for publishing. NIP-42 can be useful in many contexts, but it's not strictly necessary for this specific model: the relay can account for publishing based on the pubkey that signed the event.\n## Relatr over ContextVM\n\nWotrlay's only external dependency is the rank provider. ContextVM makes that dependency \"Nostr-shaped\": you address the service by pubkey, send a request event, and listen for a response event.\n\nThis has practical consequences:\n\nIf you don't like the default ranking model, you can run your own provider. If a community wants a different notion of rank, they can choose a different provider. If you want to experiment, you can swap the oracle without redesigning the relay.\n\nThis also highlights something subtle: DVM calls are fundamentally the same interaction pattern as calling a ContextVM server. Different framing, same Nostr-native mechanism. We'll explore this more in the next article.\n## What to expect\n\nWotrlay is not \"the solution to moderation.\" It's a working demonstration of a proof of concept.\n\nExpect a policy that is legible (rank maps to permissions), resistant to cheap sybil throughput (new identities don't get volume), and composable (the ranking oracle can be self-hosted and swapped).\n\nDon't expect a universal rank metric, or a replacement for human judgement where real abuse is involved.\n\nThe point is to widen the design space: moderation can be expressed as explicit, programmable constraints—strict where they must be, permissive where they can be, and always replaceable. We would love to hear your feedback, thoughs and ideas.\n\n---\n\n**Want to try it out?** We're running a public instance at `wss://wotr.relatr.xyz` that anyone can connect to and test. It uses the default Relatr instance for ranking.\n\n**Want to explore the implementation or run your own instance?** Check out the repository at [ContextVM/wotrlay](https://github.com/ContextVM/wotrlay) for the complete source code, configuration details, and setup instructions.\n\n",
+			"created_at": 1766865090,
+			"id": "c159915faaba82cc4bf7d8c6133c2c36fa849a03e7d1cc6b425d1256d4f0d3ea",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "6baa37e897bf0b315440fecb74f0c9559d26f35fb6fae37bdb5774bac3f7fb1b2a8b1bc87e524d61a644490a9b244d2da3a533fb6fbd78ff427c25e451d6835b",
+			"tags": [
+				["d", "wotrlay-moderation-as-a-bucket"],
+				["title", "Wotrlay: moderation as a bucket"],
+				["published_at", "1766865089"],
+				[
+					"image",
+					"https://blossom.band/2e2664e11cc3cf69e4488beca8ae0875845ad166d982feb61bb111bdc5304b5d.png"
+				],
+				[
+					"summary",
+					"Wotrlay is a new relay that explores a different approach to moderation: treat it as resource allocation, and let a community's web-of-trust influence who gets more publishing capacity."
+				],
+				[
+					"alt",
+					"Wotrlay: moderation as a bucket - read it in https://habla.news/u/_@contextvm.org/wotrlay-moderation-as-a-bucket"
+				],
+				["client", "Habla"]
+			]
+		},
+		{
+			"content": "Trust is not an absolute quantity. It is deeply personal, contextual, and always relative. In centralized systems, we have become accustomed to trust being imposed upon us by platforms and institutions, a \"blue check\" or a hidden algorithm deciding who is trustworthy for everyone.\n\nBut this model misunderstands the nature of trust, especially in decentralized systems like Nostr. Trust is a scaling solution, the fundamental mechanism that reduces friction in complex systems, allowing us to cooperate beyond our immediate relationships.\n\nWe built Relatr to reclaim this mechanism. Relatr is a service that anyone can run, computing trust scores based on the perspective of a specific source. It embraces the relative, dynamic, and layered nature of trust, empowering individuals and communities to define what trust means to them.\n\nToday, we are releasing Relatr v0.1, with significant architectural improvements powered by the new Nostr Social Duck library. This update solves critical scaling challenges and makes running your own trust engine more accessible than ever.\n\n## A Transparent Algorithm\n\nAt its core, Relatr computes trust from a specific source public key perspective. Because decentralized networks like Nostr lack a global state, there is no \"global reputation.\" Instead, we rely on social graph proximity together with objective validations. While Relatr includes some default validations like NIP-05 domain checks, relay lists, and Lightning address verification, among others, the system is fundamentally flexible. You can customize it with any validation rule, enabling highly specific trust models tailored to your needs.\n\nIf you are interested in learning more about how Relatr computes trust scores, the about page of the Relatr website is a good way to start. [https://www.relatr.xyz/about](https://www.relatr.xyz/about)\n\nThis flexibility enables Relatr to serve diverse use cases. Individuals might prioritize social connections, while businesses or communities can configure their instance to validate specific badges, memberships, or other criteria, effectively creating their own Web of Trust metrics based on their own standards. At its core, Relatr embraces the relativity of trust and context. We are still working to make custom validations more accessible and intuitive, but the framework is already extensible enough for anyone to create custom validation rules.\n\n## The Challenge\n\nIn our initial release, we used a combination of the `nostr-social-graph` library for social graph distance calculations and SQLite for profile metadata. While this worked well for looking up the score of single pubkeys, it struggled with search. Search is a much more nuanced operation than calculating a score for a given pubkey.\n\nConsider a search for \"Alex\". This query could potentially return thousands of matches. To find the profiles relevant to *you*, we must filter and rank these thousands of candidates by their trust score, and then return the top results.\n\nIn our previous architecture, the \"phone book\" (names) and the \"social map\" (distances and validations) lived in separate systems. We had to fetch large batches of potential matches, calculate trust scores for each individually, and then sort them. This approach was inefficient and prone to making servers hang under load. Returning all potential matches is very expensive and inefficient, so we opted to add a multiplier to the search limit to keep computation under control. However, this limit approach was quite arbitrary: too few possible matches and we missed relevant people; too many or all matches, and performance and response times became unpredictable.\n\n## The Solution: Nostr Social Duck\n\nWe needed a way to improve this, to query metadata and social graph distance simultaneously while keeping resource requirements low. In other words, we had to shift the concept of the query from returning all matches from \"Alex\", to returning the most relevant \"Alex\". After some research, we found an answer that fits our needs.\n\nEnter DuckDB.\n\nDuckDB is an embedded, in-process SQL database designed for high-performance analytics. Crucially, it handles memory management gracefully. When a query requires more memory than is available, DuckDB spills to disk rather than crashing. This allows us to perform complex graph analysis on modest hardware.\n\nWe built [Nostr Social Duck](https://github.com/gzuuus/nostr-social-duck) (NSD), a library that leverages DuckDB to perform graph operations over Nostr data. If you are interested in learning more about NSD, you can visit its repository, and read this [introductory note](https://nostr.eu/nostr:nevent1qvzqqqqqqypzqs9eep0ll6hurjkl3sc2fewgses07mjfwxsdcu3at2m8fd0xrdz3qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqypmz4lcyj5k9he9yl5gan0erwqjdxrskymvw6qawhqj9l0rwlr6cspasp6h)\n\nWith this in place, we could move both the social graph and profile metadata into a unified DuckDB instance, transforming the search problem. Now, in a single SQL query we can:\n\nFind profiles matching \"Alex\" across metadata fields\nCalculate their social distance from the source key\nApply validation criteria\nReturn ranked results\n\nThis unified approach allows us to pre-rank and return the most relevant results from the entire dataset in milliseconds, not just a random subset.\n\n## Performance and Accessibility\n\nOne of our core goals is to ensure Relatr can be self-hosted by anyone, not just those with powerful servers.\n\nThe results of this refactor have been excellent. Our public Relatr instance currently runs on a $4 VPS. Even on this constrained hardware, it can handle hundreds of requests per minute with graceful performance degradation. We conducted some naive benchmarking and stress testing, achieving ~30ms response times for searches under normal load and ~300ms response times during peak stress periods. In the other hand the pubkey lookup method demonstrated response times from ~2ms under normal load, to ~30ms under heavy load.\n\nThis efficiency makes the results feel instant and can satisfy various application use cases, such as tagging and quick search, among others. Additionally, you can deploy your own trust engine on almost any hardware, including a Raspberry Pi, an Umbrel node, a low-cost cloud server, or even a phone, without significant expense and with reasonable responsiveness. The disk requirements are also quite low; currently, our public instance, which contains more than 300k relationships, along with profile metadata and validations, uses just ~200MB.\n\n## Ecosystem Adoption and Use Cases\n\nWe cannot conclude this article without mentioning the community's response to Relatr, which is already being integrated into several projects:\n\n**Nostrudel:** Uses Relatr for username search and tagging\n**Profilestr:** Aggregates Relatr scores with other metrics like their own, and Vertex for unified reputation views\n**Zap-Work:** Leverages Relatr to compute trust scores for user interactions in their job marketplace\n**AQSTR:** Uses Relatr for engagement and reward platform scoring\n\nThanks to everyone integrating and using Relatr 💛\nThis adoption validates our belief that the ecosystem needs diverse, interoperable trust models. The potential use cases for Web of Trust on Nostr are extensive, and Relatr's self-hostable design makes it ideal for integration into clients for personalized scoring, tagging, search, and recommendations, among others.\n\nWe're also participating in the #WoTathon organized by Nosfabrica, which is advancing important discussions around Web of Trust implementations. This initiative inspires us to integrate NIP-85 trusted assertions into Relatr, providing another interface for developers and users to leverage Relatr's capabilities.\n\n## Seamless Integration\n\nWe want to make it trivial for developers to add \"Web of Trust\" features to their apps.\n\nWith CtxCn, integrating Relatr is as simple as running one command in your project:\n\nnpx @contextvm/ctxcn add\n\nThis generates a fully-typed, readable TypeScript client directly in your codebase. You own the code, it's easy to maintain, and it connects immediately to the specified Relatr instance.\n\nBut you're not limited to TypeScript. Relatr uses the ContextVM protocol, so in practice, if you can call a DVM, you can call any Relatr instance. The interaction follows a simple Nostr event pattern that works with any programming language.\n\nTo call Relatr tools like `search_profiles` or `calculate_trust_score`, you send a Nostr event of kind 25910 containing a request. The event must tag the Relatr instance's pubkey and include your call in the content field.\n\n**Example request structure:**\n\n{\n\"kind\": 25910,\n\"tags\": [[\"p\", \"\"]],\n\"content\": {\n\"jsonrpc\": \"2.0\",\n\"id\": \"your-request-id\",\n\"method\": \"tools/call\",\n\"params\": {\n\"name\": \"search_profiles\",\n\"arguments\": {\"query\": \"jack\"}\n}\n}\n}\n\nNote: The content field should be stringified.\n\n**Listening for responses:**\nResponses come as Nostr events from the Relatr instance, tagged with your pubkey. The response contains the result with trust-scored profiles and metrics.\n\n### Quick Testing with `nak` CLI\n\nFor quick testing, you can use the `nak` CLI tool:\n\n**Send a search request:**\n\nnak event -k 25910 -c '{\"jsonrpc\":\"2.0\",\"id\":\"test\",\"method\":\"tools/call\",\"params\":{\"name\":\"search_profiles\",\"arguments\":{\"query\":\"jack\"}}}' -t \"p=750682303c9f0ddad75941b49edc9d46e3ed306b9ee3335338a21a3e404c5fa3\" wss://relay.contextvm.org\n\n**Listen for responses:**\n\nnak req --stream -s \"$(date +%s)\" -k 25910 -p  wss://relay.contextvm.org\n\n**Discover available tools:**\n\nnak event -k 25910 -c '{\"jsonrpc\":\"2.0\",\"id\":\"any-id\",\"method\":\"tools/list\"}' -t \"p=750682303c9f0ddad75941b49edc9d46e3ed306b9ee3335338a21a3e404c5fa3\" wss://relay.contextvm.org\n\nThis returns complete tool definitions with input/output schemas, so you know exactly what methods are available, which parameters to use, and what to expect in responses.\n\nNote that the pubkey used in this examples are the public key of the public Relatr instance that we are running which is accessible to anyone and can also be used through [https://relatr.xyz](https://relatr.xyz)\n\nIf you want to learn more about the underlying ContextVM protocol, you can visit the [ContextVM documentation](https://docs.contextvm.org).\n\n## Run Your Own Instance\n\nRelatr is designed to be self-hostable and accessible. You can deploy it in multiple ways, we provide Docker images for easy deployment, you can have a Relatr instance running in minutes. For custom configurations or development, you can build Relatr from source. The project uses TypeScript and Bun, and the repository contains comprehensive documentation on configuration options, custom validation rules, and more.\n\n## Conclusion\n\nRelatr represents more than just a tool for us, it is a statement that in a decentralized world, trust cannot be outsourced. It must be claimed as our own.\n\nThe evolution from our initial architecture to the current Nostr Social Duck-powered implementation marks significant progress in making trust metrics accessible, efficient, and scalable. With v0.1, we've established a foundation that empowers individuals, communities, and businesses to define their own trust models.\n\nLooking ahead, we're focusing on several key enhancements. We're working to make validation customization more intuitive for non-developers, moving beyond the current approach that requires modifying Relatr's source code. Performance optimization remains a priority to ensure efficient operations across the board. We're actively incorporating community feedback and exploring the integration of NIP-85 trusted assertions to provide additional interfaces for developers. Additionally, we will expand our documentation to facilitate easier integration of Relatr into any Nostr application.\n\nWe're excited to see how the community adopts and builds upon these foundations and invite you to run your own instance, integrate Relatr into your projects, or contribute to the codebase.\n\n**Website:** [relatr.xyz](https://relatr.xyz)\n**GitHub:** [github.com/contextvm/relatr](https://github.com/contextvm/relatr)\n**Nostr Social Duck:** [github.com/gzuuus/nostr-social-duck](https://github.com/gzuuus/nostr-social-duck)",
+			"created_at": 1764943791,
+			"id": "2bbfb8cb0ce158f385c62c50ee6fa3cefe4c2fa18e87055b1168985931d7d460",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "cb23362834959c2ee3ebd7fa4901d87b8cbf61f7abef8843aeeeb2ac9a45bcee431c5db78a54404030e1017317c2bf74e239bced9dcbd74651b8467017b78e48",
+			"tags": [
+				["d", "relatr-nsd"],
+				["title", "Relatr v0.1: Scaling Decentralized Trust"],
+				[
+					"summary",
+					"Today, we are releasing Relatr v0.1, with significant architectural improvements powered by the new Nostr Social Duck library. This update solves critical scaling challenges and makes running your own trust engine more accessible than ever."
+				],
+				[
+					"image",
+					"https://image.nostr.build/c15be8c517785968002188b9dfbb6a4a8ba0509d3de569bd7d0f78f0b13c1b53.jpg"
+				],
+				["published_at", "1764943791"],
+				["t", "nostr"],
+				["t", "wot"],
+				["t", "wotathon"],
+				["t", "trust"],
+				["t", "cvm"],
+				["t", "contextvm"],
+				[
+					"e",
+					"762aff04952c5be4a4fd11d9bf237024d30e1626d8ed03aeb8245fbc6ef8f588",
+					"wss://nos.lol/",
+					"",
+					"40b9c85fffeafc1cadf8c30a4e5c88660ff6e4971a0dc723d5ab674b5e61b451"
+				],
+				["p", "40b9c85fffeafc1cadf8c30a4e5c88660ff6e4971a0dc723d5ab674b5e61b451", ""]
+			]
+		},
+		{
+			"content": "Trust is not an absolute quantity, it's always relative, it's a deeply personal and contextual phenomenon. In centralized systems, we’ve become accustomed to trust being imposed upon us by platforms and institutions. But this model misunderstands the nature of trust itself. As explored in \"[Trust Is a Scaling Solution](https://trustisascalingsolution.com/),\" trust is the fundamental mechanism that reduces friction in complex systems, allowing us to cooperate beyond our immediate relationships.\n\nHowever, traditional systems have applied this principle with a flaw: they have attempted to create one-size-fits-all metrics or impose their own model of trust to determine what is trustworthy. We are pleased to introduce Relatr, our approach to decentralized trust. It is built on a fundamentally different philosophy. Relatr is a decentralized service to compute trust in decentralized networks like Nostr, that embraces the relative, dynamic, and layered nature of trust, empowering individuals to define what trust means to them.\n\n## The Engine of Trust: A Transparent Algorithm\n\nRelatr computes trust from a specific source public key perspective which every instance should configure (if not configured it will default to nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc public key). At its core, it uses a simple yet meaningful algorithm to compute trust scores by combining multiple factors into a single, weighted score:\n\n`Trust Score = Σ(wᵢ × vᵢ) / Σ(wᵢ)`\n\nHere, `wᵢ` represents the weight you assign to a metric, and `vᵢ` is its normalized value, allowing for deep personalization. This formula is inspired by the [\"Qualitative Thumb System\" (QTS) outlined by arkinox](https://nostr.at/naddr1qvzqqqr4gupzp68dx7vvdlltl7sg2qdv8838ze3tl5tq76y0jnz966fdsana6dz6qq25gnzpveay5jns29z9xdrkdgehw5mvv46k6gd0088)\n\nThe system analyzes two primary types of signals:\n\n1.  **Social Graph Proximity**: Reflecting the idea that trust diminishes across social connections, Relatr measures social distance between the source public key and a target public key, using Martti Malmi's `nostr-social-graph` library. Direct relationships between the source and the target public key carry the most weight, while trust decays exponentially as distance grows, capturing the essence of \"I trust you, so I can extend a degree of trust to those you trust.\"\n\n2.  **Objetive Profile Validations**: Beyond social ties, Relatr incorporates objective, verifiable data. This includes metrics like NIP-05 domain validation, Lightning Network address, and other proofs. The framework is designed to be extensible, allowing new validation plugins to be added over time to assess factors like user activity or zap interactions.\n\n## Decentralized and Accessible: Relatr on ContextVM\n\nRelatr's architecture embodies its principles. It is not a centralized service but a protocol that anyone can run. This is made possible by **ContextVM**, a decentralized protocol that enables services to communicate over the Nostr network.\n\nRunning Relatr as a ContextVM service makes it incredibly accessible. Anyone can deploy their own trust engine from source or a Docker container in environments like Umbrel or Start9, often with a one-click install. This turns any internet-connected device into a personal trust server without complex networking or hosting costs.\n\nEach Relatr instance is identified by the public key of its ContextVM server. The **[relatr.xyz](https://relatr.xyz)** website demonstrates this. While it defaults to a public server we are running, it allows any user to paste in the public key of another Relatr instance. Whether it’s their own, a friend’s, or one run by a community they trust. This guarantees no vendor lock-in; you are always free to choose your provider.\n\n## Seamless Integration: Empowering Developers with CtxCn\n\nThe benefits of ContextVM extend to developers. Integrating Relatr into clients is remarkably simple, thanks to a tool called **CtxCn** ([We introduced it last week](https://nostr.at/naddr1qvzqqqr4gupzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqq25set9ddxy2s33wq68y4fkx9hxwcn4geeyszanq8u)). It’s a command-line utility that generates a fully-typed Relatr client directly into an application's codebase. Simple as running a single command.\n\n`npx @contextvm/ctxcn add <relatr-server-pubkey>`\n\nInstead of wrestling with an opaque library, developers get clean, readable source code they can own and adapt, and it's easy to maintain. This empowers anyone to easily integrate Relatr, allowing users to configure their own trust server and plug a powerful, personalized reputation system directly into their user experience.\n\n## From Centralized Authority to Individual Sovereignty\n\nRelatr represents a fundamental departure from the black-box algorithms of traditional platforms. Where centralized systems impose universal standards, Relatr delivers transparency and control. Trust carries costs and risks, making it a valuable and vulnerable resource. The principle of \"don't trust, verify\" is key, but realizing that verification itself is relative to the observer's point of view. Relatr enables this by allowing you to fine-tune your own criteria, creating a resilient ecosystem resistant to censorship.\n\nThe open-source algorithm and the ability to run your own instance mean you can always understand and audit how scores are computed, giving you true sovereignty over your trust decisions.\n\n## Getting Started with Relatr\n\nRelatr is designed to be lightweight and should run on almost any device. The easiest way to get started is with the official Docker image. For detailed instructions, follow the readme in the [repository](https://github.com/contextvm/relatr).\n\n## Conclusion\n\nRelatr is more than a technical tool; it’s a philosophical statement. It argues that in a decentralized world, trust cannot be outsourced. It must be cultivated, calculated, and claimed as our own.\n\nIts existence is also part of a broader conversation within the Nostr ecosystem, inspired by projects like [Vertex](https://vertexlab.io/), which first introduced advanced trust computation concepts. It's a testament to the idea that there is no single right way to compute trust. The more models we have to explore, the healthier the ecosystem becomes. By placing powerful, transparent tools in the hands of individuals and developers, Relatr paves the way for a more a sovereign digital future where power is distributed and systems serve human agency.\n\n## Get Involved\n\nExplore this and get involved with the Relatr project.\n\n- **Website**: [https://relatr.xyz](https://relatr.xyz)\n- **GitHub Repository**: [https://github.com/contextvm/relatr](https://github.com/contextvm/relatr)\n",
+			"created_at": 1761497287,
+			"id": "7ca6570bebc83140365dec05ce343b77eb5c7d74b8c4f74e2c9a97de123012d5",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "3ab00a6212041a5c22e985322e6ac3c8b184c12b9c988da4cd16f00c4b3c6a6511b9ad73ce78ff3af3b7def14e75402c60f2cc31e27b8b47341ff8ff1c497ceb",
+			"tags": [
+				[
+					"client",
+					"Yakihonne",
+					"31990:20986fb83e775d96d188ca5c9df10ce6d613e0eb7e5768a0f0b12b37cdac21b3:1700732875747"
+				],
+				["published_at", "1761497287"],
+				["d", "yItckCkpmTq-owE5AgYtq"],
+				[
+					"image",
+					"https://image.nostr.build/30d7fdef1b3d3b83d9e33f47b7d15388deeb47428041f0656612d1450cdb1216.jpg"
+				],
+				["title", "Relatr — Relate, Relative, Relation: Our shot on Decentralized Trust."],
+				[
+					"summary",
+					"A decentralized trust metric service for Nostr that computes trust scores based in the perspective of a source pubkey using social graph distances and customizable validations."
+				],
+				["t", "nostr"],
+				["t", "trust"],
+				["t", "cvm"],
+				["t", "mcp"],
+				["p", "6e468422dfb74a5738702a8823b9b28168abab8655faacb6853cd0ee15deee93", "", "mention"]
+			]
+		},
+		{
+			"content": "# Introducing Ctxcn\n\nIn today's interconnected digital landscape, building applications often feels like assembling a complex puzzle. We stitch together frontend interfaces, backend logic, and a growing number of remote services, each with its own language and rules. This is especially true in decentralized ecosystems, where the distance between a client application and a remote server can be fraught with friction.\n\nEnter [`ctxcn`](https://github.com/ContextVM/ctxcn), a command-line utility poised to change this narrative. It’s not just another RPC framework; it’s a philosophical shift in how we handle remote integrations. Inspired by the developer-first ethos of tools like `shadcn` and the conceptual elegance of [Cap'n Web](https://blog.cloudflare.com/capnweb-javascript-rpc-library/), `ctxcn` provides a bridge that seamlessly connects your TypeScript applications to ContextVM (CVM) servers, transforming a chore into a natural and intuitive experience.\n\n## The `shadcn` Philosophy: From UI to RPC\n\nTo understand `ctxcn`, we first need to understand the brilliance of `shadcn`. Unlike traditional UI libraries that give you black-box components, `shadcn` provides source code that you copy directly into your project. This gives you full ownership. You can modify, adapt, and style every part of the component without fighting against the library's opinions or limitations.\n\n`ctxcn` applies this exact philosophy to the world of server-side RPC. Instead of installing an opaque client package, `ctxcn` generates the client code directly into your codebase. You own it. This simple shift has profound implications: no more dependency hell, no more waiting for a library to be updated, and complete freedom to customize the client to your exact needs. \n\nIn this line and because you own the client code, `ctxcn` unlocks a new level of creative freedom. Imagine creating multiple \"skins\" or user interfaces for the same set of server tools. You could build a sleek, minimalist UI for power users and a more guided, friendly experience for beginners, all without touching the backend.\n\nThis approach also dramatically simplifies development with AI-powered coding assistants. These tools thrive on clear, well-documented, and strongly-typed code. By generating a client that looks and feels like standard TypeScript, `ctxcn` makes it trivial for an LLM to understand how to implement features that rely on your CVM server, accelerating development and reducing errors.\n\n## The Silent Struggle of Remote Integration\n\nBefore `ctxcn`, integrating a CVM server involved a familiar, tedious dance. You’d manually write TypeScript interfaces to match the server's API, a process that was both time-consuming and fragile. You'd find yourself wrestling with `any` types, sacrificing the compile-time safety that makes TypeScript so valuable. Every server update became a potential breaking change, turning maintenance into a source of nightmares.\n\nThis friction forces developers to spend more time on boilerplate and configuration than on what truly matters: building a great user experience.\n\n## The `ctxcn` Elegance: From Schema to Seamless Code\n\n`ctxcn` elegantly dismantles these barriers. When you point it at a CVM server, it connects, inspects the tool definitions, and generates a complete, type-safe TypeScript client. This is all accomplished with two simple commands:\n\n```bash\n# 1. Initialize ctxcn in your project (one time)\nnpx @contextvm/ctxcn init\n\n# 2. Add a server by its public key\nnpx @contextvm/ctxcn add <server-pubkey>\n\n# 3 (optional). Update all clients if the server changes\nnpx @contextvm/ctxcn update\n```\n\nWhat you get is not just a set of type definitions, but a fully-formed client class. Each remote tool becomes a native TypeScript method, complete with JSDoc comments, parameter validation, and fully-typed return values.\n\nFor a live demonstration, check out this short video where we explore ContextVM ecosystem and `ctxcn` in action:\n\n[![Watch the demo](https://r2a.primal.net/uploads2/d/b5/73/db5731558295a9c919327416b8a48e2e189e4ef6603cef636c92f67428a2ae6e.mp4)](https://blossom.primal.net/db5731558295a9c919327416b8a48e2e189e4ef6603cef636c92f67428a2ae6e.mp4)\n\n*(You can also view the [original note here](https://nostr.at/nevent1qvzqqqqqqypzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyrk6hlekvheur59n22ts95vlg9g9d9rm75uk5vk2ksyqj9k73t7fwaa38y4).)*\n\nThe complexities of the underlying Nostr transport protocol, message signing, and relay management are all handled for you, abstracted away behind a clean and intuitive API.\n\nFor example, if a CVM server exposes an `add` tool, `ctxcn` generates a client you can use like this:\n\n```typescript\n// The generated client exports a convenient singleton instance\nimport { addition } from \"./src/ctxcn/AdditionClient\";\n\n// This feels like a local function call, but it's a secure, remote operation.\n// Each function in the client is type safe and integrates with your IDE to have auto completion\nconst add = await addition.add(5, 10);\n\nconsole.log(add.result); // 15\n\n// You can also create a custom instance for more control\nimport { AdditionClient } from \"./src/ctxcn/AdditionClient\";\nconst customClient = new AdditionClient({\n  privateKey: process.env.MY_PRIVATE_KEY,\n  relays: [\"wss://my-custom-relay.com\"]\n});\n```\n\n## Under the Hood: Type Safety via MCP\n\nThe type safety in `ctxcn` isn't magic; it's a direct result of the robust design of the **[Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification/2025-06-18/server/tools#structured-content)**. CVM servers adhere to the MCP specification, which allows tools to define their inputs and outputs schemas.\n\nThis `outputSchema` is the secret sauce. It enables strict validation of server responses and provides the precise type information `ctxcn` uses to generate a client that is type-safe from end to end. This means you can catch errors at compile time, not in production, leading to more reliable and maintainable applications.\n\n## Get Started and Learn More\n\n`ctxcn` is more than a productivity tool; it's a catalyst for innovation in the decentralized web. By combining the principle of code ownership with the power of a standardized protocol like MCP, it lowers the barrier to entry for CVM integration and champions a future where decentralization and developer experience go hand-in-hand.\n\nThe era of wrestling with opaque, third-party RPC clients is over. The future of distributed development is about ownership, flexibility, and powerful, type-safe tooling. Welcome to `ctxcn`.\n\n- **Explore the code** and contribute on the [official `ctxcn` GitHub repository](https://github.com/ContextVM/ctxcn).\n- **Dive deeper** into the ContextVM ecosystem by reading the [official documentation](https://docs.contextvm.org).\n- **Join the community** on [Nostr](https://nostr.at/npub1dvmcpmefwtnn6dctsj3728n64xhrf06p9yude77echmrkgs5zmyqw33jdm) and [Signal](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR).",
+			"created_at": 1761045534,
+			"id": "ca75fec480de951f1294bd6b690ffb5ac50660b97ffa36da1aaeb9b55a008d45",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "5f2047d030ce79b3d757ae9e1b8f9de7c1dc833759b463e9a3d804d517ff5ccc610bc241bf654a69dfdc0c0a7c80e300a3db2a33cbbc8a473fa27c4f1c845fcc",
+			"tags": [
+				[
+					"client",
+					"Yakihonne",
+					"31990:20986fb83e775d96d188ca5c9df10ce6d613e0eb7e5768a0f0b12b37cdac21b3:1700732875747"
+				],
+				["published_at", "1761045534"],
+				["d", "HeekLEB1p4rU61ngbuFrH"],
+				[
+					"image",
+					"https://image.nostr.build/77aa773c5671045ad723cf08da98e6733ade9859428627a8d687825b413f23ff.jpg"
+				],
+				["title", "Introducing Ctxcn"],
+				[
+					"summary",
+					"Inspired by tools like shadcn and Cap'n Web, CtxCn is a command-line utility designed to make developers' lives easier."
+				],
+				["t", "contextvm"],
+				["t", "nostr"],
+				["t", "rpc"],
+				["t", "dev"],
+				["t", "ai"],
+				["t", "llm"],
+				["t", "mcp"]
+			]
+		},
+		{
+			"content": "The promise of a truly decentralized internet has long been a guiding star for builders, developers, and advocates of digital freedom. Yet, the practical challenges of deploying services that are both censorship-resistant and easy to manage have often felt insurmountable. During the recent #sovEng 5 cohort, we embarked on a period of intense experimentation with ContextVM (CVM), a technology that we believe provides a powerful new foundation for sovereign infrastructure. This article shares the insights, breakthroughs, and a Cambrian explosion of projects that emerged, painting a picture of a more liberated digital future.\n\n## The Paradigm Shift: Services Addressed by Public Keys\n\nAt the heart of our exploration was a fundamental realization: CVM enables a powerful paradigm shift by allowing services to be addressed by a public key rather than a permissioned, location-dependent IP address. This seemingly simple change has profound implications.\n\nSuddenly, the need for API keys vanishes, replaced by cryptographic identity. The complex dance of configuring networks, firewalls, and NAT traversal becomes obsolete. You can deploy a service from your laptop in a coffee shop, and it is instantly accessible to the world, securely and privately. The service is identified by *who* it is (its pubkey), not *where* it is.\n\nThis unlocks the concept of \"rolling services\"—infrastructure that can move geographically without any disruption in accessibility. It makes deploying services not only trivial but also unstoppable. Security and privacy are enhanced by default; since a service never needs to reveal its IP address, only the relay it connects through can see its IP, but all communication is end-to-end encrypted, rendering the relay blind to what's happening.\n\n## Balancing the Trilemma: Convenience Through Sovereignty\n\nZooko's like Trilemmas suggests that of the three desirable properties—privacy, decentralization, and convenience—we can only pick two. If convenience is provided by a third party, you inevitably sacrifice either privacy or decentralization.\n\n![Zooko's Trilemma](https://image.nostr.build/b3029b832db5082ca0cc9e0915f0991c7b31047b6619f79ddd9b100f5c3e4cb3.png)\n\nInspired by nostr:nprofile1qqsxu35yyt0mwjjh8pcz4zprhxegz69t4wr9t74vk6zne58wzh0waycprpmhxue69uhhqun9d45h2mfwwpexjmtpdshxuet5qyxhwumn8ghj7mn0wvhxcmmvee340a 's presentations during the cohort, we were led to a powerful conclusion: you can balance all three if you reframe the problem. When a user provides their own convenience, they sacrifice nothing. Convenience is transformed into sovereignty.\n\n![Sovereignty Trilemma](https://image.nostr.build/7106ea033c5b5e85ea9d86ec4d3193ba5a0e2b50fdb5e10f550f971c5b3facee.png)\n\nCVM provides the technical groundwork for this model, making it practical for anyone to become their own infrastructure provider. This is especially appealing for node runners or anyone with a spare device and an internet connection. We are actively working to make this even more accessible, with plans for \"one-click\" CVM server installations on platforms like Umbrel and Start9, truly democratizing the ability to run one's own corner of the internet.\n\n## From Theory to Practice: A Cambrian Explosion of Experiments\n\nTalk is cheap. The true test of any technology is what people build with it. SovEng 5 unleashed a torrent of creativity, with projects exploring the potential of CVM. Here are some of the highlights:\n\n### [Nutoff](https://github.com/gzuuus/nutoff-wallet): A Sovereign Cashu Wallet\n\nOne of the first experiments, Nutoff is a Cashu wallet that runs locally on your device, yet is accessible from anywhere. By implementing the Nostr Wallet Connect (NWC) API, it allows users to create and pay invoices while ensuring all sensitive data remains under their control. This minimizes custodial risk and provides a powerful, self-hosted alternative for managing eCash. To complement the wallet, the [`nutoff-http`](https://github.com/gzuuus/nutoff-http) project was created, providing a simple HTTP server to interact with the wallet and offer a Lightning Address out of the box for any Nutoff wallet. Here you can see a [diagram](https://nostr.at/nevent1qvzqqqqqqypzqs9eep0ll6hurjkl3sc2fewgses07mjfwxsdcu3at2m8fd0xrdz3qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qqsypfpvq4afjm9n977xsxf7ngx75a0556tf46rzvwcam3jmgdelgsg6uqw24) of how all this works together.\n\n### [Beacon](https://github.com/humansinstitute/beacon-main): A Trojan Horse for Freedom Tech\n\nBeacon is a liberating and audacious idea: infiltrate walled gardens like WhatsApp with Lightning payments and other freedom technologies. Born from the realization that in many parts of the world, WhatsApp *is* the internet, Beacon uses CVM as the unstoppable glue to connect its different components and users from closed ecosystems to open networks. It's a pragmatic tool for guiding people toward free information, free networks, and freedom money. As the project's main meme states, \"Nice walled garden you got there, shame if someone... Put some freedom tech in it\" ([Demo](https://nostr.at/nevent1qvzqqqqqqypzp9pptap2jce4epluh85grg9mkc4e5724r8ssnn6ln5h0v9mgra3zqy88wumn8ghj7mn0wvhxcmmv9uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqzqznn5y4wf2xsm5sj55tddemrgj6x7yscyn8pp7xmn8fznh2ryt9t0lxchs))\n\n### [Blovm](https://github.com/ContextVM/blovm): Your Personal, Sovereign Dropbox\n\nBlovm explores the idea of a personal file indexing and storage system. It watches a local directory, indexes any files you drop into it, and uses Blossom integration to let you access or share them from anywhere. Essentially, you can request your server to upload a file from your local filesystem to a Blossom server, making it available to be downloaded from anywhere. It also supports the reverse process, allowing you to monitor a public key and automatically back up all associated blobs to your local machine. Other powerful features include periodic health checks to ensure your online blobs remain accessible, enabling you to re-upload them if they disappear.\n\n### [CtxCn](https://github.com/ContextVM/ctxcn): Streamlining Developer Experience\n\nInspired by tools like `shadcn` and [Cap'n Web](https://blog.cloudflare.com/capnweb-javascript-rpc-library/), CtxCn is a command-line utility that makes developers' lives easier. It connects to a CVM server, reads the JSON schema definitions of its tools, and automatically generates a type-safe TypeScript client. With a simple `init` and `add <pubkey>` command, developers can call remote CVM tools as if they were native functions, complete with type safety and autocompletion. We'll be writing a more detailed article on this tool soon.\n\n### [Retired in a Field](https://github.com/humansinstitute/retired-in-a-field-cvm): FUNding, and Multi-Jurisdictional Deployments\n\nThis playful game demonstrated how a full-stack application could be built with a completely decoupled architecture. The static frontend was hosted somewhere, while the CVM backend—managing Cashu payments, leaderboards, and some logic—ran from an Airbnb in Funchal, Madeira. This highlights the concept of multi-jurisdictional deployments, a powerful strategy for building resilient applications. It also brought \"fun\" to funding, with proceeds split between the developer and the CVM team. Another insight from this project is the ability to create 'full-stack' apps based on static web pages, a powerful pattern when combined with Nsite.\n\n### [Keepass-CVM](https://github.com/ContextVM/keepss-cvm.git): A Secure, Self-Hosted Password Manager\n\nThis project brings the convenience of services like Bitwarden to a self-hosted, minimized-trust environment. Keepass-CVM allows anyone to run their own secure password manager, accessible from anywhere, without any sensitive information ever leaving their device. It transmits data over relays in an end-to-end encrypted manner.\n\n### [Craig David Machine](https://github.com/humansinstitute/craigdavid-cvm): Composable AI Entertainment\n\nA perfect example of a composable application, this hilarious experiment uses multiple micro-backends to summarize your week on Nostr and turn it into a rap song, performed by a virtual Craig David. It's a fun demonstration of what's possible when services can be composed seamlessly. ([Craig David Profile](https://nostr.at/nprofile1qqs865yg459use0ggf8925h4xwntlu7kuuwatzaymkcme2dm2kqjnrgpzfmhxue69uhk7enxvd5xz6tw9ec82csppamhxue69uhkummnw3ezumt0d5q3vamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet5qyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqpp4mhxue69uhkummn9ekx7mqsy6l7p))\n\n### [Hypernote Elements](https://github.com/futurepaul/hypernote-elements): Interactive Experiences on Nostr\n\nHypernote brings back the spirit of the early, hypertext-driven web, allowing developers to create interactive, micro-apps that live directly within Nostr notes. It have some examples using CVM to provide the 'backend' or state management for these hyper-apps, opening up new possibilities for rich, decentralized content. ([Demo](https://nostr.at/nevent1qvzqqqqqqypzqrtvswydevzfhrw5ljxnmrpmhy778k5sh2pguncfezks7dry3z3nqy88wumn8ghj7mn0wvhxcmmv9uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uqzq6pp2c2wd6qwdv75xamn4dvxf5qxxe9vj7z383nr68qg5geytg3t2z8q2a))\n\n### [Paygress CVM Integration](https://github.com/DhananjayPurohit/paygress): Sovereign Machine Provisioning\n\nAnother powerful idea, this project explored using CVM as the interface for Paygress, a service that offers VPS and machine deployment using Nostr. This would allow users to programmatically buy and manage machines in a completely sovereign manner.\n\n### And More...\n\nOther projects are being built right now, and we are working on creating an awesome list of them. Stay tuned!\n\n## Empowering the Builders: Workshops and Knowledge Sharing\n\nA common misconception we encountered was that CVM is purely for AI and LLM applications. To dispel this, we conducted workshops focused on building general-purpose services. We demonstrated how anyone could build an MCP server in one of the ten supported languages (see the [MCP SDKs](https://modelcontextprotocol.io/docs/sdk)) and instantly expose it as a CVM server using the gateway component. The [CVM Rust MCP example](https://github.com/futurepaul/cvm-rust-mcp) created by nostr:nprofile1qqsq6myr3rwtqjdcm48u357ccwae8h3a4y96s28y7zwg458ngeyg5vcpzpmhxue69uhnzdps9enrw73wd9hsz9rhwden5te0dehhxarj9ehhsarj9ejx2as9mu63n during the workshop is a testament to this flexibility.\n\n## The Dual API: A Bridge Between Humans and AI\n\nWhile these experiments focused on CVM for sovereign backends and programmatic use, it's crucial to remember that the underlying Model Context Protocol (MCP) was designed for interaction with LLMs. This gives every CVM service a unique \"dual API\" nature. By building on CVM, you get an API usable by LLMs for free. A service built for a human or another program can be seamlessly understood and utilized by an LLM, opening up a fascinating design space for the future.\n\n## The Road Ahead\n\nThe experiments at SovEng 5 revealed that ContextVM is more than just a tool; it's a foundation for a new class of applications built on the principles of sovereignty, privacy, and decentralization. It enables multi-jurisdictional deployments, eliminates single points of failure, and provides a stellar developer experience.\n\nAll the projects mentioned are in their early stages, and we are incredibly excited to continue working on them, and about what's next. We hope this article has illuminated the potential of CVM and inspired you to join us. Keep an eye on these projects, or better yet, jump in and contribute.\n\nIf you have questions or want to contribute, please reach out to us on Nostr or join our [Signal community](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR). We are always happy to help build the future.\n\nThanks to everyone who contributed to make this article possible 💛 ",
+			"created_at": 1760440304,
+			"id": "ec2db296ad534b208e0d0b6740a5856c06dffaeee2e02fbbd94cc699305b2ffc",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "44fb22342835ac9b67361276ccfd378e5073745f0588961a5465859c5926ac25130e37a7a0f8427d79d0c92f9c0f41fcb79056fbdc6c2606a962583efd94646b",
+			"tags": [
+				[
+					"client",
+					"Yakihonne",
+					"31990:20986fb83e775d96d188ca5c9df10ce6d613e0eb7e5768a0f0b12b37cdac21b3:1700732875747"
+				],
+				["published_at", "1760440304"],
+				["d", "H6A1QyrVRu8DkRqZy_pJN"],
+				[
+					"image",
+					"https://image.nostr.build/7106ea033c5b5e85ea9d86ec4d3193ba5a0e2b50fdb5e10f550f971c5b3facee.png"
+				],
+				["title", "Lessons and Innovations from CVM at SovEng 5"],
+				[
+					"summary",
+					"During the recent SovEng 5 cohort, we embarked on a period of intense experimentation with ContextVM (CVM), a technology that we believe provides a powerful new foundation for sovereign infrastructure. This article shares the insights, breakthroughs, and a Cambrian explosion of projects that emerged, painting a picture of a more liberated digital future."
+				],
+				["t", "sovEng"],
+				["t", "nostr"],
+				["t", "cvm"],
+				["t", "contextvm"],
+				["t", "mcp"],
+				["p", "6e468422dfb74a5738702a8823b9b28168abab8655faacb6853cd0ee15deee93", "", "mention"],
+				["p", "0d6c8388dcb049b8dd4fc8d3d8c3bb93de3da90ba828e4f09c8ad0f346488a33", "", "mention"]
+			]
+		},
+		{
+			"content": "# Introducing ContextVM Enhancement Proposal (CEP) Guidelines\n\nWe're excited to announce the launch of our new ContextVM Enhancement Proposal (CEP) guidelines! As ContextVM has grown, we recognized the need for a more structured approach to protocol evolution. This standardized process is designed to ensure that enhancements to the ContextVM protocol are well-vetted, thoroughly discussed, and properly documented while maintaining our community-driven approach to development.\n\nOur approach draws inspiration from successful governance models used by other open source projects, including the Model Context Protocol's SEP guidelines, Python PEPs and Rust RFCs. By adapting these proven approaches to ContextVM's unique needs, we've created a framework that balances structure with flexibility.\n\n## What Are CEPs and Why Do They Matter?\n\nA **CEP** (ContextVM Enhancement Proposal) is a formal design document that proposes changes to the ContextVM protocol, outlines new features, or describes improvements to our development processes. Think of CEPs as the pathway for bringing big ideas to the ContextVM ecosystem in a way that ensures they receive the consideration they deserve. For more information about what qualifies as a CEP, see our [CEP guidelines](https://docs.contextvm.org/spec/cep-guidelines/).\n\nThe CEP process serves several important purposes. It provides standardization by creating a consistent format for proposing and reviewing protocol changes. It ensures transparency by maintaining a clear record of design decisions and community input. It fosters collaboration by ensuring broad community participation in protocol evolution. And it maintains quality by encouraging thorough consideration of technical implications and security concerns.\n\n## What Qualifies for a CEP?\n\nNot every change requires a CEP! The process is designed for substantial proposals that benefit from formal discussion and documentation. You should consider proposing a CEP if your change involves:\n\n- **New Protocol Features**: Adding event kinds, Nostr integration patterns, or changing data structures\n- **A Breaking Change**: Any change that is not backwards-compatible\n- **A Change to Governance or Process**: Any proposal that alters the project's decision-making, contribution guidelines\n- **A Complex or Controversial Topic**: If a change is likely to have multiple valid solutions or generate significant debate, the CEP process provides the necessary framework to explore alternatives, document the rationale, and build community consensus before implementation begins\n\nFor smaller, straightforward changes, a regular GitHub issue or pull request is often more appropriate. You can learn more about the CEP submission process in our [official documentation](https://docs.contextvm.org/spec/cep-guidelines/#submitting-a-cep).\n\n## The Three Types of CEPs\n\nWe've defined three categories of CEPs to serve different purposes within our ecosystem:\n\n1. **Standards Track CEPs** describe new features or implementations for the ContextVM protocol itself. They extend or enhance the base protocol and become part of the official specification once finalized. These are the most common type of CEP and represent the core evolution of our protocol. For more details on Standards Track CEPs, refer to our [CEP guidelines](https://docs.contextvm.org/spec/cep-guidelines/#cep-types).\n\n2. **Informational CEPs** provide guidelines, describe design issues, or share information with the community without necessarily representing official consensus. These documents serve as valuable resources that help the community understand complex topics or design considerations, even if they don't directly change the protocol. Learn more about Informational CEPs in our [documentation](https://docs.contextvm.org/spec/cep-guidelines/#cep-types).\n\n3. **Process CEPs** focus on how we work rather than what we build. These address processes surrounding ContextVM development, such as changes to contribution guidelines, review procedures, or community governance. They ensure that as our project grows, our ways of working evolve thoughtfully and with community input. For more information about Process CEPs, see our [CEP guidelines](https://docs.contextvm.org/spec/cep-guidelines/#cep-types).\n\n## How the CEP Process Works\n\nThe CEP process is designed to be thorough yet efficient, ensuring that good ideas get proper consideration while moving through clear stages. For Standards Track CEPs, the journey begins with a discussion phase where you start with a GitHub Issue to gather initial feedback and build consensus. This is followed by the specification phase where you create a Pull Request with the detailed technical specification. Then comes sponsorship, where you find a maintainer to champion your proposal. Next is the review process, where your proposal undergoes formal review by maintainers. Finally, there's implementation, where you complete a reference implementation before final approval.\n\nFor Informational and Process CEPs, the journey is similar but slightly streamlined. You still start with a discussion phase by creating a GitHub Issue, then find a maintainer sponsor, go through formal review by maintainers, and finally see your CEP accepted.\n\n## Key Benefits of the CEP Process\n\nThe CEP process brings significant advantages to everyone involved in the ContextVM ecosystem:\n\n### For Contributors\n- **Clear Process**: Well-defined steps for bringing your ideas to life\n- **Community Input**: Your proposal gets reviewed by the entire community\n- **Expert Guidance**: Access to maintainer expertise and feedback\n- **Historical Record**: Your contribution becomes part of ContextVM's history\n\n### For the Community\n- **Quality Assurance**: Thorough review of protocol changes\n- **Transparency**: Clear documentation of design decisions\n- **Consensus Building**: Structured approach to resolving disagreements\n- **Ecosystem Growth**: Well-considered enhancements that benefit everyone\n\n### For Protocol Evolution\n- **Stability**: Breaking changes are carefully managed\n- **Interoperability**: New features are designed with compatibility in mind\n- **Security**: Security implications are thoroughly evaluated\n- **Maintainability**: Clear documentation makes future maintenance easier\n\n## Getting Started with CEPs\n\nReady to propose an enhancement? The journey begins by reviewing the full CEP guidelines to understand the detailed requirements. It is highly recommended that a single CEP contain a single key proposal or new idea. First, ascertain whether your idea is CEP-able by posting to the ContextVM community forums (Nostr, Signal, GitHub Discussions). When ready, create a GitHub Issue with the `CEP` and `proposal` tags. The next step is to find a sponsor by tagging relevant maintainers to get your proposal championed. Finally, engage with the community to build consensus and refine your idea based on feedback. For detailed instructions on submitting a CEP, please refer to our [CEP guidelines](https://docs.contextvm.org/spec/cep-guidelines/#submitting-a-cep).\n\n## Looking Ahead\n\nThe CEP process represents an important step forward for ContextVM's governance and development workflow. By establishing clear guidelines for protocol enhancement, we're ensuring that the main specification remains focused and clean while protocol extensions are properly documented and reviewed. This approach guarantees that community voices are heard and valued, and that innovation happens in a structured, collaborative environment.\n\nWe believe this process will help ContextVM continue to evolve in a way that benefits the entire ecosystem while maintaining the quality and security that our users expect. Drawing inspiration from successful projects gives us confidence that this approach will scale with our community's growth.\n\n## Join the Conversation\n\nThe CEP process is fundamentally community-driven, and we need your participation to make it successful! Whether you want to propose an enhancement, review existing proposals, or simply learn more about the protocol, there are many ways to get involved. You can browse existing CEP proposals in the ContextVM-docs repository, join discussions on GitHub, Nostr, or Signal, review and provide feedback on CEPs in development, or consider sponsoring proposals if you're a maintainer.\n\nTogether, we're building the future of ContextVM.\n\n## Additional Resources\n\nFor more information about ContextVM and the CEP process, please visit:\n\n- [CEP Guidelines Documentation](https://docs.contextvm.org/spec/cep-guidelines/)\n- [ContextVM Documentation](https://docs.contextvm.org/)\n- [ContextVM-docs Repository](https://github.com/ContextVM/contextvm-docs)",
+			"created_at": 1756305533,
+			"id": "9b575d9f107c7f0cf6a6582dee75e2b028cd6d89ff8f1f90f80878d0a5d9db6a",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "3ce500dcf91b91a0c322450fe26e3b560ea2936a68bc71d16f7274a9e33c4dd1767d621bfb0737a8045152edb6698cb38c5c7b587fc9737b9ea3ab3c89243772",
+			"tags": [
+				["d", "introducing-ceps"],
+				["title", "Meet CEPs — Propose. Review. Ship"],
+				[
+					"summary",
+					"We're excited to announce the launch of our new ContextVM Enhancement Proposal (CEP) guidelines! As ContextVM has grown, we recognized the need for a more structured approach to protocol evolution. This standardized process is designed to ensure that enhancements to the ContextVM protocol are well-vetted, thoroughly discussed, and properly documented while maintaining our community-driven approach to development.\n"
+				],
+				["published_at", "1755098910"],
+				[
+					"alt",
+					"This is a long form article, you can read it in https://habla.news/a/naddr1qvzqqqr4gupzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqqf8yetvv4shx6twvukkueth94ekjar97vcl4k"
+				],
+				["t", "cep"],
+				["t", "nostr"],
+				["t", "mcp"],
+				["t", "contextvm"],
+				["t", "cvm"],
+				["t", "ctxvm"],
+				["t", "ai"],
+				["t", "llm"],
+				["t", "freedom"],
+				["t", "internet"],
+				[
+					"image",
+					"https://image.nostr.build/766e2080a058797690ad298542ff2e491bb942eaebb8fa52335077178c23f1f7.jpg"
+				],
+				["t", "submitting"]
+			]
+		},
+		{
+			"content": "We are thrilled to announce the launch of the brand new ContextVM website, now live at [contextvm.org](https://contextvm.org)! This is a major step forward in our mission to create a truly sovereign, resilient, and open marketplace for computational tools and services.\n\nThis first version of our new site is fully functional and provides the core tools you need to engage with the ContextVM servers. Our primary focus is on making it simple to discover, connect to, and use ContextVM servers.\n\n### Discover and Connect\n\nThe new website acts as your gateway to the ContextVM ecosystem. The key functionality allows you to:\n\n*   **Discover Public Servers:** Find and explore publicly available ContextVM servers shared by the community.\n*   **Connect to Private Servers:** The platform is designed not just for public use, but to give you a seamless interface for connecting to and using your own private servers. Run a service on your machine at home and access it from anywhere, securely and privately.\n\nOur goal is to break down the barriers of traditional networking. With ContextVM, running a service is as simple as running an app on your laptop—no public IP addresses, complex firewall rules, or gatekeepers required. This new website is the user-friendly portal to that experience.\n\nShort demo of the site:\nhttps://video.nostr.build/4a0f4498cadb8e165d96118ece0714d6c03f2b135d340871cc89567a5cf93195.webm\n\n### A New Home for a Growing Project\n\nAs part of this launch, we've reorganized our online presence to better serve the community:\n\n*   **New Pages:** The site now includes a **Blog** (which you're reading right now!), a comprehensive **About** page explaining our vision, and an **FAQ** to answer common questions. We want to provide clear, accessible information for everyone, from new users to experienced developers.\n*   **Dedicated Docs:** All of our technical documentation has been moved to its new home at [docs.contextvm.org](https://docs.contextvm.org).\n\n### Openly Built and Ready for Contribution\n\nIn the spirit of decentralization and collaboration, the entire website is open source. It’s built with modern tools, including Svelte 5 and the `applesauce` Nostr library. We encourage you to check out the code, fork it, and contribute.\n\nWhile this first iteration is stable and fully working, we are continually iterating to add new features and improve the design.\n\n### We Need Your Help! A Call for Designers\n\nWe are actively looking for talented designers to help us shape the future of the ContextVM interface. If you have experience in UI/UX design and believe in a more open, permissionless internet, we would love to hear from you. Your contribution can make a massive impact on the usability and appeal of the project.\n\n### Get Involved\n\nWhether you're a developer, a designer, or simply someone who believes in a more sovereign web, there are many ways to get involved.\n\n*   Explore the new website at [contextvm.org](https://contextvm.org).\n*   Dive into the documentation at [docs.contextvm.org](https://docs.contextvm.org).\n*   Contribute to the project on GitHub at [github.com/contextvm](https://github.com/contextvm).\n*   Join the conversation in our Signal group: [Join the group](https://signal.group/#CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg-0gLNdusnb3wLR).\n\nIf you have any questions, doubts, or need help with anything—from running your own server to connecting it with LLMs—please don't hesitate to get in contact.",
+			"created_at": 1755098914,
+			"id": "7c331a609dcce773596743514e1c31e010dfa3159b9184aa6c287cbe41a112b2",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "ac1434f4bf1cf8e84898ff239a189dedf97c326cbf4b75c0cb5f75f5b9f2825164cb6135dd9309bb019d159ce101542179ef42e691a2d5cfd3a3bd393d7edc10",
+			"tags": [
+				["d", "releasing-new-site"],
+				["title", "Releasing the new ContextVM website 🚀"],
+				[
+					"summary",
+					"We are thrilled to announce the launch of the brand new ContextVM website, now live at contextvm.org! This is a major step forward in our mission to create a truly sovereign, resilient, and open marketplace for computational tools and services."
+				],
+				["t", "nostr"],
+				["t", "mcp"],
+				["t", "contextvm"],
+				["t", "cvm"],
+				["t", "ctxvm"],
+				["t", "ai"],
+				["t", "llm"],
+				["t", "freedom"],
+				["t", "internet"],
+				[
+					"image",
+					"https://image.nostr.build/98c21918d6a4d4c26b9bfb98db71d988069b291e40f7440c030c7c766403808d.jpg"
+				],
+				["published_at", "1755098910"],
+				[
+					"alt",
+					"This is a long form article, you can read it in https://habla.news/a/naddr1qvzqqqr4gupzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqqf8yetvv4shx6twvukkueth94ekjar97vcl4k"
+				],
+				["t", "CjQKIOgvfFJf8ZFZ1SsMx7teFqNF73sZ9Elaj_v5i6RSjDHmEhAB3wO1Rg"]
+			]
+		},
+		{
+			"content": "The digital world stands at a crossroads. We were promised a frontier of boundless connection and creativity, an open commons for all. Instead, we find ourselves in a landscape of walled gardens, governed by central authorities who act as gatekeepers to our data, our identity, and even our lives. New standards emerge, promising interoperability and a more connected future, yet they are often built upon the very same fractured and centralized foundations.\n\nThe Model Context Protocol (MCP) is one such standard—a powerful new language designed for AI models to use, communicate, and collaborate with digital tools, resources, and more. While focused on AI, its potential extends far beyond that use case. MCP holds the promise of breaking down silos, and connect everything allowing for complex, automated workflows across countless services, offering a glimpse into a more intelligent and integrated digital world. You can learn more about it [here](https://modelcontextprotocol.org).\n\nBut a new language is not enough if it is spoken only within the walls of the old castles. The current trajectory of MCP, while well-intentioned, risks tethering its vast potential to the gatekeepers of the old world: centralized identity providers, operational complexity, permissioned registries, and traditional payment systems.\n\nWe believe that a different path is not only possible but necessary. This is the 'why' behind ContextVM. ContextVM is not a new protocol; we are not replacing MCP. Instead, we are liberating it through Nostr and Bitcoin, by forging a new foundation for censorship-resistant collaboration. Any existing MCP client or server can adopt our specification or SDK to use Nostr as a transport. Furthermore, the tools we are developing will enable them to communicate via Nostr seamlessly, even without explicit support, thereby breaking free from centralized constraints.\n\n## The Chains of the Old World: MCP's Current Path\n\nTo understand where we are going, we must first understand where we are. The standard implementation of MCP relies on architectures that, while familiar, carry the baggage of centralization. This isn't a flaw in the protocol itself, but a choice of building materials—and these choices have consequences.\n\n*   **The Gatekeeper of Identity (OAuth):** Access in the current MCP world is often guarded by OAuth. While theoretically an open specification, in reality is centralized and federated, OAuth was primarily designed for humans logging into web applications. This model acts as a central checkpoint, creating a bottleneck for autonomous, headless computation. It forces participants into a permissioned system where identity is delegated, not owned, and every actor must present their credentials to a central authority, thereby limiting the spontaneous collaboration inherent to decentralized computing.\n\n*   **The King's Map (Centralized Registries):** How do you find a service in the MCP ecosystem? You consult a central registry. A curated list. A map drawn by a central authority, showing only what it has approved. This creates a permissioned ecosystem where innovation is gated. If you are not on the map, you do not exist. This is a barrier to entry, a point of control, and a single point of failure. It slows growth and stifles the \"long-tail\" of small, niche, or experimental providers.\n\n*   **The Toll Roads (Conventional Payments):** How do providers sustain themselves? Through the toll roads of traditional finance—Stripe, bank transfers, and credit cards. These systems are slow, expensive, and exclusive. They are ill-suited for the fluid, per-use, micro-transaction economy that a truly open network requires, forming another layer of control, a barrier for small operators, and an anchor to the old world.\n\nThis is the path of least resistance—paving over the old cow paths. It leads to a world that is more connected, yes, but no more free. It domesticates the wild potential of MCP, keeping it safely within existing walled gardens. ContextVM chooses a different path.\n\n\n## The ContextVM Difference: A Declaration of Digital Sovereignty\n\nContextVM is our answer. It is not an incremental improvement. It is a fundamental paradigm shift, built on the bedrock principles of Nostr: simplicity, sovereignty, and censorship-resistance. We replace the weak links of centralization with the unbreakable chains of cryptography.\n\n*   **Your Keys, Your Identity:** We discard central delegated authority. In the world of ContextVM, your identity is your cryptographic key pair—a sovereign passport, not a permission slip. It is owned and controlled by you, requiring no central issuer. Every interaction, request, and piece of data is cryptographically signed, providing undeniable proof of origin and integrity. This creates a trustless environment where everyone can interact securely and directly, without intermediaries.\n\n*   **The Open Town Square (Decentralized Discovery):** We tear up the king's map. In its place, we have the open, chaotic, and vibrant town square of Nostr relays. Anyone, anywhere, can announce a service by simply broadcasting a signed message. There are no gatekeepers. There is no central registry. Discovery is permissionless and dynamic. Clients subscribe to relays and learn about the ecosystem in real-time. This is how a thousand flowers bloom. This is how innovation accelerates.\n\n*   **Awakening the World's Dormant Computation:** The traditional model requires a public server, a fixed address on the internet. This is a significant barrier, limiting participation to those with the technical skills and resources to maintain public infrastructure. Nostr relays shatter this barrier. They act as a simple, distributed message bus. A ContextVM server needs no public IP, no open ports, no DNS name. It can run on a laptop behind a firewall, a Raspberry Pi in a dorm room, or a phone in a remote village. It only needs an outbound connection to a relay.\n\n    This single innovation is transformative. It unlocks the vast, dormant computational power of millions of devices, turning every connected device into a potential node in a global, decentralized network. This is not just about making things easier; it's about fundamentally democratizing participation and value creation.\n\n*   **The Economy of Freedom (Bitcoin Micropayments):** We bypass the toll roads. ContextVM enables direct integration with the Bitcoin Lightning Network, unleashing a true peer-to-peer economy. Payments can be per-use, instantaneous, and infinitesimally small, with near-zero fees. This is the lifeblood of a bottom-up economy, allowing any provider to be compensated directly and without intermediaries. It is a borderless, private, permissionless, and censorship-resistant economic layer for an open and decentralized ecosystem.\n\n\n## Our Vision: A New Computational Commons\n\nWhat does this future look like?\n\nIt looks like a journalist in a censored nation hosting sensitive reports, photographs, and documents as MCP resources on a laptop in their safe house. These resources are instantly accessible worldwide using ContextVM and Nostr relays, with no public web server, IP address, or domain that can be seized or shut down. The information flows freely, protected by cryptography and decentralization.\n\nIt looks like an indie developer in a niche market running a powerful, specialized tool as a Bitcoin-paid MCP server from their home office. Users from anywhere in the world can access and pay for this tool instantly, rewarding the creator directly without needing a corporate bank account or payment processor.\n\nIt looks like a grassroots community building and sharing its own educational tools and resources, tailored to its needs. Each tool and resource is hosted and run by a community member, creating a resilient, anti-fragile network of knowledge.\n\nIt looks like an enthusiastic engineer in their garage launching a novel service to the world from their laptop, with no upfront cost or permission required.\n\nFor everyone of these innovators, users benefit directly. They gain access to a vibrant, competitive, and permissionless marketplace of capabilities.\n\nOur vision is not merely to build better infrastructure for MCP and AI. Our vision is to cultivate a **new computational commons**: a sovereign, resilient, and open marketplace of ideas, resources, and capabilities, where value flows freely to those who create it. This is a world where the right to compute is as fundamental as the right to speak.\n\nThis is a world where innovation is no longer the exclusive domain of heavily capitalized corporations. It is a world where a lone builder with a powerful idea can compete on a level playing field. It is a world where the vast, untapped power of our collective devices is awakened, creating a collaborative network that is more resilient, more diverse, and more powerful than any centralized cloud.\n\n## The Call to Action: Build the Future with Us\n\nContextVM is more than just code; it is a community-driven, open-source project and a declaration that the internet is not a finished product. It asserts that the ideals of decentralization, sovereignty, and permissionless innovation are not nostalgic dreams but achievable realities.\n\nBut we cannot build this future alone. The initial tools are ready, the specification is public, and the frontier is open, waiting for pioneers. We are calling on the sovereign engineers, the builders, the innovators, and the freedom thinkers to join us.\n\nVisit us at **[contextvm.org](https://contextvm.org)**. Explore the code, run a server, build a client, use it, and join the conversation to help us build a more liberated digital future.\n\nThe digital world was meant to be a vast, open territory for human creativity to flourish. It has become a landscape of enclosures. The fences are being built higher every day.\n\nIt is time to tear them down.\n",
+			"created_at": 1753294993,
+			"id": "591a5cdb1812b2ced131b0fb5a0728130f64c15ee2f4ebef2ee337b612923d33",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "7f832f3e437326a73a1d18b9ce104b5c3ae20ebca69c4994a44bb6e67463d6974fb8f83fc472894feb78dfb4af20f1017d75201cced98794d12aeefb883c826b",
+			"tags": [
+				["d", "forging-a-new-frontier"],
+				["title", "Forging a New Frontier for Censorship-Resistant and Sustainable Collaboration"],
+				[
+					"summary",
+					"The digital world stands at a crossroads. We were promised a frontier of boundless connection and creativity, an open commons for all. Instead, we find ourselves in a landscape of walled gardens, governed by central authorities who act as gatekeepers to our data, our identity, and even our lives. New standards emerge, promising interoperability and a more connected future, yet they are often built upon the very same fractured and centralized foundations."
+				],
+				["t", "mcp"],
+				["t", "contextvm"],
+				["t", "ai"],
+				["t", "llm"],
+				["t", "freedom"],
+				["t", "tech"],
+				[
+					"image",
+					"https://v3.fal.media/files/zebra/QzXwEBXpDOkrODGvtON5g_78386f8f3c04497b9852905b914b8c94.png"
+				],
+				["published_at", "1753294989"],
+				[
+					"alt",
+					"This is a long form article, you can read it in https://habla.news/a/naddr1qvzqqqr4gupzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqqtxvmmjva5kueedvykkueth94n8ymmww35k2ussqz4ct"
+				]
+			]
+		},
+		{
+			"content": "## Introducing New Security and Privacy Features in DVMCP\n\nWe're excited to announce a new update to DVMCP, bringing enhanced privacy and security with encryption for transport communication and the launch of private server discovery. These features are designed to offer greater flexibility, stronger data protection, and new ways to manage access within the DVMCP ecosystem.\n\n**Seamless Encryption for Private Communication**\n\nSecurity is at the core of this release. DVMCP now allows you to encrypt communications between clients and servers using nip-17 and giftwraps, ensuring that the communication stays confidential as it travels across the network. By default, DVMCP uses a flexible encryption system based on three straightforward modes:\n\n- **Disabled** mode ensures backward compatibility or operation in trusted environments, with encryption turned off.\n- **Optional** (the default) uses message format mirroring: if a client sends an encrypted message, the server responds in kind; if not, responses are unencrypted. This provides seamless compatibility without guesswork.\n- **Required** mode enforces encryption on every message. Unencrypted messages are rejected.\n\nConfiguring the encryption mode is as simple as adding a line to your YAML configuration file, letting operators choose the right balance of security and accessibility for their needs. This configuration can be done in both packages, bridge and discovery, which means that whether you are consuming or serving, you can ensure that encryption suits your needs.\n\nDue to this new feature, we also updated the DVMCP relay to accept events with kind 1059 giftwraps, which are stored temporarily as ephemeral events are, using the same ring buffer ephemeral events use. This ensures we can handle large loads of them efficiently. Note that giftwraps are sometimes rejected by some relays due to their strong encryption, as they could be a vector of spammy attacks. The DVMCP relay is free to use, and you can connect with this URL: 'wss://r.dvmcp.fun'.\n\n**Private (Unannounced) Servers**\n\nThe update also introduces a new way to run and connect with servers privately. Private servers remain unannounced on relays, making them invisible to the wider network unless specifically targeted. Clients can connect to the servers from a provider by knowing the provider's public key, or target an individual server from a provider adding its server ID.\n\nThis is made possible by following the same MCP handshake pattern. Communication begins with the client sending an initialization request directly to the server. The server responds with its details and capabilities, and then the client can request to list available capabilities, tools, resources, or prompts. The handshake is completed when the client confirms successful initialization.\n\n**How Encryption and Private Discovery Work Together**\n\nBoth encryption and private server discovery are fully compatible. If the client supports encryption it will attempt the handshake in a encrypted way, if the server the client is attempting to connect supports encryption, it signals this in the handshake to ensure all subsequent communication remains protected. If the server the client is attempting to connect doesn't support encryption but the client does in 'optional' (default) mode, it will fall back to unencrypted communication and stay unencrypted for the subsequent requests. If the client has 'required' encryption mode but the server doesn't support encryption, the handshake is rejected as the client will not fall back to unencrypted communication.\n\nYou can run a fleet of private, unannounced servers that only accept connections from trusted clients, and you can also ensure this authorization access using the pubkey whitelist configuration, with all data exchanges encrypted. This architecture is ideal for sensitive projects, custom enterprise deployments, or any environment where data privacy and controlled access are mission-critical.\n\n**Other updates:**\nFor this update, we also refactored the configuration wizzard of the packages to be more intuitive, also added the handling of kind 1059 giftwraps to the DVMCP relay, and we added a badge in dvmcp.fun for servers that support encryption, also all the servers offered by DVMCP have being updated to the latest version of DVMCP and now they support encryption.\n\n**Why These Changes?**\n\nOur goal is to make DVMCP both secure and adaptable. Encryption ensures that only intended recipients can interpret the payloads, while private server discovery puts you in control of the visibility in the network, and who can access your services. By combining these features, DVMCP offers a versatile platform for deploying MCP servers, whether you want to broadcast to the world or remain 'invitation only'.\n\nGet started with the latest DVMCP today to take advantage of these privacy and security enhancements, and tailor your deployments for the world you want to build.\n\n**Next steps:**\n\nThe next steps for DVMCP are, write documentation and create a docs page, to stay up-to-date with the MCP specification, as it recently received an update on [**2025-06-18**](https://modelcontextprotocol.io/specification/2025-06-18) that introduced new features such as structured tool output schemas, elicitation, and other enhancements. Also as part of this process, it is important to take a step back, review our current implementation, and understand how we can further improve it.\n\nWe are designing a refactor of the DVMCP packages, as the MCP protocol and its SDK have evolved. During the process of creating DVMCP, we have gained valuable insights that will help us structure our packages in a more lightweight and versatile manner, reducing some accumulated technical debt. This will allow us to make DVMCP more library-like, which is the direction we have already started to explore with the `@dvmcp/commons` package. We now have a clearer understanding of how to build a better architecture for our packages, and we are ready to fully implement these improvements. ",
+			"created_at": 1750666382,
+			"id": "e19bf7ef47348731ebc7e14929a20d8d027e432a966db8e5e5f9485ff5717068",
+			"kind": 30023,
+			"pubkey": "6b3780ef2972e73d370b84a3e51e7aa9ae34bf412938dcfbd9c5f63b221416c8",
+			"sig": "57306131ac2d7742dd966a39abb10c3d71642718df54f0267c34f6e5ba4b979b293ffddb5233e38ffb3e4f8ec71d7c8ce25e095f97715883b9c6246bc2f5cabd",
+			"tags": [
+				["d", "new-privacy-features"],
+				["title", "Encryption and private servers - New Security and Privacy Features in DVMCP"],
+				[
+					"summary",
+					"We're excited to announce a new update to DVMCP, bringing enhanced privacy and security with encryption for transport communication and the launch of private server discovery. These features are designed to offer greater flexibility, stronger data protection, and new ways to manage access within the DVMCP ecosystem."
+				],
+				["t", "dvmcp"],
+				["t", "mcp"],
+				["t", "dvm"],
+				["t", "encryption"],
+				["t", "privacy"],
+				[
+					"image",
+					"https://image.nostr.build/103608a2a53ce1323148bfeeab760c9aca39be689b03387def8616a617622a22.png"
+				],
+				["published_at", "1750666377"],
+				[
+					"alt",
+					"This is a long form article, you can read it in https://habla.news/a/naddr1qvzqqqr4gupzq6ehsrhjjuh885mshp9ru50842dwxjl5z2fcmnaan30k8v3pg9kgqq2xueth94c8y6tkv93hjttxv4shgatjv4es5f8gaq"
+				]
+			]
+		}
+	],
+	"servers": [
+		{
+			"event": {
+				"content": "{\"protocolVersion\":\"2025-11-25\",\"capabilities\":{\"tools\":{}},\"serverInfo\":{\"name\":\"RelayVM\",\"version\":\"0.1.0\"}}",
+				"created_at": 1790180438,
+				"id": "247dbc9e9acb9a6e1395c7d9a65e7c79fafca089c87008c0949385b981d7e70b",
+				"kind": 11316,
+				"pubkey": "65a334b02f5913cf2c1f73376044df11254166676e7d499d0c34e2ca10cf3e16",
+				"sig": "ac2b8ec9eef8963db49bc6a4ee0fcc888c143a838043ab767eaa4536b172a2eb62a7f212590ba1b32df6fc6e7de58695cc523e8c949999c7cc8b2d8b91871f72",
+				"tags": [
+					["name", "RelayVM"],
+					[
+						"about",
+						"ContextVM server that aggregates NIP-66 relay intelligence and exposes it via MCP over Nostr. Service provided by nostr.watch"
+					],
+					["support_encryption"],
+					["support_encryption_ephemeral"],
+					["pmi", "bitcoin-lightning-bolt11"],
+					["payment_interaction", "explicit_gating"],
+					["support_oversized_transfer"],
+					["cap", "tool:relays/list", "2", "sats"],
+					["cap", "tool:relays/list/detailed", "3", "sats"],
+					["cap", "tool:relays/list/full", "4", "sats"],
+					["cap", "tool:relays/state", "1", "sats"],
+					["cap", "tool:relays/search", "3", "sats"],
+					["cap", "tool:relays/search/detailed", "4", "sats"],
+					["cap", "tool:relays/search/full", "5", "sats"],
+					["cap", "tool:relays/nearby", "3", "sats"],
+					["cap", "tool:relays/nearby/detailed", "4", "sats"],
+					["cap", "tool:relays/nearby/full", "5", "sats"],
+					["cap", "tool:relays/bbox", "3", "sats"],
+					["cap", "tool:relays/bbox/detailed", "4", "sats"],
+					["cap", "tool:relays/bbox/full", "5", "sats"],
+					["cap", "tool:relays/labels", "1", "sats"],
+					["cap", "tool:relays/by/label", "3", "sats"],
+					["cap", "tool:relays/by/label/detailed", "4", "sats"],
+					["cap", "tool:relays/by/label/full", "5", "sats"],
+					["cap", "tool:relays/by/software", "2", "sats"],
+					["cap", "tool:relays/by/network", "2", "sats"],
+					["cap", "tool:relays/by/nip", "2", "sats"],
+					["cap", "tool:relays/by/country", "3", "sats"],
+					["cap", "tool:relays/compare", "5", "sats"],
+					["cap", "tool:relays/online", "2", "sats"],
+					["cap", "tool:relays/offline", "2", "sats"],
+					["cap", "tool:relays/dead", "2", "sats"],
+					["cap", "tool:monitors/get", "1", "sats"],
+					["cap", "tool:monitors/analytics", "5", "sats"],
+					["cap", "tool:monitors/analytics/get", "2", "sats"]
+				]
+			},
+			"relays": ["wss://relay.contextvm.org"]
+		},
+		{
+			"event": {
+				"content": "{\"protocolVersion\":\"2025-11-25\",\"capabilities\":{\"tools\":{\"listChanged\":true}},\"serverInfo\":{\"name\":\"plebeian-currency-server\",\"version\":\"1.0.0\"}}",
+				"created_at": 1790101463,
+				"id": "469fa3ce5674477ad588478f232c55e5b9862b0e6ed1591c383e5f6ae33b8b12",
+				"kind": 11316,
+				"pubkey": "29bd6461f780c07b29c89b4df8017db90973d5608a3cd811a0522b15c1064f15",
+				"sig": "8673bbe6fa119a1f4890f852a747d69137b050d9a166edbccb3cdc786f85118fa0c4314b6dd79bf67896bedd8494b4c859bd750a1397c7c06e300b6cc44b975d",
+				"tags": [
+					["name", "Plebeian Currency Server"],
+					[
+						"about",
+						"BTC exchange rate server aggregating Yadio, CoinDesk, Binance, and CoinGecko prices via median calculation."
+					],
+					["website", "https://plebeian.market"],
+					["support_encryption"],
+					["support_encryption_ephemeral"]
+				]
+			},
+			"relays": ["wss://nos.lol"]
+		},
+		{
+			"event": {
+				"content": "{\"protocolVersion\":\"2025-11-25\",\"capabilities\":{\"tools\":{\"listChanged\":true}},\"serverInfo\":{\"name\":\"SkateSpots\",\"version\":\"1.0.0\"}}",
+				"created_at": 1790640019,
+				"id": "eba8f0a88aa9de541293e248a5bfff52cda36b374c23bb843846798e0de5a19f",
+				"kind": 11316,
+				"pubkey": "e3564bb877adb0c99a7e4973ccb22e516d7d9eca0027d0bd62a04174ed670530",
+				"sig": "bb90f534bfc8f49e0966f4dbbf4c7ad93faa2cf4ebaa206ad6a6e75dfa188339127bde02bb23a97336eba22697d5e4309fa4d2a4bb15cafe9f070c5b0c586c40",
+				"tags": [
+					["name", "SkateSpots Data Server"],
+					[
+						"about",
+						"Structured query access to the global SkateSpots database on Nostr. Find skate spots, events, coaches, filmers, video editors, and gear listings."
+					],
+					["website", "https://skate-spots.org"],
+					["picture", "https://skate-spots.org/images/logo.png"],
+					["support_encryption"],
+					["support_encryption_ephemeral"],
+					["support_oversized_transfer"]
+				]
+			},
+			"relays": ["wss://relay.contextvm.org"]
+		}
+	]
+}
diff --git a/src/lib/content/seo-snapshot.test.ts b/src/lib/content/seo-snapshot.test.ts
new file mode 100644
index 0000000..0444350
--- /dev/null
+++ b/src/lib/content/seo-snapshot.test.ts
@@ -0,0 +1,33 @@
+import { describe, expect, test } from 'bun:test';
+import { npubEncode, nprofileEncode } from 'nostr-tools/nip19';
+import type { Event } from 'nostr-tools';
+import { decodeServerPubkey, getArticleIdentifier } from './seo-snapshot';
+
+const pubkey = '65a334b02f5913cf2c1f73376044df11254166676e7d499d0c34e2ca10cf3e16';
+
+describe('getArticleIdentifier', () => {
+	test('returns the addressable event identifier', () => {
+		const event = { tags: [['d', 'article-slug']] } as Event;
+		expect(getArticleIdentifier(event)).toBe('article-slug');
+	});
+
+	test('rejects events without a non-empty identifier', () => {
+		const event = { tags: [['d', '']] } as Event;
+		expect(getArticleIdentifier(event)).toBeNull();
+	});
+});
+
+describe('decodeServerPubkey', () => {
+	test('normalizes hex, npub, and nprofile identifiers to the same pubkey', () => {
+		expect(decodeServerPubkey(pubkey)).toBe(pubkey);
+		expect(decodeServerPubkey(npubEncode(pubkey))).toBe(pubkey);
+		expect(
+			decodeServerPubkey(nprofileEncode({ pubkey, relays: ['wss://relay.contextvm.org'] }))
+		).toBe(pubkey);
+	});
+
+	test('rejects unsupported and malformed identifiers', () => {
+		expect(decodeServerPubkey('relayvm@contextvm.org')).toBeNull();
+		expect(decodeServerPubkey('not-a-server-id')).toBeNull();
+	});
+});
diff --git a/src/lib/content/seo-snapshot.ts b/src/lib/content/seo-snapshot.ts
new file mode 100644
index 0000000..4b922d7
--- /dev/null
+++ b/src/lib/content/seo-snapshot.ts
@@ -0,0 +1,48 @@
+import { decode } from 'nostr-tools/nip19';
+import type { Event } from 'nostr-tools';
+import snapshotData from './seo-snapshot.json';
+
+export interface ServerSnapshot {
+	event: Event;
+	relays: string[];
+}
+
+export interface SeoSnapshot {
+	schemaVersion: 1;
+	generatedAt: string;
+	articles: Event[];
+	servers: ServerSnapshot[];
+}
+
+export const seoSnapshot = snapshotData as SeoSnapshot;
+
+export function getArticleIdentifier(event: Event): string | null {
+	return event.tags.find((tag) => tag[0] === 'd')?.[1] || null;
+}
+
+export function getSnapshotArticle(identifier: string): Event | null {
+	return (
+		seoSnapshot.articles.find((article) => getArticleIdentifier(article) === identifier) ?? null
+	);
+}
+
+export function decodeServerPubkey(identifier: string): string | null {
+	if (/^[0-9a-f]{64}$/.test(identifier)) return identifier;
+
+	try {
+		const decoded = decode(identifier);
+		if (decoded.type === 'npub') return decoded.data;
+		if (decoded.type === 'nprofile') return decoded.data.pubkey;
+	} catch {
+		return null;
+	}
+
+	return null;
+}
+
+export function getSnapshotServer(identifier: string): ServerSnapshot | null {
+	const pubkey = decodeServerPubkey(identifier);
+	if (!pubkey) return null;
+
+	return seoSnapshot.servers.find((server) => server.event.pubkey === pubkey) ?? null;
+}
diff --git a/src/lib/queries/serverQueries.ts b/src/lib/queries/serverQueries.ts
index 6946d30..7aad0e1 100644
--- a/src/lib/queries/serverQueries.ts
+++ b/src/lib/queries/serverQueries.ts
@@ -18,7 +18,7 @@ import { getSeenRelays, mergeRelaySets } from 'applesauce-core/helpers/relays';
 import { relayStore } from '$lib/stores/relay-store.svelte';
 import { encodeServerIdentity, decodeServerIdentifier, type ServerIdentity } from '$lib/utils';
 
-interface ServerQueryResult {
+export interface ServerQueryResult {
 	isPublic: boolean;
 	server: ServerAnnouncement | null;
 }
@@ -33,9 +33,15 @@ interface ParsedRelayList {
 	hasPublishedRelayList: boolean;
 }
 
-export function useServerAnnouncement(pubkey: string, relayHints: string[] = []) {
+export function useServerAnnouncement(
+	pubkey: string,
+	relayHints: string[] = [],
+	initialData?: ServerQueryResult
+) {
 	return createQuery<ServerQueryResult | null>({
 		queryKey: serverKeys.announcement(pubkey),
+		initialData,
+		initialDataUpdatedAt: initialData ? 0 : undefined,
 		queryFn: async () => {
 			let server: ServerAnnouncement | null = null;
 			const event = await lastValueFrom(
@@ -47,9 +53,15 @@ export function useServerAnnouncement(pubkey: string, relayHints: string[] = [])
 	});
 }
 
-export function useServerIdentity(pubkey: string, explicitRelayHints: string[] = []) {
+export function useServerIdentity(
+	pubkey: string,
+	explicitRelayHints: string[] = [],
+	initialData?: ServerIdentity
+) {
 	return createQuery<ServerIdentity>({
 		queryKey: serverKeys.identity(pubkey),
+		initialData,
+		initialDataUpdatedAt: initialData ? 0 : undefined,
 		queryFn: async () => {
 			const relayListEvent = await fetchServerRelayListEvent(pubkey, explicitRelayHints);
 			const publishedRelayList = parseServerRelayList(relayListEvent);
diff --git a/src/lib/seo.test.ts b/src/lib/seo.test.ts
new file mode 100644
index 0000000..6dc05a6
--- /dev/null
+++ b/src/lib/seo.test.ts
@@ -0,0 +1,29 @@
+import { describe, expect, it } from 'bun:test';
+import { absoluteSiteUrl, canonicalUrl } from './seo';
+
+describe('canonicalUrl', () => {
+	it('uses the production origin and strips the GitHub Pages base path', () => {
+		expect(canonicalUrl('/contextvm-site/about', '/contextvm-site')).toBe(
+			'https://contextvm.org/about'
+		);
+	});
+
+	it('preserves encoded path segments', () => {
+		expect(canonicalUrl('/blog/an%20article')).toBe('https://contextvm.org/blog/an%20article');
+	});
+
+	it('keeps the root URL canonical', () => {
+		expect(canonicalUrl('/contextvm-site', '/contextvm-site')).toBe('https://contextvm.org/');
+	});
+});
+
+describe('absoluteSiteUrl', () => {
+	it('resolves site assets and preserves remote URLs', () => {
+		expect(absoluteSiteUrl('/apple-touch-icon-180x180.png')).toBe(
+			'https://contextvm.org/apple-touch-icon-180x180.png'
+		);
+		expect(absoluteSiteUrl('https://cdn.example.com/image.png')).toBe(
+			'https://cdn.example.com/image.png'
+		);
+	});
+});
diff --git a/src/lib/seo.ts b/src/lib/seo.ts
new file mode 100644
index 0000000..9ece01e
--- /dev/null
+++ b/src/lib/seo.ts
@@ -0,0 +1,20 @@
+export const SITE_ORIGIN = 'https://contextvm.org';
+
+function stripBasePath(pathname: string, basePath: string): string {
+	if (!basePath) return pathname;
+	if (pathname === basePath) return '/';
+	if (pathname.startsWith(`${basePath}/`)) return pathname.slice(basePath.length);
+	return pathname;
+}
+
+export function canonicalUrl(pathname: string, basePath = ''): string {
+	const path = stripBasePath(pathname, basePath);
+	return new URL(path.startsWith('/') ? path : `/${path}`, SITE_ORIGIN).href;
+}
+
+export function absoluteSiteUrl(value: string, basePath = ''): string {
+	if (/^https?:\/\//.test(value)) return value;
+
+	const path = value.startsWith('./') ? `/${value.slice(2)}` : value;
+	return canonicalUrl(path, basePath);
+}
diff --git a/src/routes/+error.svelte b/src/routes/+error.svelte
index 6647be2..1c4204c 100644
--- a/src/routes/+error.svelte
+++ b/src/routes/+error.svelte
@@ -2,8 +2,15 @@
 	import { page } from '$app/state';
 	import { resolve } from '$app/paths';
 	import { Button } from '$lib/components/ui/button';
+	import SEO from '$lib/components/SEO.svelte';
 </script>
 
+<SEO
+	title={page.status === 404 ? 'Page not found' : 'Error'}
+	description="The requested ContextVM page could not be displayed."
+	robots="noindex, nofollow"
+/>
+
 <main class="flex min-h-[calc(100vh-3.5rem)] items-center justify-center bg-background px-4">
 	<div class="mx-auto max-w-md text-center">
 		<p class="mb-2 text-7xl font-bold tracking-tight text-primary">
diff --git a/src/routes/+layout.svelte b/src/routes/+layout.svelte
index be5e72d..d2cca3f 100644
--- a/src/routes/+layout.svelte
+++ b/src/routes/+layout.svelte
@@ -10,7 +10,6 @@
 	import { Toaster } from '$lib/components/ui/sonner/index.js';
 	import { QueryClientProvider } from '@tanstack/svelte-query';
 	import { queryClient } from '$lib/query-client';
-	import SEO from '$lib/components/SEO.svelte';
 
 	let { children } = $props();
 
@@ -18,8 +17,6 @@
 	setThemeContext({ components });
 </script>
 
-<SEO />
-
 <QueryClientProvider client={queryClient}>
 	<ModeWatcher />
 	<Header />
diff --git a/src/routes/+page.svelte b/src/routes/+page.svelte
index 7385826..6a95425 100644
--- a/src/routes/+page.svelte
+++ b/src/routes/+page.svelte
@@ -113,7 +113,7 @@
 					size="lg"
 					variant="outline"
 					class="w-full px-6 text-base transition-transform duration-200 hover:scale-105 sm:w-auto sm:px-8"
-					href="/servers"
+					href={resolve('/servers')}
 				>
 					Browse public servers
 				</Button>
@@ -172,7 +172,7 @@
 					</div>
 
 					<div class="mt-10 text-center sm:mt-12">
-						<Button size="lg" href="/servers">View all public servers</Button>
+						<Button size="lg" href={resolve('/servers')}>View all public servers</Button>
 					</div>
 				</div>
 			</div>
diff --git a/src/routes/about/+page.svelte b/src/routes/about/+page.svelte
index d0c0090..1877d2d 100644
--- a/src/routes/about/+page.svelte
+++ b/src/routes/about/+page.svelte
@@ -1,7 +1,5 @@
 <script lang="ts">
 	import { marked } from 'marked';
-	import DOMPurify from 'dompurify';
-	import { browser } from '$app/environment';
 	import Seo from '$lib/components/SEO.svelte';
 
 	// About page content in markdown
@@ -97,6 +95,8 @@ To get involved:
 ---
 
 *Built with ❤️ for the decentralized web*`;
+
+	const aboutHtml = marked.parse(aboutContent) as string;
 </script>
 
 <Seo
@@ -118,11 +118,8 @@ To get involved:
 	<div
 		class="prose prose-slate dark:prose-invert prose-sm sm:prose-base max-w-none [&>*:not(:first-child)]:mt-6"
 	>
-		{#await marked.parse(aboutContent) then html}
-			{#if browser}
-				<!-- eslint-disable-next-line svelte/no-at-html-tags -->
-				{@html DOMPurify.sanitize(html)}
-			{/if}
-		{/await}
+		<!-- aboutContent is source-controlled static copy. -->
+		<!-- eslint-disable-next-line svelte/no-at-html-tags -->
+		{@html aboutHtml}
 	</div>
 </article>
diff --git a/src/routes/blog/+page.svelte b/src/routes/blog/+page.svelte
index 5b82710..29ce0ba 100644
--- a/src/routes/blog/+page.svelte
+++ b/src/routes/blog/+page.svelte
@@ -1,5 +1,6 @@
 <script lang="ts">
 	import { articlesFilter } from '$lib/constants';
+	import { getArticleIdentifier } from '$lib/content/seo-snapshot';
 	import { eventStore } from '$lib/services/eventStore';
 	import { TimelineModel } from 'applesauce-core/models';
 	import ArticleCard from '$lib/components/ArticleCard.svelte';
@@ -7,11 +8,38 @@
 	import { createBlogArticlesLoader } from '$lib/services/loaders.svelte';
 	import { commonRelays } from '$lib/services/relay-pool';
 	import SEO from '$lib/components/SEO.svelte';
+	import type { Event } from 'nostr-tools';
+	import type { PageData } from './$types';
 
-	const blogArticles = eventStore.model(TimelineModel, articlesFilter);
+	let { data }: { data: PageData } = $props();
+
+	const liveArticles = eventStore.model(TimelineModel, articlesFilter);
+	let liveStatus = $state<'connecting' | 'available' | 'unavailable'>('connecting');
+	const articles = $derived.by(() => {
+		const byIdentifier = new Map<string, Event>();
+
+		for (const article of [...data.articles, ...$liveArticles]) {
+			const identifier = getArticleIdentifier(article);
+			if (!identifier) continue;
+
+			const current = byIdentifier.get(identifier);
+			if (!current || article.created_at > current.created_at) {
+				byIdentifier.set(identifier, article);
+			}
+		}
+
+		return [...byIdentifier.values()].sort((a, b) => b.created_at - a.created_at);
+	});
 
 	$effect(() => {
-		const sub = createBlogArticlesLoader(commonRelays).subscribe();
+		const sub = createBlogArticlesLoader(commonRelays).subscribe({
+			next: () => {
+				liveStatus = 'available';
+			},
+			error: () => {
+				liveStatus = 'unavailable';
+			}
+		});
 		return () => {
 			sub.unsubscribe();
 		};
@@ -24,11 +52,20 @@
 />
 
 <div class="container mx-auto px-4 py-8">
-	<h1 class="mb-8 text-3xl font-bold">Blog</h1>
+	<h1 class="mb-2 text-3xl font-bold">Blog</h1>
+	<p class="mb-8 text-sm text-muted-foreground">
+		Snapshot refreshed
+		<time datetime={data.generatedAt}
+			>{new Date(data.generatedAt).toLocaleDateString('en', {
+				dateStyle: 'medium',
+				timeZone: 'UTC'
+			})}</time
+		>. Live relay updates are {liveStatus}.
+	</p>
 
-	{#if $blogArticles.length}
+	{#if articles.length}
 		<div class="grid grid-cols-1 gap-6 md:grid-cols-2 lg:grid-cols-3">
-			{#each $blogArticles as article (article.id)}
+			{#each articles as article (article.id)}
 				<ArticleCard {article} />
 			{/each}
 		</div>
diff --git a/src/routes/blog/+page.ts b/src/routes/blog/+page.ts
new file mode 100644
index 0000000..6c620cf
--- /dev/null
+++ b/src/routes/blog/+page.ts
@@ -0,0 +1,7 @@
+import { seoSnapshot } from '$lib/content/seo-snapshot';
+import type { PageLoad } from './$types';
+
+export const load = (() => ({
+	articles: seoSnapshot.articles,
+	generatedAt: seoSnapshot.generatedAt
+})) satisfies PageLoad;
diff --git a/src/routes/blog/[id]/+page.svelte b/src/routes/blog/[id]/+page.svelte
index 885e351..e7bc38c 100644
--- a/src/routes/blog/[id]/+page.svelte
+++ b/src/routes/blog/[id]/+page.svelte
@@ -1,5 +1,5 @@
 <script lang="ts">
-	import { asset, resolve } from '$app/paths';
+	import { asset, base, resolve } from '$app/paths';
 	import { page } from '$app/state';
 	import ProfileCard from '$lib/components/ProfileCard.svelte';
 	import ServerNoteCard from '$lib/components/ServerNoteCard.svelte';
@@ -13,13 +13,20 @@
 	import DOMPurify from 'dompurify';
 	import { formatUnixTimestamp } from '$lib/utils';
 	import { browser } from '$app/environment';
-	import { onMount } from 'svelte';
-	import { goto } from '$app/navigation';
 	import SEO from '$lib/components/SEO.svelte';
 	import { relayStore } from '$lib/stores/relay-store.svelte';
 	import { commonRelays } from '$lib/services/relay-pool';
-	import { getArticleImage, getArticleTitle } from 'applesauce-common/helpers';
+	import {
+		getArticleImage,
+		getArticlePublished,
+		getArticleSummary,
+		getArticleTitle
+	} from 'applesauce-common/helpers';
 	import type { Event } from 'nostr-tools';
+	import type { PageData } from './$types';
+	import { absoluteSiteUrl, canonicalUrl, SITE_ORIGIN } from '$lib/seo';
+
+	let { data }: { data: PageData } = $props();
 
 	const pointer: AddressPointer = $derived({
 		kind: LongFormArticle,
@@ -30,12 +37,11 @@
 			: commonRelays
 	});
 
-	let loading = $state(true);
+	let relayLoading = $state(true);
 	let embeddedNotes = $state<Record<string, Event | undefined>>({});
 	const article = $derived(addressLoader(pointer));
-
 	const storedArticle = $derived(eventStore.model(ReplaceableModel, pointer));
-
+	const articleEvent = $derived($storedArticle ?? data.article);
 	const blogHref = $derived<`/blog`>('/blog');
 
 	type ArticleSegment =
@@ -51,54 +57,112 @@
 	$effect(() => {
 		const sub = article.subscribe({
 			error: () => {
-				loading = false;
+				relayLoading = false;
 			},
 			complete: () => {
-				loading = false;
+				relayLoading = false;
 			}
 		});
-		if ($storedArticle) loading = false;
+		if (articleEvent) relayLoading = false;
 		return () => {
 			sub.unsubscribe();
 		};
 	});
 
-	// Configure marked options
-	onMount(() => {
-		marked.setOptions({
-			breaks: true,
-			gfm: true
-		});
-	});
-
 	const logoBlackSrc = asset('/logo-black.svg');
-
-	// Dynamic SEO data for individual blog posts
-	let seoTitle = $state('Loading...');
-	let seoDescription = $state('Loading article...');
-	let seoImage = $state(logoBlackSrc);
-	let seoUrl = $state(`https://contextvm.com/blog/${page.params.id}`);
-	let seoType = $state('article' as 'website' | 'article');
-
-	// Update SEO data when article loads
-	$effect(() => {
-		if ($storedArticle) {
-			const articleTitle = getArticleTitle($storedArticle) || 'Untitled Article';
-			const articleImage = getArticleImage($storedArticle);
-			const contentPreview = $storedArticle.content.substring(0, 160) + '...';
-
-			seoTitle = articleTitle;
-			seoDescription = contentPreview;
-			seoImage = articleImage || logoBlackSrc;
-			seoUrl = `https://contextvm.com/blog/${page.params.id}`;
-			seoType = 'article';
-		}
-	});
+	const seoTitle = $derived(
+		articleEvent ? getArticleTitle(articleEvent) || 'Untitled Article' : 'Loading...'
+	);
+	const seoDescription = $derived(
+		articleEvent
+			? (getArticleSummary(articleEvent) || articleEvent.content).replace(/\s+/g, ' ').slice(0, 160)
+			: 'Loading article...'
+	);
+	const seoImage = $derived(
+		articleEvent ? getArticleImage(articleEvent) || logoBlackSrc : logoBlackSrc
+	);
+	const articleUrl = $derived(canonicalUrl(`/blog/${page.params.id ?? ''}`, base));
+	const articleImageUrl = $derived(absoluteSiteUrl(seoImage, base));
+	const articleStructuredData = $derived.by(() =>
+		articleEvent
+			? [
+					{
+						'@type': 'Article',
+						'@id': `${articleUrl}#article`,
+						headline: seoTitle,
+						description: seoDescription,
+						image: [articleImageUrl],
+						datePublished: new Date(getArticlePublished(articleEvent) * 1000).toISOString(),
+						dateModified: new Date(articleEvent.created_at * 1000).toISOString(),
+						author: { '@id': `${SITE_ORIGIN}/#organization` },
+						publisher: { '@id': `${SITE_ORIGIN}/#organization` },
+						mainEntityOfPage: articleUrl
+					},
+					{
+						'@type': 'BreadcrumbList',
+						itemListElement: [
+							{
+								'@type': 'ListItem',
+								position: 1,
+								name: 'Blog',
+								item: canonicalUrl('/blog')
+							},
+							{
+								'@type': 'ListItem',
+								position: 2,
+								name: seoTitle,
+								item: articleUrl
+							}
+						]
+					}
+				]
+			: []
+	);
 
 	function escapeRegex(value: string): string {
 		return value.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
 	}
 
+	function escapeHtml(value: string): string {
+		return value
+			.replace(/&/g, '&amp;')
+			.replace(/</g, '&lt;')
+			.replace(/>/g, '&gt;')
+			.replace(/"/g, '&quot;')
+			.replace(/'/g, '&#39;');
+	}
+
+	function isSafeMarkdownUrl(value: string, image: boolean): boolean {
+		try {
+			const protocol = new URL(value, SITE_ORIGIN).protocol;
+			return image
+				? protocol === 'http:' || protocol === 'https:'
+				: protocol === 'http:' ||
+						protocol === 'https:' ||
+						protocol === 'mailto:' ||
+						protocol === 'nostr:';
+		} catch {
+			return false;
+		}
+	}
+
+	const markdownRenderer = new marked.Renderer();
+	markdownRenderer.html = ({ text }) => escapeHtml(text);
+	markdownRenderer.link = function ({ href, title, tokens }) {
+		const label = this.parser.parseInline(tokens);
+		if (!isSafeMarkdownUrl(href, false)) return label;
+
+		const titleAttribute = title ? ` title="${escapeHtml(title)}"` : '';
+		const externalAttribute = /^https?:\/\//i.test(href) ? ' rel="external"' : '';
+		return `<a href="${escapeHtml(href)}"${titleAttribute}${externalAttribute}>${label}</a>`;
+	};
+	markdownRenderer.image = ({ href, title, text }) => {
+		if (!isSafeMarkdownUrl(href, true)) return escapeHtml(text);
+
+		const titleAttribute = title ? ` title="${escapeHtml(title)}"` : '';
+		return `<img src="${escapeHtml(href)}" alt="${escapeHtml(text)}"${titleAttribute}>`;
+	};
+
 	function parseEmbeddedEvents(content: string): Extract<ArticleSegment, { type: 'event' }>[] {
 		return Array.from(content.matchAll(NOSTR_EVENT_URI_REGEX))
 			.map((match) => {
@@ -132,11 +196,11 @@
 			);
 	}
 
-	async function parseArticleContent(content: string): Promise<ArticleSegment[]> {
+	function parseArticleContent(content: string): ArticleSegment[] {
 		const matches = Array.from(content.matchAll(NOSTR_URI_REGEX));
 		const segments: ArticleSegment[] = [];
 		const profiles: Array<Extract<ArticleSegment, { type: 'profile' }>> = [];
-		let markdownContent = content;
+		let markdownContent = content.replace(/\]\(\[(https?:\/\/[^\]\s]+)\]\(\1\)\)/g, ']($1)');
 
 		for (const [index, match] of matches.entries()) {
 			const value = match[0];
@@ -168,7 +232,7 @@
 			}
 		}
 
-		const html = await renderMarkdown(markdownContent);
+		const html = renderMarkdown(markdownContent);
 		const tokens = profiles.map((profile) => escapeRegex(profile.token));
 		if (!tokens.length) {
 			return [{ type: 'html', value: html }, ...segments];
@@ -190,23 +254,8 @@
 		];
 	}
 
-	let articleSegments = $state<ArticleSegment[]>([]);
-	const articleEventSegments = $derived.by(() =>
-		parseEmbeddedEvents($storedArticle?.content ?? '')
-	);
-
-	$effect(() => {
-		const content = $storedArticle?.content ?? '';
-		let cancelled = false;
-
-		parseArticleContent(content).then((segments) => {
-			if (!cancelled) articleSegments = segments;
-		});
-
-		return () => {
-			cancelled = true;
-		};
-	});
+	const articleSegments = $derived(parseArticleContent(articleEvent?.content ?? ''));
+	const articleEventSegments = $derived.by(() => parseEmbeddedEvents(articleEvent?.content ?? ''));
 
 	$effect(() => {
 		if (!articleEventSegments.length) return;
@@ -226,26 +275,38 @@
 		};
 	});
 
-	async function renderMarkdown(content: string): Promise<string> {
-		const html = await marked.parse(content);
+	function renderMarkdown(content: string): string {
+		const html = marked.parse(content, {
+			async: false,
+			breaks: true,
+			gfm: true,
+			renderer: markdownRenderer
+		});
 		return browser ? DOMPurify.sanitize(html) : html;
 	}
 </script>
 
-{#if $storedArticle}
-	<SEO title={seoTitle} description={seoDescription} image={seoImage} url={seoUrl} type={seoType} />
-	{@const image = getArticleImage($storedArticle)}
-	{@const title = getArticleTitle($storedArticle)}
-	{@const publishedAt = formatUnixTimestamp($storedArticle.created_at, true)}
+{#if articleEvent}
+	<SEO
+		title={seoTitle}
+		description={seoDescription}
+		image={seoImage}
+		type="article"
+		canonicalPath={`/blog/${page.params.id ?? ''}`}
+		structuredData={articleStructuredData}
+	/>
+	{@const image = getArticleImage(articleEvent)}
+	{@const title = getArticleTitle(articleEvent)}
+	{@const publishedAt = formatUnixTimestamp(getArticlePublished(articleEvent), true)}
 
 	<article class="container mx-auto max-w-4xl px-4 py-6 sm:py-8 md:py-12">
-		<!-- Back to blog link -->
-		<button
-			onclick={() => goto(resolve(blogHref))}
-			class="mb-4 flex items-center text-sm font-medium text-muted-foreground hover:text-primary sm:mb-6"
-		>
-			← Back to blog
-		</button>
+		<nav aria-label="Breadcrumb" class="mb-4 text-sm text-muted-foreground sm:mb-6">
+			<ol class="flex flex-wrap items-center gap-2">
+				<li><a href={resolve(blogHref)} class="font-medium hover:text-primary">Blog</a></li>
+				<li aria-hidden="true">/</li>
+				<li aria-current="page" class="truncate">{seoTitle}</li>
+			</ol>
+		</nav>
 
 		<!-- Article header -->
 		<header class="mb-6 sm:mb-8">
@@ -262,7 +323,7 @@
 			</h1>
 
 			<div class="flex items-center text-sm text-muted-foreground">
-				<time datetime={new Date($storedArticle.created_at * 1000).toISOString()}>
+				<time datetime={new Date(getArticlePublished(articleEvent) * 1000).toISOString()}>
 					{publishedAt}
 				</time>
 			</div>
@@ -298,7 +359,7 @@
 			{/each}
 		</div>
 	</article>
-{:else if loading}
+{:else if relayLoading}
 	<div class="container mx-auto px-4 py-16 text-center">
 		<div class="aspect-video overflow-hidden bg-muted">
 			<div class="h-full w-full animate-pulse bg-muted-foreground/20"></div>
@@ -327,11 +388,11 @@
 		<p class="mb-6 text-muted-foreground">
 			The article you're looking for doesn't exist or couldn't be loaded.
 		</p>
-		<button
-			onclick={() => goto(resolve(blogHref))}
+		<a
+			href={resolve(blogHref)}
 			class="inline-flex items-center justify-center rounded-md bg-primary px-4 py-2 text-sm font-medium text-primary-foreground transition-colors hover:bg-primary/90"
 		>
 			Back to blog
-		</button>
+		</a>
 	</div>
 {/if}
diff --git a/src/routes/blog/[id]/+page.ts b/src/routes/blog/[id]/+page.ts
index d43d0cd..3b07a67 100644
--- a/src/routes/blog/[id]/+page.ts
+++ b/src/routes/blog/[id]/+page.ts
@@ -1 +1,15 @@
-export const prerender = false;
+import { getArticleIdentifier, getSnapshotArticle, seoSnapshot } from '$lib/content/seo-snapshot';
+import type { EntryGenerator, PageLoad } from './$types';
+
+export const prerender = true;
+
+export const entries: EntryGenerator = () =>
+	seoSnapshot.articles.flatMap((article) => {
+		const id = getArticleIdentifier(article);
+		return id ? [{ id }] : [];
+	});
+
+export const load = (({ params }) => ({
+	article: getSnapshotArticle(params.id),
+	generatedAt: seoSnapshot.generatedAt
+})) satisfies PageLoad;
diff --git a/src/routes/chat/+page.svelte b/src/routes/chat/+page.svelte
index a5f7677..382bd95 100644
--- a/src/routes/chat/+page.svelte
+++ b/src/routes/chat/+page.svelte
@@ -56,7 +56,7 @@
 <SEO
 	title="Chat"
 	description="Try ContextVM with an LLM chat. Zero config with free models or bring your own API key."
-	url="https://contextvm.com/chat"
+	robots="noindex, nofollow"
 />
 
 <Sidebar.Provider class="h-[calc(100dvh-3.5rem)] min-h-0 overflow-hidden">
diff --git a/src/routes/faqs/+page.svelte b/src/routes/faqs/+page.svelte
index 3f4d57d..80bfee9 100644
--- a/src/routes/faqs/+page.svelte
+++ b/src/routes/faqs/+page.svelte
@@ -1,16 +1,7 @@
 <script lang="ts">
-	import * as Collapsible from '$lib/components/ui/collapsible/index.js';
 	import ChevronDownIcon from '@lucide/svelte/icons/chevron-down';
-	import DOMPurify from 'dompurify';
-	import { browser } from '$app/environment';
 	import SEO from '$lib/components/SEO.svelte';
 	import { faqCategories } from './faq-data';
-
-	let openCategoryIndex = $state<number | null>(null);
-
-	function toggleCategory(index: number) {
-		openCategoryIndex = openCategoryIndex === index ? null : index;
-	}
 </script>
 
 <SEO
@@ -19,7 +10,6 @@
 />
 
 <article class="container mx-auto max-w-4xl px-4 py-6 sm:py-8 md:py-12">
-	<!-- FAQ header -->
 	<header class="mb-6 sm:mb-8">
 		<h1
 			class="mb-3 text-2xl leading-tight font-bold tracking-tight sm:mb-4 sm:text-3xl md:text-4xl"
@@ -28,72 +18,44 @@
 		</h1>
 	</header>
 
-	<!-- FAQ categories -->
 	<div class="flex flex-col gap-4">
-		{#each faqCategories as category, categoryIndex (category.title)}
-			<!-- Category accordion -->
-			<div class="faq-category overflow-hidden rounded-lg">
-				{#if openCategoryIndex === categoryIndex}
-					<!-- Expanded state -->
-					<div class="rounded-lg bg-card">
-						<!-- Category header (expanded) -->
-						<button
-							class="flex w-full cursor-pointer items-center justify-between rounded-lg bg-accent px-4 py-3.5 text-left transition-colors"
-							onclick={() => toggleCategory(categoryIndex)}
-						>
-							<h2 class="text-base font-semibold text-foreground sm:text-lg">
-								{category.title}
-							</h2>
-							<ChevronDownIcon
-								class="h-5 w-5 shrink-0 rotate-180 text-foreground transition-transform duration-200"
-							/>
-						</button>
+		{#each faqCategories as category (category.title)}
+			<details class="group overflow-hidden rounded-lg border border-border bg-card">
+				<summary
+					class="flex cursor-pointer list-none items-center justify-between rounded-lg px-4 py-3.5 text-left transition-colors hover:bg-accent focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 focus-visible:outline-none"
+				>
+					<h2 class="text-base font-semibold text-foreground sm:text-lg">{category.title}</h2>
+					<ChevronDownIcon
+						aria-hidden="true"
+						class="h-5 w-5 shrink-0 text-foreground transition-transform duration-200 group-open:rotate-180"
+					/>
+				</summary>
 
-						<!-- Questions list -->
-						<div class="flex flex-col gap-1 px-2 py-3">
-							{#each category.faqs as faq (faq.question)}
-								<Collapsible.Root>
-									<Collapsible.Trigger
-										class="flex w-full items-center justify-between rounded-md px-3 py-3 text-left transition-colors hover:bg-accent/50 focus:ring-2 focus:ring-ring focus:ring-offset-2 focus:outline-none"
-									>
-										<h3 class="pr-4 text-sm font-semibold text-foreground sm:text-base">
-											{faq.question}
-										</h3>
-										<ChevronDownIcon
-											class="h-5 w-5 shrink-0 text-muted-foreground transition-transform duration-200 [[data-state=open]>&]:rotate-180"
-										/>
-									</Collapsible.Trigger>
-									<Collapsible.Content
-										class="data-[state=closed]:animate-out data-[state=closed]:fade-out-0 data-[state=open]:animate-in data-[state=open]:fade-in-0 overflow-hidden"
-									>
-										<div
-											class="prose prose-sm dark:prose-invert sm:prose-base mx-1 mt-1 mb-2 max-w-none overflow-x-auto rounded-md border-l-2 border-primary/40 bg-muted/30 py-4 pr-4 pl-4 sm:py-5 sm:pr-6 sm:pl-5"
-										>
-											{#if browser}
-												<!-- eslint-disable-next-line svelte/no-at-html-tags -->
-												{@html DOMPurify.sanitize(faq.answer)}
-											{/if}
-										</div>
-									</Collapsible.Content>
-								</Collapsible.Root>
-							{/each}
-						</div>
-					</div>
-				{:else}
-					<!-- Collapsed state -->
-					<button
-						class="flex w-full cursor-pointer items-center justify-between rounded-lg border border-border bg-card px-4 py-3.5 text-left transition-colors hover:bg-accent"
-						onclick={() => toggleCategory(categoryIndex)}
-					>
-						<h2 class="text-base font-semibold text-foreground/60 sm:text-lg">
-							{category.title}
-						</h2>
-						<ChevronDownIcon
-							class="h-5 w-5 shrink-0 text-foreground/60 transition-transform duration-200"
-						/>
-					</button>
-				{/if}
-			</div>
+				<div class="flex flex-col gap-1 px-2 py-3">
+					{#each category.faqs as faq (faq.question)}
+						<details class="group/question">
+							<summary
+								class="flex cursor-pointer list-none items-center justify-between rounded-md px-3 py-3 text-left transition-colors hover:bg-accent/50 focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 focus-visible:outline-none"
+							>
+								<h3 class="pr-4 text-sm font-semibold text-foreground sm:text-base">
+									{faq.question}
+								</h3>
+								<ChevronDownIcon
+									aria-hidden="true"
+									class="h-5 w-5 shrink-0 text-muted-foreground transition-transform duration-200 group-open/question:rotate-180"
+								/>
+							</summary>
+							<div
+								class="prose prose-sm dark:prose-invert sm:prose-base mx-1 mt-1 mb-2 max-w-none overflow-x-auto rounded-md border-l-2 border-primary/40 bg-muted/30 py-4 pr-4 pl-4 sm:py-5 sm:pr-6 sm:pl-5"
+							>
+								<!-- FAQ answers are source-controlled static HTML. -->
+								<!-- eslint-disable-next-line svelte/no-at-html-tags -->
+								{@html faq.answer}
+							</div>
+						</details>
+					{/each}
+				</div>
+			</details>
 		{/each}
 	</div>
 </article>
diff --git a/src/routes/robots.txt/+server.ts b/src/routes/robots.txt/+server.ts
new file mode 100644
index 0000000..9fade73
--- /dev/null
+++ b/src/routes/robots.txt/+server.ts
@@ -0,0 +1,9 @@
+import { SITE_ORIGIN } from '$lib/seo';
+
+export const prerender = true;
+
+export function GET() {
+	return new Response(`User-agent: *\nAllow: /\n\nSitemap: ${SITE_ORIGIN}/sitemap.xml\n`, {
+		headers: { 'Content-Type': 'text/plain; charset=utf-8' }
+	});
+}
diff --git a/src/routes/s/[pubkey]/+page.svelte b/src/routes/s/[pubkey]/+page.svelte
index e2d2bcc..7a9f77a 100644
--- a/src/routes/s/[pubkey]/+page.svelte
+++ b/src/routes/s/[pubkey]/+page.svelte
@@ -7,6 +7,8 @@
 		getAvailableCapabilities,
 		pubkeyToHexColor,
 		copyToClipboard,
+		decodeServerIdentifier,
+		encodeServerIdentity,
 		resolveServerIdentifier
 	} from '$lib/utils';
 	import { goto } from '$app/navigation';
@@ -54,11 +56,48 @@
 	import { createServerNotesFilter } from '$lib/constants';
 	import { npubEncode } from 'nostr-tools/nip19';
 	import { parseCapTagsFromEvent, parseCapTagsFromTags } from '$lib/services/payments/cep8-tags';
+	import type { PageData } from './$types';
+
+	let { data }: { data: PageData } = $props();
 
 	const requestedIdentifier = page.params.pubkey ?? '';
+	const snapshotAnnouncement = $derived(
+		data.server ? parseServerInitializeMsg(data.server.event) : null
+	);
+	const snapshotIdentifier = $derived.by(() => {
+		if (!data.server) return undefined;
+
+		const decoded = decodeServerIdentifier(requestedIdentifier);
+		if (decoded?.pubkey === data.server.event.pubkey) {
+			return {
+				...decoded,
+				relayHints: decoded.relayHints.length ? decoded.relayHints : data.server.relays
+			};
+		}
+
+		return {
+			original: requestedIdentifier,
+			pubkey: data.server.event.pubkey,
+			relayHints: data.server.relays,
+			format: 'hex' as const
+		};
+	});
+	const snapshotIdentity = $derived.by(() => {
+		if (!snapshotAnnouncement || !data.server) return undefined;
+
+		const relayHints = snapshotIdentifier?.relayHints ?? data.server.relays;
+		const relaySource: 'nprofile' | 'announcement' =
+			snapshotIdentifier?.format === 'nprofile' ? 'nprofile' : 'announcement';
+		return {
+			...encodeServerIdentity(snapshotAnnouncement.pubkey, relayHints),
+			relaySource
+		};
+	});
+
 	const resolvedIdentifierQuery = createQuery({
 		queryKey: ['server-identifier', requestedIdentifier, page.url.hostname],
-		queryFn: () => resolveServerIdentifier(requestedIdentifier, page.url.hostname)
+		queryFn: () => resolveServerIdentifier(requestedIdentifier, page.url.hostname),
+		initialData: () => snapshotIdentifier
 	});
 	const resolvedIdentifier = $derived($resolvedIdentifierQuery.data ?? null);
 	const pubkey = $derived(resolvedIdentifier?.pubkey ?? requestedIdentifier);
@@ -73,18 +112,19 @@
 	const homeHref = $derived<`/`>('/');
 	const logoBlackSrc = asset('/logo-black.svg');
 
-	// Dynamic SEO data for server pages
-	let seoTitle = $state('Loading server...');
-	let seoDescription = $state('Loading server information...');
-	let seoImage = $state(logoBlackSrc);
-	let seoUrl = $state(`https://contextvm.com/s/${requestedIdentifier}`);
-	let seoType = $state('website' as 'website' | 'article');
-
 	const serverQuery = $derived(
-		resolvedIdentifier ? useServerAnnouncement(pubkey, bootstrapRelayHints) : undefined
+		resolvedIdentifier
+			? useServerAnnouncement(
+					pubkey,
+					bootstrapRelayHints,
+					snapshotAnnouncement ? { server: snapshotAnnouncement, isPublic: true } : undefined
+				)
+			: undefined
 	);
 	const serverIdentityQuery = $derived(
-		resolvedIdentifier ? useServerIdentity(pubkey, bootstrapRelayHints) : undefined
+		resolvedIdentifier
+			? useServerIdentity(pubkey, bootstrapRelayHints, snapshotIdentity)
+			: undefined
 	);
 	const effectiveRelayHints = $derived(
 		$serverIdentityQuery?.data?.relayHints?.length
@@ -111,22 +151,23 @@
 
 	const hasNotes = $derived($notes.length > 0);
 
-	// Update SEO data when server loads
-	$effect(() => {
-		if ($serverQuery?.data?.server) {
-			const server = $serverQuery.data.server;
-			const serverName = server.name || 'Unnamed Server';
-			const serverAbout = server.about || 'No description available for this server.';
-			const serverPicture = server.picture || logoBlackSrc;
-
-			seoTitle = serverName;
-			seoDescription =
-				serverAbout.length > 160 ? serverAbout.substring(0, 160) + '...' : serverAbout;
-			seoImage = serverPicture;
-			seoUrl = `https://contextvm.com/s/${requestedIdentifier}`;
-			seoType = 'website';
-		}
+	const displayedServer = $derived($serverQuery?.data?.server ?? snapshotAnnouncement);
+	const seoTitle = $derived(displayedServer?.name || 'Server');
+	const seoDescription = $derived.by(() => {
+		const about = displayedServer?.about || 'Public ContextVM server on Nostr.';
+		return about.length > 160 ? about.substring(0, 157) + '...' : about;
 	});
+	const seoImage = $derived(displayedServer?.picture || logoBlackSrc);
+	const canonicalPath = $derived('/s/' + (displayedServer?.pubkey ?? pubkey));
+	const liveStatus = $derived(
+		$serverQuery?.isError
+			? 'unavailable'
+			: $serverQuery?.isFetching
+				? 'connecting'
+				: ($serverQuery?.dataUpdatedAt ?? 0) > 0
+					? 'available'
+					: 'not checked'
+	);
 
 	// Only load queries for capabilities that are actually available
 	let toolsQuery = $derived(
@@ -275,7 +316,7 @@
 	}
 </script>
 
-<Seo title={seoTitle} description={seoDescription} image={seoImage} url={seoUrl} type={seoType} />
+<Seo title={seoTitle} description={seoDescription} image={seoImage} {canonicalPath} />
 
 {#if $resolvedIdentifierQuery.isLoading}
 	<div class="container mx-auto flex min-h-[50vh] max-w-6xl items-center justify-center px-4 py-12">
@@ -296,13 +337,13 @@
 	</div>
 {:else if $serverQuery?.data?.server}
 	<article class="container mx-auto max-w-6xl px-4 py-6 sm:py-8 md:py-12">
-		<!-- Back to servers link -->
-		<button
-			onclick={() => goto(resolve(serversHref))}
-			class="mb-4 flex items-center text-sm font-medium text-muted-foreground hover:text-primary sm:mb-6"
-		>
-			← Back to servers
-		</button>
+		<nav aria-label="Breadcrumb" class="mb-4 text-sm text-muted-foreground sm:mb-6">
+			<ol class="flex flex-wrap items-center gap-2">
+				<li><a href={resolve(serversHref)} class="font-medium hover:text-primary">Servers</a></li>
+				<li aria-hidden="true">/</li>
+				<li aria-current="page" class="truncate">{seoTitle}</li>
+			</ol>
+		</nav>
 
 		<!-- Server header with picture -->
 		{#if $serverQuery.data.server.picture}
@@ -327,9 +368,9 @@
 				<!-- Server name and website -->
 				<div class="mb-6 flex flex-col gap-6">
 					<div>
-						<h2 class="mb-1 text-2xl leading-none font-bold sm:text-3xl md:text-4xl">
+						<h1 class="mb-1 text-2xl leading-none font-bold sm:text-3xl md:text-4xl">
 							{$serverQuery.data.server.name}
-						</h2>
+						</h1>
 						{#if $serverQuery.data.server.website}
 							<!-- External URL — resolve() not applicable -->
 							<!-- eslint-disable-next-line svelte/no-navigation-without-resolve -->
@@ -342,6 +383,15 @@
 								{$serverQuery.data.server.website}
 							</a>
 						{/if}
+						<p class="mt-3 text-xs text-muted-foreground">
+							Snapshot refreshed
+							<time datetime={data.generatedAt}
+								>{new Date(data.generatedAt).toLocaleDateString('en', {
+									dateStyle: 'medium',
+									timeZone: 'UTC'
+								})}</time
+							>. Live relay lookup is {liveStatus}.
+						</p>
 					</div>
 					<div class="w-full space-y-3">
 						{#if hasPaidCapabilities}
diff --git a/src/routes/s/[pubkey]/+page.ts b/src/routes/s/[pubkey]/+page.ts
index d43d0cd..6761c59 100644
--- a/src/routes/s/[pubkey]/+page.ts
+++ b/src/routes/s/[pubkey]/+page.ts
@@ -1 +1,29 @@
-export const prerender = false;
+import { building } from '$app/environment';
+import { error } from '@sveltejs/kit';
+import { getSnapshotServer, seoSnapshot } from '$lib/content/seo-snapshot';
+import { nprofileEncode, npubEncode } from 'nostr-tools/nip19';
+import type { EntryGenerator, PageLoad } from './$types';
+
+export const prerender = true;
+
+export const entries: EntryGenerator = () =>
+	seoSnapshot.servers.flatMap((server) => [
+		{ pubkey: server.event.pubkey },
+		{ pubkey: npubEncode(server.event.pubkey) },
+		{
+			pubkey: nprofileEncode({
+				pubkey: server.event.pubkey,
+				relays: server.relays
+			})
+		}
+	]);
+
+export const load = (({ params }) => {
+	const server = getSnapshotServer(params.pubkey);
+	if (building && !server) error(404, 'Server is not in the prerender snapshot');
+
+	return {
+		server,
+		generatedAt: seoSnapshot.generatedAt
+	};
+}) satisfies PageLoad;
diff --git a/src/routes/servers/+page.svelte b/src/routes/servers/+page.svelte
index 4374112..ff91819 100644
--- a/src/routes/servers/+page.svelte
+++ b/src/routes/servers/+page.svelte
@@ -1,4 +1,5 @@
 <script lang="ts">
+	import { resolve } from '$app/paths';
 	import { page } from '$app/state';
 	import { createQuery } from '@tanstack/svelte-query';
 	import ServerCard from '$lib/components/ServerCard.svelte';
@@ -10,7 +11,11 @@
 	} from '$lib/queries/serverQueries';
 	import { serverKeys } from '$lib/queries/serverQueryKeys';
 	import { eventStore } from '$lib/services/eventStore';
-	import { ServerAnnouncementsModel } from '$lib/models/serverAnnouncements';
+	import {
+		parseServerInitializeMsg,
+		ServerAnnouncementsModel,
+		type ServerAnnouncement
+	} from '$lib/models/serverAnnouncements';
 	import { CatalogSchemasModel } from '$lib/models/catalogSchemas';
 	import { createCommonSchemaAnnouncementsLoader } from '$lib/services/loaders.svelte';
 	import Seo from '$lib/components/SEO.svelte';
@@ -18,7 +23,16 @@
 	import { Button } from '$lib/components/ui/button';
 	import CatalogBrowseSection from '$lib/components/CatalogBrowseSection.svelte';
 	import { decodeServerIdentifier, resolveServerIdentifier } from '$lib/utils';
+	import type { PageData } from './$types';
+
+	let { data }: { data: PageData } = $props();
 
+	const snapshotAnnouncements = $derived(
+		data.servers.flatMap((snapshot) => {
+			const server = parseServerInitializeMsg(snapshot.event);
+			return server ? [server] : [];
+		})
+	);
 	const serverAnnouncements = eventStore.model(ServerAnnouncementsModel);
 	const allSchemas = eventStore.model(CatalogSchemasModel);
 
@@ -43,7 +57,24 @@
 		return () => sub.unsubscribe();
 	});
 
-	let loading = $state($serverAnnouncementsQuery.isFetching);
+	const loading = $derived($serverAnnouncementsQuery.isFetching);
+	const liveStatus = $derived(
+		$serverAnnouncementsQuery.isError
+			? 'unavailable'
+			: $serverAnnouncementsQuery.data
+				? 'available'
+				: 'connecting'
+	);
+	const allServerAnnouncements = $derived.by(() => {
+		const byPubkey = new Map<string, ServerAnnouncement>();
+
+		for (const server of [...snapshotAnnouncements, ...$serverAnnouncements]) {
+			const current = byPubkey.get(server.pubkey);
+			if (!current || server.created_at > current.created_at) byPubkey.set(server.pubkey, server);
+		}
+
+		return [...byPubkey.values()].sort((a, b) => b.created_at - a.created_at);
+	});
 	let searchTerm = $state('');
 	const resolvedSearchIdentifierQuery = $derived.by(() => {
 		const trimmedSearchTerm = searchTerm.trim();
@@ -57,11 +88,11 @@
 
 	const filteredServerAnnouncements = $derived.by(() => {
 		if (!searchTerm.trim()) {
-			return $serverAnnouncements;
+			return allServerAnnouncements;
 		}
 
 		const term = searchTerm.trim();
-		return $serverAnnouncements?.filter((s) => matchesServerSearch(s, term)) ?? [];
+		return allServerAnnouncements.filter((server) => matchesServerSearch(server, term));
 	});
 
 	const decodedSearchIdentifier = $derived(
@@ -74,7 +105,7 @@
 	);
 	const serverLookupHref = $derived.by(() => {
 		const identifier = decodedSearchIdentifier;
-		return identifier ? `/s/${identifier.original}` : null;
+		return identifier ? resolve(`/s/${identifier.original}`) : null;
 	});
 </script>
 
@@ -91,6 +122,15 @@
 				Discover and connect with Model Context Protocol servers running on the Nostr network. No
 				domains, no OAuth, no port forwarding—just cryptographic keys and relays.
 			</p>
+			<p class="mt-4 text-sm text-muted-foreground">
+				Snapshot refreshed
+				<time datetime={data.generatedAt}
+					>{new Date(data.generatedAt).toLocaleDateString('en', {
+						dateStyle: 'medium',
+						timeZone: 'UTC'
+					})}</time
+				>. Live relay updates are {liveStatus}.
+			</p>
 		</div>
 
 		<!-- Discovery Strip: Categories & Schemas -->
@@ -175,7 +215,7 @@
 						{/each}
 					</div>
 				{/if}
-			{:else if !$serverAnnouncements?.length && !loading}
+			{:else if !allServerAnnouncements.length && !loading}
 				<div class="mt-12 text-center text-muted-foreground">
 					<p>No MCP servers found. Check back later for server announcements.</p>
 				</div>
diff --git a/src/routes/servers/+page.ts b/src/routes/servers/+page.ts
new file mode 100644
index 0000000..9eaa40a
--- /dev/null
+++ b/src/routes/servers/+page.ts
@@ -0,0 +1,7 @@
+import { seoSnapshot } from '$lib/content/seo-snapshot';
+import type { PageLoad } from './$types';
+
+export const load = (() => ({
+	servers: seoSnapshot.servers,
+	generatedAt: seoSnapshot.generatedAt
+})) satisfies PageLoad;
diff --git a/src/routes/servers/i/[hash]/+page.svelte b/src/routes/servers/i/[hash]/+page.svelte
index c28ddb5..57d9cb6 100644
--- a/src/routes/servers/i/[hash]/+page.svelte
+++ b/src/routes/servers/i/[hash]/+page.svelte
@@ -69,8 +69,9 @@
 </script>
 
 <Seo
-	title="{currentSchema?.name || 'Schema'} | ContextVM"
+	title={currentSchema?.name || 'Schema'}
 	description="MCP servers implementing the {currentSchema?.name || hash} common tool schema."
+	robots="noindex, follow"
 />
 
 <main class="min-h-screen bg-background px-4 py-8">
diff --git a/src/routes/servers/t/[cat]/+page.svelte b/src/routes/servers/t/[cat]/+page.svelte
index 58fa69c..1a075cd 100644
--- a/src/routes/servers/t/[cat]/+page.svelte
+++ b/src/routes/servers/t/[cat]/+page.svelte
@@ -69,8 +69,9 @@
 </script>
 
 <Seo
-	title="#{cat} Servers | ContextVM"
+	title="#{cat} Servers"
 	description="MCP servers in the {cat} category on the Nostr network."
+	robots="noindex, follow"
 />
 
 <main class="min-h-screen bg-background px-4 py-8">
diff --git a/src/routes/sitemap.xml/+server.ts b/src/routes/sitemap.xml/+server.ts
new file mode 100644
index 0000000..ad62aac
--- /dev/null
+++ b/src/routes/sitemap.xml/+server.ts
@@ -0,0 +1,26 @@
+import { canonicalUrl } from '$lib/seo';
+import { getArticleIdentifier, seoSnapshot } from '$lib/content/seo-snapshot';
+
+export const prerender = true;
+
+const publicPages = ['/', '/about', '/blog', '/faqs', '/servers', '/slides'];
+
+export function GET() {
+	const articlePages = seoSnapshot.articles.flatMap((article) => {
+		const identifier = getArticleIdentifier(article);
+		return identifier ? [`/blog/${encodeURIComponent(identifier)}`] : [];
+	});
+	const serverPages = seoSnapshot.servers.map((server) => `/s/${server.event.pubkey}`);
+	const urls = [...publicPages, ...articlePages, ...serverPages]
+		.map((path) => `  <url><loc>${canonicalUrl(path)}</loc></url>`)
+		.join('\n');
+	const sitemap = `<?xml version="1.0" encoding="UTF-8"?>
+<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
+${urls}
+</urlset>
+`;
+
+	return new Response(sitemap, {
+		headers: { 'Content-Type': 'application/xml; charset=utf-8' }
+	});
+}
diff --git a/src/routes/slides/+page.svelte b/src/routes/slides/+page.svelte
index 9e9b44a..e40989e 100644
--- a/src/routes/slides/+page.svelte
+++ b/src/routes/slides/+page.svelte
@@ -1,6 +1,6 @@
 <script lang="ts">
 	import Seo from '$lib/components/SEO.svelte';
-	import { resolve } from '$app/paths';
+	import { asset, resolve } from '$app/paths';
 
 	type SlideDeck = {
 		title: string;
@@ -19,7 +19,7 @@
 			title: 'ContextVM — Permissionless Infrastructure for MCP',
 			description:
 				'A technical overview of ContextVM as the transport layer that makes MCP sovereign, relay-routed, and public-key addressed.',
-			href: '/slides/contextvm-deck/index.html',
+			href: asset('/slides/contextvm-deck/index.html'),
 			status: 'Available now',
 			category: 'Protocol overview'
 		}
diff --git a/svelte.config.js b/svelte.config.js
index afd35b6..2528222 100644
--- a/svelte.config.js
+++ b/svelte.config.js
@@ -12,17 +12,28 @@ const config = {
 
 	kit: {
 		adapter: adapter({
-			fallback: 'index.html'
+			fallback: '404.html'
 		}),
 		paths: {
-			base: isGitHubPages ? githubPagesBasePath : ''
+			base: isGitHubPages ? githubPagesBasePath : '',
+			relative: false
 		},
 		alias: {
 			'@/*': './path/to/lib/*'
 		},
 		prerender: {
 			crawl: true,
-			handleHttpError: 'ignore'
+			origin: isGitHubPages ? 'https://contextvm.github.io' : 'https://contextvm.org',
+			handleHttpError: ({ status, path, referrer, message }) => {
+				const isLiveServerLink =
+					status === 404 && path.startsWith('/s/') && referrer?.startsWith('/blog/');
+				const isDocsMirrorLink =
+					isGitHubPages &&
+					status === 404 &&
+					path.startsWith('/contextvm-docs/') &&
+					referrer?.startsWith(`${githubPagesBasePath}/blog/`);
+				if (!isLiveServerLink && !isDocsMirrorLink) throw new Error(message);
+			}
 		}
 	}
 };
diff --git a/vercel.json b/vercel.json
index 29cec4f..d964905 100644
--- a/vercel.json
+++ b/vercel.json
@@ -1,3 +1,3 @@
 {
-	"rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
+	"cleanUrls": true
 }