mirror of
https://github.com/aljazceru/contextvm-docs.git
synced 2025-12-18 22:44:25 +01:00
init
This commit is contained in:
gzuuus
@@ -30,7 +30,7 @@ Inside of your Astro + Starlight project, you'll see the following folders and f
|
||||
└── tsconfig.json
|
||||
```
|
||||
|
||||
Starlight looks for `.md` or `.mdx` files in the `src/content/docs/` directory. Each file is exposed as a route based on its file name.
|
||||
Starlight looks for `` or `.mdx` files in the `src/content/docs/` directory. Each file is exposed as a route based on its file name.
|
||||
|
||||
Images can be added to `src/assets/` and embedded in Markdown with a relative link.
|
||||
|
||||
|
||||
@@ -16,60 +16,52 @@ export default defineConfig({
|
||||
replacesTitle: false,
|
||||
},
|
||||
social: [
|
||||
{ icon: 'github', label: 'ContextVM', href: 'https://github.com/contextvm/sdk' },
|
||||
{ icon: 'twitter', label: 'Twitter', href: 'https://twitter.com/contextvm' },
|
||||
{ icon: 'github', label: 'ContextVM', href: 'https://github.com/contextvm/ts-sdk' },
|
||||
],
|
||||
editLink: {
|
||||
baseUrl: 'https://github.com/contextvm/sdk/edit/main/docs/',
|
||||
},
|
||||
sidebar: [
|
||||
{
|
||||
label: 'Getting Started',
|
||||
items: [
|
||||
{ label: 'Quick Overview', slug: 'guides/getting-started/quick-overview' },
|
||||
{ label: 'Quick Overview', slug: 'getting-started/quick-overview' },
|
||||
],
|
||||
},
|
||||
{
|
||||
label: 'Specification',
|
||||
items: [
|
||||
{ label: 'Specification', slug: 'guides/ctxvm-draft-spec' },
|
||||
{ label: 'Specification', slug: 'ctxvm-draft-spec' },
|
||||
],
|
||||
},
|
||||
{
|
||||
label: 'Core Concepts',
|
||||
items: [
|
||||
{ label: 'Constants', slug: 'guides/core/constants' },
|
||||
{ label: 'Interfaces', slug: 'guides/core/interfaces' },
|
||||
{ label: 'Encryption', slug: 'guides/core/encryption' },
|
||||
{ label: 'Constants', slug: 'core/constants' },
|
||||
{ label: 'Interfaces', slug: 'core/interfaces' },
|
||||
{ label: 'Encryption', slug: 'core/encryption' },
|
||||
],
|
||||
},
|
||||
{
|
||||
label: 'Components',
|
||||
items: [
|
||||
{ label: 'Gateway', slug: 'guides/gateway/overview' },
|
||||
{ label: 'Relay', slug: 'guides/relay/simple-relay-pool' },
|
||||
{ label: 'Signer', slug: 'guides/signer/private-key-signer' },
|
||||
{ label: 'Proxy', slug: 'guides/proxy/overview' },
|
||||
{ label: 'Gateway', slug: 'gateway/overview' },
|
||||
{ label: 'Relay', slug: 'relay/simple-relay-pool' },
|
||||
{ label: 'Signer', slug: 'signer/private-key-signer' },
|
||||
{ label: 'Proxy', slug: 'proxy/overview' },
|
||||
],
|
||||
},
|
||||
{
|
||||
label: 'Tutorials',
|
||||
items: [
|
||||
{ label: 'Client-Server Communication', slug: 'guides/tutorials/client-server-communication' },
|
||||
{ label: 'Client-Server Communication', slug: 'tutorials/client-server-communication' },
|
||||
],
|
||||
},
|
||||
{
|
||||
label: 'Transports',
|
||||
items: [
|
||||
{ label: 'Base Nostr Transport', slug: 'guides/transports/base-nostr-transport' },
|
||||
{ label: 'Nostr Client', slug: 'guides/transports/nostr-client-transport' },
|
||||
{ label: 'Nostr Server', slug: 'guides/transports/nostr-server-transport' },
|
||||
{ label: 'Base Nostr Transport', slug: 'transports/base-nostr-transport' },
|
||||
{ label: 'Nostr Client', slug: 'transports/nostr-client-transport' },
|
||||
{ label: 'Nostr Server', slug: 'transports/nostr-server-transport' },
|
||||
],
|
||||
},
|
||||
{
|
||||
label: 'Reference',
|
||||
autogenerate: { directory: 'reference' },
|
||||
},
|
||||
],
|
||||
}),
|
||||
],
|
||||
|
||||
@@ -118,7 +118,7 @@ This works particularly well for landing pages and you can see it in action on t
|
||||
|
||||
```md {5}
|
||||
---
|
||||
# src/content/docs/index.md
|
||||
# src/content/docs/index
|
||||
|
||||
title: My Landing Page
|
||||
template: splash
|
||||
@@ -137,7 +137,7 @@ By default, `<h2>` and `<h3>` headings are included in the table of contents. Ch
|
||||
|
||||
```md {4-6}
|
||||
---
|
||||
# src/content/docs/example.md
|
||||
# src/content/docs/example
|
||||
title: Page with only H2s in the table of contents
|
||||
tableOfContents:
|
||||
minHeadingLevel: 2
|
||||
@@ -171,7 +171,7 @@ Disable the table of contents entirely by setting the `tableOfContents` option t
|
||||
|
||||
```md {4}
|
||||
---
|
||||
# src/content/docs/example.md
|
||||
# src/content/docs/example
|
||||
title: Page without a table of contents
|
||||
tableOfContents: false
|
||||
---
|
||||
@@ -268,15 +268,15 @@ export default defineConfig({
|
||||
## Custom 404 page
|
||||
|
||||
Starlight sites display a simple 404 page by default.
|
||||
You can customize this by adding a `404.md` (or `404.mdx`) file to your `src/content/docs/` directory:
|
||||
You can customize this by adding a `404` (or `404.mdx`) file to your `src/content/docs/` directory:
|
||||
|
||||
<FileTree>
|
||||
|
||||
- src/
|
||||
- content/
|
||||
- docs/
|
||||
- **404.md**
|
||||
- index.md
|
||||
- **404**
|
||||
- index
|
||||
- astro.config.mjs
|
||||
|
||||
</FileTree>
|
||||
@@ -285,7 +285,7 @@ You can use all of Starlight’s page layout and customization techniques in you
|
||||
|
||||
```md {4,6-8}
|
||||
---
|
||||
# src/content/docs/404.md
|
||||
# src/content/docs/404
|
||||
title: '404'
|
||||
template: splash
|
||||
editUrl: false
|
||||
|
||||
@@ -127,7 +127,7 @@ yarn dlx @astrojs/upgrade
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
See the [Starlight changelog](https://github.com/withastro/starlight/blob/main/packages/starlight/CHANGELOG.md) for a full list of the changes made in each release.
|
||||
See the [Starlight changelog](https://github.com/withastro/starlight/blob/main/packages/starlight/CHANGELOG) for a full list of the changes made in each release.
|
||||
|
||||
## Troubleshooting Starlight
|
||||
|
||||
|
||||
@@ -84,12 +84,12 @@ This is useful if you have an existing Astro project and are unable to make any
|
||||
|
||||
Starlight is now configured and it’s time to add some content!
|
||||
|
||||
Create a `src/content/docs/` directory and start by adding an `index.md` file.
|
||||
Create a `src/content/docs/` directory and start by adding an `index` file.
|
||||
This will be the homepage of your new site:
|
||||
|
||||
```md
|
||||
---
|
||||
# src/content/docs/index.md
|
||||
# src/content/docs/index
|
||||
title: My docs
|
||||
description: Learn more about my project in this docs site built with Starlight.
|
||||
---
|
||||
@@ -118,8 +118,8 @@ import { FileTree } from '@astrojs/starlight/components';
|
||||
- content/
|
||||
- docs/
|
||||
- **guides/**
|
||||
- guide.md
|
||||
- index.md
|
||||
- guide
|
||||
- index
|
||||
- pages/
|
||||
- astro.config.mjs
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ Starlight projects generally follow the same file and directory structure as oth
|
||||
|
||||
- `astro.config.mjs` — The Astro configuration file; includes the Starlight integration and configuration.
|
||||
- `src/content.config.ts` — Content collections configuration file; adds Starlight’s frontmatter schemas to your project.
|
||||
- `src/content/docs/` — Content files. Starlight turns each `.md`, `.mdx` or `.mdoc` file in this directory into a page on your site.
|
||||
- `src/content/docs/` — Content files. Starlight turns each ``, `.mdx` or `.mdoc` file in this directory into a page on your site.
|
||||
- `src/content/i18n/` (optional) — Translation data to support [internationalization](/guides/i18n/).
|
||||
- `src/` — Other source code and files (components, styles, images, etc.) for your project.
|
||||
- `public/` — Static assets (fonts, favicon, PDFs, etc.) that will not be processed by Astro.
|
||||
@@ -36,8 +36,8 @@ import { FileTree } from '@astrojs/starlight/components';
|
||||
- content/
|
||||
- docs/
|
||||
- guides/
|
||||
- 01-getting-started.md
|
||||
- 02-advanced.md
|
||||
- 01-getting-started
|
||||
- 02-advanced
|
||||
- index.mdx
|
||||
- content.config.ts
|
||||
- astro.config.mjs
|
||||
|
||||
@@ -17,7 +17,7 @@ No configuration is required to enable search. Build and deploy your site, then
|
||||
|
||||
To exclude a page from your search index, add [`pagefind: false`](/reference/frontmatter/#pagefind) to the page’s frontmatter:
|
||||
|
||||
```md title="src/content/docs/not-indexed.md" ins={3}
|
||||
```md title="src/content/docs/not-indexed" ins={3}
|
||||
---
|
||||
title: Content to hide from search
|
||||
pagefind: false
|
||||
@@ -30,7 +30,7 @@ Pagefind will ignore content inside an element with the [`data-pagefind-ignore`]
|
||||
|
||||
In the following example, the first paragraph will display in search results, but the contents of the `<div>` will not:
|
||||
|
||||
```md title="src/content/docs/partially-indexed.md" ins="data-pagefind-ignore"
|
||||
```md title="src/content/docs/partially-indexed" ins="data-pagefind-ignore"
|
||||
---
|
||||
title: Partially indexed page
|
||||
---
|
||||
|
||||
@@ -53,4 +53,4 @@ This object is used internally by the `NostrServerTransport` to construct announ
|
||||
|
||||
## Next Steps
|
||||
|
||||
With a solid understanding of the core modules, you are now ready to explore the **[Transports](../transports/base-nostr-transport.md)**, which are responsible for all network communication in the SDK.
|
||||
With a solid understanding of the core modules, you are now ready to explore the **[Transports](/transports/base-nostr-transport)**, which are responsible for all network communication in the SDK.
|
||||
@@ -69,4 +69,4 @@ These functions handle the low-level details of gift wrapping and unwrapping, bu
|
||||
|
||||
## Next Steps
|
||||
|
||||
Now that you understand how encryption works, let's look at the [Constants](./constants.md) used throughout the SDK.
|
||||
Now that you understand how encryption works, let's look at the [Constants](./constants) used throughout the SDK.
|
||||
@@ -34,8 +34,8 @@ export interface NostrSigner {
|
||||
|
||||
Any object that implements this interface can be used to sign events, allowing you to integrate with various key management systems, such as web, hardware wallets or remote signing services. The SDK provides a default implementation, `PrivateKeySigner`, which signs events using a raw private key.
|
||||
|
||||
- **Learn more:** [`NostrSigner` Deep Dive](../signer/nostr-signer-interface.md)
|
||||
- **Default Implementation:** [`PrivateKeySigner`](../signer/private-key-signer.md)
|
||||
- **Learn more:** [`NostrSigner` Deep Dive](/signer/nostr-signer-interface/)
|
||||
- **Default Implementation:** [`PrivateKeySigner`](/signer/private-key-signer/)
|
||||
|
||||
## `RelayHandler`
|
||||
|
||||
@@ -59,8 +59,8 @@ export interface RelayHandler {
|
||||
|
||||
By implementing this interface, you can create custom relay management logic, such as sophisticated relay selection strategies or custom reconnection policies. The SDK includes `SimpleRelayPool` as a default implementation.
|
||||
|
||||
- **Learn more:** [`RelayHandler` Deep Dive](../relay/relay-handler-interface.md)
|
||||
- **Default Implementation:** [`SimpleRelayPool`](../relay/simple-relay-pool.md)
|
||||
- **Learn more:** [`RelayHandler` Deep Dive](/relay/relay-handler-interface)
|
||||
- **Default Implementation:** [`SimpleRelayPool`](/relay/simple-relay-pool)
|
||||
|
||||
## `EncryptionMode`
|
||||
|
||||
@@ -76,7 +76,7 @@ export enum EncryptionMode {
|
||||
|
||||
This enum is used to configure the encryption behavior of the `NostrClientTransport` and `NostrServerTransport`.
|
||||
|
||||
- **Learn more:** [Encryption](./encryption.md)
|
||||
- **Learn more:** [Encryption](./encryption/)
|
||||
|
||||
## `AnnouncementMethods`
|
||||
|
||||
@@ -11,7 +11,7 @@ The `NostrMCPGateway` is a server-side bridging component that exposes a traditi
|
||||
|
||||
The gateway manages two transports simultaneously:
|
||||
|
||||
1. **Nostr Server Transport**: A [`NostrServerTransport`](../transports/nostr-server-transport.md) that listens for incoming connections from clients on the Nostr network.
|
||||
1. **Nostr Server Transport**: A [`NostrServerTransport`](/transports/nostr-server-transport) that listens for incoming connections from clients on the Nostr network.
|
||||
2. **MCP Server Transport**: A standard MCP client transport (like `StdioClientTransport`) that connects to a local or remote MCP server.
|
||||
|
||||
The gateway's role is to forward requests from Nostr clients to the MCP server and relay the server's responses back to the appropriate client on Nostr.
|
||||
@@ -80,4 +80,4 @@ console.log('Gateway is running, exposing the MCP server to Nostr.');
|
||||
|
||||
This concludes the core components of the SDK. The final section provides practical examples of how to use these components together.
|
||||
|
||||
- **[Tutorials](../tutorials/client-server-communication.md)**
|
||||
- **[Tutorials](/tutorials/client-server-communication)**
|
||||
@@ -27,12 +27,12 @@ This will install the SDK and its dependencies into your project.
|
||||
|
||||
The SDK is organized into several modules, each providing a specific set of functionalities:
|
||||
|
||||
- **[Core](../core/interfaces.md)**: Contains fundamental definitions, constants, interfaces, and utilities (e.g., encryption, serialization). It forms the foundation of the SDK.
|
||||
- **[Transports](../transports/base-nostr-transport.md)**: Critical for communication, this module provides `NostrClientTransport` and `NostrServerTransport` implementations for enabling MCP over Nostr.
|
||||
- **[Signer](../signer/nostr-signer-interface.md)**: Provides cryptographic signing capabilities required for Nostr events
|
||||
- **[Relay](../relay/relay-handler-interface.md)**: Manages Nostr relay connections, abstracting the complexity of relay interactions.
|
||||
- **[Proxy](../proxy/overview.md)**: A client-side MCP server that connects to other servers through Nostr, exposing their capabilities locally, specially useful for clients that don't natively support Nostr transport.
|
||||
- **[Gateway](../gateway/overview.md)**: An MCP server transport that binds to another MCP server, exposing its capabilities to the Nostr network, specially useful for servers that don't natively support Nostr transport.
|
||||
- **[Core](/core/interfaces)**: Contains fundamental definitions, constants, interfaces, and utilities (e.g., encryption, serialization).
|
||||
- **[Transports](/transports/base-nostr-transport)**: Critical for communication, this module provides `NostrClientTransport` and `NostrServerTransport` implementations for enabling MCP over Nostr.
|
||||
- **[Signer](/signer/nostr-signer-interface)**: Provides cryptographic signing capabilities required for Nostr events
|
||||
- **[Relay](/relay/relay-handler-interface)**: Manages Nostr relay connections, abstracting the complexity of relay interactions.
|
||||
- **[Proxy](/proxy/overview)**: A client-side MCP server that connects to other servers through Nostr, exposing their capabilities locally, specially useful for clients that don't natively support Nostr transport.
|
||||
- **[Gateway](/gateway/overview)**: An MCP server transport that binds to another MCP server, exposing its capabilities to the Nostr network, specially useful for servers that don't natively support Nostr transport.
|
||||
|
||||
## Core Concepts
|
||||
|
||||
@@ -51,8 +51,8 @@ These components are fundamental for creating and broadcasting Nostr events, whi
|
||||
|
||||
The SDK provides two specialized transports to send and receive MCP messages over the Nostr network:
|
||||
|
||||
- [`NostrClientTransport`](../transports/nostr-client-transport.md): Used by MCP clients to connect to remote MCP servers exposed via Nostr.
|
||||
- [`NostrServerTransport`](../transports/nostr-server-transport.md): Used by MCP servers to expose their capabilities through Nostr.
|
||||
- [`NostrClientTransport`](/transports/nostr-client-transport): Used by MCP clients to connect to remote MCP servers exposed via Nostr.
|
||||
- [`NostrServerTransport`](/transports/nostr-server-transport): Used by MCP servers to expose their capabilities through Nostr.
|
||||
|
||||
These transports handle the serialization of MCP messages into Nostr events and manage the communication flow.
|
||||
|
||||
@@ -60,8 +60,8 @@ These transports handle the serialization of MCP messages into Nostr events and
|
||||
|
||||
To simplify integration with existing MCP applications, the SDK provides two high-level bridging components:
|
||||
|
||||
- [`NostrMCPProxy`](../proxy/overview.md): A client-side bridge that allows an MCP client to communicate with a remote MCP server over Nostr without requiring native Nostr support in the client.
|
||||
- [`NostrMCPGateway`](../gateway/overview.md): A server-side bridge that exposes an existing MCP server to the Nostr network, allowing it to be discovered and used by Nostr-native clients.
|
||||
- [`NostrMCPProxy`](/proxy/overview): A client-side bridge that allows an MCP client to communicate with a remote MCP server over Nostr without requiring native Nostr support in the client.
|
||||
- [`NostrMCPGateway`](/gateway/overview): A server-side bridge that exposes an existing MCP server to the Nostr network, allowing it to be discovered and used by Nostr-native clients.
|
||||
|
||||
These components abstract away the underlying transport complexities, making it easy to connect conventional MCP setups with the decentralized Nostr ecosystem.
|
||||
|
||||
@@ -42,4 +42,4 @@ This documentation is structured to guide you from initial setup to advanced imp
|
||||
- **Proxy & Gateway**: Explains how to use the bridging components.
|
||||
- **Tutorials**: Provides practical, step-by-step examples.
|
||||
|
||||
Let's begin by setting up your environment in the [Installation Guide](./getting-started/installation.md).
|
||||
Let's begin by setting up your environment in the [Quick Overview](./getting-started/quick-overview/).
|
||||
@@ -8,10 +8,10 @@ hero:
|
||||
file: ../../assets/contextvm-logo.svg
|
||||
actions:
|
||||
- text: Get Started
|
||||
link: /guides/getting-started/quick-overview/
|
||||
link: /getting-started/quick-overview/
|
||||
icon: right-arrow
|
||||
- text: View on GitHub
|
||||
link: https://github.com/contextvm/sdk
|
||||
link: https://github.com/contextvm/ts-sdk
|
||||
icon: external
|
||||
variant: minimal
|
||||
---
|
||||
@@ -25,24 +25,9 @@ import { Card, CardGrid } from '@astrojs/starlight/components';
|
||||
Learn the foundational concepts and architecture of ContextVM
|
||||
</Card>
|
||||
<Card title="SDK Documentation" icon="code">
|
||||
Explore our comprehensive API documentation and implementation examples
|
||||
</Card>
|
||||
<Card title="Tutorials" icon="open-book">
|
||||
Follow step-by-step guides to build context-controlled applications
|
||||
Explore our comprehensive documentation and implementation examples
|
||||
</Card>
|
||||
<Card title="Integrations" icon="puzzle">
|
||||
Discover how ContextVM integrates with Nostr and other protocols
|
||||
Discover how ContextVM integrates MCP with Nostr
|
||||
</Card>
|
||||
</CardGrid>
|
||||
|
||||
## Quick Start
|
||||
|
||||
ContextVM provides a powerful framework for context-controlled computation on the Nostr network. Our SDK enables developers to:
|
||||
|
||||
- **Create secure contexts** for identity and application management
|
||||
- **Build distributed applications** with trustless architecture
|
||||
- **Integrate with Nostr** seamlessly through our transport layers
|
||||
- **Manage cryptographic signing** with extensible signer interfaces
|
||||
- **Handle relay operations** through our relay handler implementations
|
||||
|
||||
Ready to start building? Check out our [Quick Overview](/guides/getting-started/quick-overview/) to get up and running.
|
||||
</CardGrid>
|
||||
@@ -12,7 +12,7 @@ The `NostrMCPProxy` is a powerful, client-side bridging component in the `@conte
|
||||
The proxy manages two transports simultaneously:
|
||||
|
||||
1. **MCP Host Transport**: This is a standard MCP transport (like `StdioServerTransport`) that communicates with a local MCP client application.
|
||||
2. **Nostr Client Transport**: This is a [`NostrClientTransport`](../transports/nostr-client-transport.md) that communicates with the remote MCP server over the Nostr network.
|
||||
2. **Nostr Client Transport**: This is a [`NostrClientTransport`](/transports/nostr-client-transport) that communicates with the remote MCP server over the Nostr network.
|
||||
|
||||
The proxy sits in the middle, seamlessly forwarding messages between these two transports. When the local client sends a request, the proxy forwards it over Nostr. When the remote server sends a response, the proxy relays it back to the local client.
|
||||
|
||||
@@ -81,4 +81,4 @@ In this setup, a separate MCP client process could connect to this proxy's `Stdi
|
||||
|
||||
Next, we'll look at the server-side equivalent of the proxy:
|
||||
|
||||
- **[Gateway](../gateway/overview.md)**
|
||||
- **[Gateway](/gateway/overview)**
|
||||
@@ -1,11 +0,0 @@
|
||||
---
|
||||
title: Example Reference
|
||||
description: A reference page in my new Starlight docs site.
|
||||
---
|
||||
|
||||
Reference pages are ideal for outlining how things work in terse and clear terms.
|
||||
Less concerned with telling a story or addressing a specific use case, they should give a comprehensive outline of what you're documenting.
|
||||
|
||||
## Further reading
|
||||
|
||||
- Read [about reference](https://diataxis.fr/reference/) in the Diátaxis framework
|
||||
@@ -5,7 +5,7 @@ description: Learn how to create a custom relay handler for the @contextvm/sdk.
|
||||
|
||||
# Custom Relay Handler Development
|
||||
|
||||
The `@contextvm/sdk`'s-pluggable architecture, centered around the [`RelayHandler`](./relay-handler-interface.md) interface, allows developers to implement custom logic for managing Nostr-relay connections. This is particularly useful for advanced use cases that require more sophisticated behavior than what the default [`SimpleRelayPool`](./simple-relay-pool.md) provides.
|
||||
The `@contextvm/sdk`'s-pluggable architecture, centered around the [`RelayHandler`](./relay-handler-interface) interface, allows developers to implement custom logic for managing Nostr-relay connections. This is particularly useful for advanced use cases that require more sophisticated behavior than what the default [`SimpleRelayPool`](./simple-relay-pool) provides.
|
||||
|
||||
## Why Create a Custom Relay Handler?
|
||||
|
||||
@@ -88,5 +88,5 @@ Once your custom handler class is created, you can instantiate it and pass it to
|
||||
|
||||
With the `Relay` component covered, we will now look at the high-level bridging components provided by the SDK.
|
||||
|
||||
- **[Proxy](./proxy/overview.md)**
|
||||
- **[Gateway](./gateway/overview.md)**
|
||||
- **[Proxy](./proxy/overview)**
|
||||
- **[Gateway](./gateway/overview)**
|
||||
@@ -20,7 +20,7 @@ By depending on this interface, the SDK's transports can remain agnostic about t
|
||||
|
||||
## Interface Definition
|
||||
|
||||
The `RelayHandler` interface is defined in [`core/interfaces.ts`](../core/interfaces.md#relayhandler) and includes several key methods:
|
||||
The `RelayHandler` interface is defined in [`core/interfaces.ts`](/core/interfaces#relayhandler) and includes several key methods:
|
||||
|
||||
```typescript
|
||||
export interface RelayHandler {
|
||||
@@ -42,10 +42,10 @@ export interface RelayHandler {
|
||||
|
||||
The SDK provides a default implementation for common use cases and allows for custom implementations for advanced scenarios.
|
||||
|
||||
- **[SimpleRelayPool](./simple-relay-pool.md)**: The default implementation, which manages a simple pool of relays.
|
||||
- **[Custom Relay Handler](./custom-relay-handler.md)**: A guide to creating your own relay handler by implementing the `RelayHandler` interface.
|
||||
- **[SimpleRelayPool](./simple-relay-pool)**: The default implementation, which manages a simple pool of relays.
|
||||
- **[Custom Relay Handler](./custom-relay-handler)**: A guide to creating your own relay handler by implementing the `RelayHandler` interface.
|
||||
|
||||
## Next Steps
|
||||
|
||||
- Learn about the default implementation: **[SimpleRelayPool](./simple-relay-pool.md)**
|
||||
- Learn how to create your own: **[Custom Relay Handler](./custom-relay-handler.md)**
|
||||
- Learn about the default implementation: **[SimpleRelayPool](./simple-relay-pool)**
|
||||
- Learn how to create your own: **[Custom Relay Handler](./custom-relay-handler)**
|
||||
@@ -5,7 +5,7 @@ description: A default relay handler implementation for the @contextvm/sdk.
|
||||
|
||||
# `SimpleRelayPool`
|
||||
|
||||
The `SimpleRelayPool` is the default implementation of the [`RelayHandler`](./relay-handler-interface.md) interface provided by the `@contextvm/sdk`. It uses the `SimplePool` from the `nostr-tools` library to manage connections to a list of specified relays.
|
||||
The `SimpleRelayPool` is the default implementation of the [`RelayHandler`](./relay-handler-interface) interface provided by the `@contextvm/sdk`. It uses the `SimplePool` from the `nostr-tools` library to manage connections to a list of specified relays.
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -61,8 +61,8 @@ The `SimpleRelayPool` wraps the `SimplePool` from `nostr-tools` and implements t
|
||||
|
||||
The `SimpleRelayPool` is designed for simplicity. It connects to all provided relays and does not include advanced features.
|
||||
|
||||
For applications that require more sophisticated relay management, you may want to create a [Custom Relay Handler](./custom-relay-handler.md).
|
||||
For applications that require more sophisticated relay management, you may want to create a [Custom Relay Handler](./custom-relay-handler).
|
||||
|
||||
## Next Steps
|
||||
|
||||
- Learn how to build a custom relay handler: **[Custom Relay Handler](./custom-relay-handler.md)**
|
||||
- Learn how to build a custom relay handler: **[Custom Relay Handler](./custom-relay-handler)**
|
||||
@@ -5,11 +5,11 @@ description: Learn how to create a custom signer for the @contextvm/sdk.
|
||||
|
||||
# Custom Signer Development
|
||||
|
||||
One of the key design features of the `@contextvm/sdk` is its modularity, which is exemplified by the [`NostrSigner`](./nostr-signer-interface.md) interface. By creating your own implementation of this interface, you can integrate the SDK with any key management system, such as a hardware wallet, a remote signing service (like an HSM), or a browser extension.
|
||||
One of the key design features of the `@contextvm/sdk` is its modularity, which is exemplified by the [`NostrSigner`](./nostr-signer-interface) interface. By creating your own implementation of this interface, you can integrate the SDK with any key management system, such as a hardware wallet, a remote signing service (like an HSM), or a browser extension.
|
||||
|
||||
## Why Create a Custom Signer?
|
||||
|
||||
While the [`PrivateKeySigner`](./private-key-signer.md) is suitable for many development and server-side scenarios, a custom signer is often necessary when:
|
||||
While the [`PrivateKeySigner`](./private-key-signer) is suitable for many development and server-side scenarios, a custom signer is often necessary when:
|
||||
|
||||
- **Security is paramount**: You need to keep private keys isolated from the main application logic, for example, in a hardware security module (HSM) or a secure enclave.
|
||||
- **Interacting with external wallets**: Your application needs to request signatures from a user's wallet, such as a browser extension (e.g., Alby, Noster) or a mobile wallet.
|
||||
@@ -90,4 +90,4 @@ Once your custom signer class is created, you can instantiate it and pass it to
|
||||
|
||||
## Next Steps
|
||||
|
||||
With the `Signer` component covered, let's move on to the **[Relay](./relay-handler-interface.md)**, which handles another critical aspect of Nostr communication: managing connections to relays.
|
||||
With the `Signer` component covered, let's move on to the **[Relay](./relay-handler-interface)**, which handles another critical aspect of Nostr communication: managing connections to relays.
|
||||
@@ -19,7 +19,7 @@ This design offers several key benefits:
|
||||
|
||||
## Interface Definition
|
||||
|
||||
The `NostrSigner` interface is defined in [`core/interfaces.ts`](../core/interfaces.md#nostrsigner).
|
||||
The `NostrSigner` interface is defined in [`core/interfaces.ts`](/core/interfaces#nostrsigner).
|
||||
|
||||
```typescript
|
||||
export interface NostrSigner {
|
||||
@@ -51,10 +51,10 @@ Any class that implements this interface can be used as a signer throughout the
|
||||
|
||||
The SDK provides a default implementation for common use cases and allows for custom implementations for advanced scenarios.
|
||||
|
||||
- **[PrivateKeySigner](./private-key-signer.md)**: The default implementation, which takes a raw private key string and performs signing operations locally.
|
||||
- **[Custom Signer Development](./custom-signer-development.md)**: A guide to creating your own signer by implementing the `NostrSigner` interface.
|
||||
- **[PrivateKeySigner](./private-key-signer)**: The default implementation, which takes a raw private key string and performs signing operations locally.
|
||||
- **[Custom Signer Development](./custom-signer-development)**: A guide to creating your own signer by implementing the `NostrSigner` interface.
|
||||
|
||||
## Next Steps
|
||||
|
||||
- Learn about the default implementation: **[PrivateKeySigner](./private-key-signer.md)**
|
||||
- Learn how to create your own: **[Custom Signer Development](./custom-signer-development.md)**
|
||||
- Learn about the default implementation: **[PrivateKeySigner](./private-key-signer)**
|
||||
- Learn how to create your own: **[Custom Signer Development](./custom-signer-development)**
|
||||
@@ -5,7 +5,7 @@ description: A default signer implementation for the @contextvm/sdk.
|
||||
|
||||
# `PrivateKeySigner`
|
||||
|
||||
The `PrivateKeySigner` is the default implementation of the [`NostrSigner`](./nostr-signer-interface.md) interface provided by the `@contextvm/sdk`. It is a straightforward and easy-to-use signer that operates directly on a raw private key provided as a hexadecimal string.
|
||||
The `PrivateKeySigner` is the default implementation of the [`NostrSigner`](./nostr-signer-interface) interface provided by the `@contextvm/sdk`. It is a straightforward and easy-to-use signer that operates directly on a raw private key provided as a hexadecimal string.
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -67,4 +67,4 @@ For applications requiring a higher level of security, consider creating a custo
|
||||
|
||||
## Next Steps
|
||||
|
||||
- Learn how to build a custom signer: **[Custom Signer Development](./custom-signer-development.md)**
|
||||
- Learn how to build a custom signer: **[Custom Signer Development](./custom-signer-development)**
|
||||
@@ -5,7 +5,7 @@ description: An abstract class that provides the core functionality for all Nost
|
||||
|
||||
# Base Nostr Transport
|
||||
|
||||
The `BaseNostrTransport` is an abstract class that provides the core functionality for all Nostr-based transports in the `@contextvm/sdk`. It serves as the foundation for the [`NostrClientTransport`](./nostr-client-transport.md) and [`NostrServerTransport`](./nostr-server-transport.md), handling the common logic for connecting to relays, managing subscriptions, and converting messages between the MCP and Nostr formats.
|
||||
The `BaseNostrTransport` is an abstract class that provides the core functionality for all Nostr-based transports in the `@contextvm/sdk`. It serves as the foundation for the [`NostrClientTransport`](./nostr-client-transport) and [`NostrServerTransport`](./nostr-server-transport), handling the common logic for connecting to relays, managing subscriptions, and converting messages between the MCP and Nostr formats.
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
@@ -52,5 +52,5 @@ The `BaseNostrTransport` encapsulates the shared logic of Nostr communication, a
|
||||
|
||||
Now that you understand the foundation of the Nostr transports, let's explore the concrete implementations:
|
||||
|
||||
- **[Nostr Client Transport](./nostr-client-transport.md)**: For building MCP clients that communicate over Nostr.
|
||||
- **[Nostr Server Transport](./nostr-server-transport.md)**: For exposing MCP servers to the Nostr network.
|
||||
- **[Nostr Client Transport](./nostr-client-transport)**: For building MCP clients that communicate over Nostr.
|
||||
- **[Nostr Server Transport](./nostr-server-transport)**: For exposing MCP servers to the Nostr network.
|
||||
@@ -85,4 +85,4 @@ console.log('Available tools:', tools);
|
||||
|
||||
Next, we will look at the server-side counterpart to this transport:
|
||||
|
||||
- **[Nostr Server Transport](./nostr-server-transport.md)**: For exposing MCP servers to the Nostr network.
|
||||
- **[Nostr Server Transport](./nostr-server-transport)**: For exposing MCP servers to the Nostr network.
|
||||
@@ -5,7 +5,7 @@ description: A server-side component for exposing MCP servers over Nostr.
|
||||
|
||||
# Nostr Server Transport
|
||||
|
||||
The `NostrServerTransport` is the server-side counterpart to the [`NostrClientTransport`](./nostr-client-transport.md). It allows an MCP server to expose its capabilities to the Nostr network, making them discoverable and usable by any Nostr-enabled client. Like the client transport, it implements the `Transport` interface from the `@modelcontextprotocol/sdk`.
|
||||
The `NostrServerTransport` is the server-side counterpart to the [`NostrClientTransport`](./nostr-client-transport). It allows an MCP server to expose its capabilities to the Nostr network, making them discoverable and usable by any Nostr-enabled client. Like the client transport, it implements the `Transport` interface from the `@modelcontextprotocol/sdk`.
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -95,4 +95,4 @@ The `NostrServerTransport` manages a session for each unique client public key.
|
||||
|
||||
## Next Steps
|
||||
|
||||
Now that you understand how the transports work, let's dive into the **[Signer](../signer/nostr-signer-interface.md)**, the component responsible for cryptographic signatures.
|
||||
Now that you understand how the transports work, let's dive into the **[Signer](/signer/nostr-signer-interface)**, the component responsible for cryptographic signatures.
|
||||
@@ -16,7 +16,7 @@ We will build two separate scripts:
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- You have completed the [Installation Guide](../getting-started/installation.md).
|
||||
- You have completed the [Quick Overview](/getting-started/quick-overview/).
|
||||
- You have two Nostr private keys (one for the server, one for the client). You can generate new keys using various tools, or by running `nostr-tools` commands.
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user