{{ theme }}
+
+### Page Data
+{{ page }}
+
+### Page Frontmatter
+{{ frontmatter }}
+```
+
+
+
+## Results
+
+### Theme Data
+{{ theme }}
+
+### Page Data
+{{ page }}
+
+### Page Frontmatter
+{{ frontmatter }}
+
+## More
+
+Check out the documentation for the [full list of runtime APIs](https://vitepress.dev/reference/runtime-api#usedata).
diff --git a/docs/cache/dexie.md b/docs/cache/dexie.md
new file mode 100644
index 00000000..114b53bd
--- /dev/null
+++ b/docs/cache/dexie.md
@@ -0,0 +1,153 @@
+# Dexie Cache
+
+Meant to be used client-side within a browser context. This is a cache adapter for [Dexie](https://dexie.org/), a wrapper around IndexedDB.
+
+## Usage
+
+NDK will attempt to use the Dexie adapter to store users, events, and tags. The default behaviour is to always check the cache first and then hit relays, replacing older cached events as needed.
+
+## Support
+
+- [x] Events
+- [x] User profiles
+- [x] Event<>Tag indexes
+- [x] NIP-05 lookups
+- [x] Unpublished events
+
+### Install
+
+```
+pnpm add @nostr-dev-kit/ndk-cache-dexie
+```
+
+### Add as a cache adapter
+
+```ts
+import NDKCacheAdapterDexie from "@nostr-dev-kit/ndk-cache-dexie";
+
+const dexieAdapter = new NDKCacheAdapterDexie({ dbName: 'your-db-name' });
+const ndk = new NDK({cacheAdapter: dexieAdapter, ...other config options});
+```
+
+🚨 Because Dexie only exists client-side, this cache adapter will not work in pure node.js environments. You'll need to make sure that you're using the right cache adapter in the right place (e.g. Redis on the backend, Dexie on the frontend).
+
+## Slowness
+
+Because IndexDB is painfully slow, this adapter will primarly act via an LRU cache that periodically flushes to the database. Individual read/writes don't directly hit the database.
+
+## Options
+
+[**NDK Dexie Cache Adapter**](../README.md) • **Docs**
+
+***
+
+[NDK Dexie Cache Adapter](../globals.md) / NDKCacheAdapterDexieOptions
+
+# Interface: NDKCacheAdapterDexieOptions
+
+## Properties
+
+### dbName?
+
+> `optional` **dbName**: `string`
+
+The name of the database to use
+
+#### Defined in
+
+[ndk-cache-dexie/src/index.ts:34](https://github.com/nostr-dev-kit/ndk/blob/26ea669eeeadbc93b894cac1f29829e9a41694cb/ndk-cache-dexie/src/index.ts#L34)
+
+***
+
+### debug?
+
+> `optional` **debug**: `Debugger`
+
+Debug instance to use for logging
+
+#### Defined in
+
+[ndk-cache-dexie/src/index.ts:39](https://github.com/nostr-dev-kit/ndk/blob/26ea669eeeadbc93b894cac1f29829e9a41694cb/ndk-cache-dexie/src/index.ts#L39)
+
+***
+
+### eventCacheSize?
+
+> `optional` **eventCacheSize**: `number`
+
+#### Defined in
+
+[ndk-cache-dexie/src/index.ts:53](https://github.com/nostr-dev-kit/ndk/blob/26ea669eeeadbc93b894cac1f29829e9a41694cb/ndk-cache-dexie/src/index.ts#L53)
+
+***
+
+### eventTagsCacheSize?
+
+> `optional` **eventTagsCacheSize**: `number`
+
+#### Defined in
+
+[ndk-cache-dexie/src/index.ts:54](https://github.com/nostr-dev-kit/ndk/blob/26ea669eeeadbc93b894cac1f29829e9a41694cb/ndk-cache-dexie/src/index.ts#L54)
+
+***
+
+### expirationTime?
+
+> `optional` **expirationTime**: `number`
+
+The number of seconds to store events in Dexie (IndexedDB) before they expire
+Defaults to 3600 seconds (1 hour)
+
+#### Defined in
+
+[ndk-cache-dexie/src/index.ts:45](https://github.com/nostr-dev-kit/ndk/blob/26ea669eeeadbc93b894cac1f29829e9a41694cb/ndk-cache-dexie/src/index.ts#L45)
+
+***
+
+### indexableKinds?
+
+> `optional` **indexableKinds**: `number`[] \| `"all"` \| `"none"`
+
+The kinds of events that should be indexed
+
+#### Default
+
+```ts
+"all"
+```
+
+#### Defined in
+
+[ndk-cache-dexie/src/index.ts:60](https://github.com/nostr-dev-kit/ndk/blob/26ea669eeeadbc93b894cac1f29829e9a41694cb/ndk-cache-dexie/src/index.ts#L60)
+
+***
+
+### nip05CacheSize?
+
+> `optional` **nip05CacheSize**: `number`
+
+#### Defined in
+
+[ndk-cache-dexie/src/index.ts:52](https://github.com/nostr-dev-kit/ndk/blob/26ea669eeeadbc93b894cac1f29829e9a41694cb/ndk-cache-dexie/src/index.ts#L52)
+
+***
+
+### profileCacheSize?
+
+> `optional` **profileCacheSize**: `number`
+
+Number of profiles to keep in an LRU cache
+
+#### Defined in
+
+[ndk-cache-dexie/src/index.ts:50](https://github.com/nostr-dev-kit/ndk/blob/26ea669eeeadbc93b894cac1f29829e9a41694cb/ndk-cache-dexie/src/index.ts#L50)
+
+***
+
+### zapperCacheSize?
+
+> `optional` **zapperCacheSize**: `number`
+
+#### Defined in
+
+[ndk-cache-dexie/src/index.ts:51](https://github.com/nostr-dev-kit/ndk/blob/26ea669eeeadbc93b894cac1f29829e9a41694cb/ndk-cache-dexie/src/index.ts#L51)
diff --git a/docs/cache/nostr.md b/docs/cache/nostr.md
new file mode 100644
index 00000000..ec166e2a
--- /dev/null
+++ b/docs/cache/nostr.md
@@ -0,0 +1,34 @@
+# Nostr Cache Adapter
+
+NDK cache adapter using a nostr relay as the database.
+
+This cache adapter is meant to be run against a local relay. This adapter will generate two NDK instances:
+
+`ndk` -- This talks exclusively to the local relay, with outbox model disabled.
+`fallbackNdk` -- This is used to hydrate the cache and uses the outbox model -- each query the cache receives is placed in a queue in the background so that subsequent requests can be served from the cache. All events from other relays
+
+## Usage
+
+### Install
+
+```
+npm add @nostr-dev-kit/ndk-cache-nostr
+
+```
+
+### Add as a cache adapter
+
+```ts
+import NDKCacheAdapterNostr from "@nostr-dev-kit/ndk-cache-nostr";
+
+const cacheAdapter = new NDKCacheAdapterNostr({
+ relayUrl: 'ws://localhost:5577',
+});
+const ndk = new NDK({ cacheAdapter });
+```
+
+If running server-side in a NodeJS environment, you should make sure to polyfill `WebSocket`.
+
+# License
+
+MIT
diff --git a/docs/getting-started/introduction.md b/docs/getting-started/introduction.md
new file mode 100644
index 00000000..50c63b8f
--- /dev/null
+++ b/docs/getting-started/introduction.md
@@ -0,0 +1,35 @@
+# Getting started
+
+## Installation
+
+```sh
+npm add @nostr-dev-kit/ndk
+```
+
+## Debugging
+
+NDK uses the `debug` package to assist in understanding what's happening behind the hood. If you are building a package
+that runs on the server define the `DEBUG` envionment variable like
+
+```sh
+export DEBUG='ndk:*'
+```
+
+or in the browser enable it by writing in the DevTools console
+
+```sh
+localStorage.debug = 'ndk:*'
+```
+
+## Network Debugging
+
+You can construct NDK passing a netDebug callback to receive network traffic events, particularly useful for debugging applications not running in a browser.
+
+```ts
+const netDebug = (msg: string, relay: NDKRelay, direction?: "send" | "recv") = {
+ const hostname = new URL(relay.url).hostname;
+ netDebug(hostname, msg, direction);
+}
+
+ndk = new NDK({ netDebug });
+```
diff --git a/docs/getting-started/signers.md b/docs/getting-started/signers.md
new file mode 100644
index 00000000..47346bef
--- /dev/null
+++ b/docs/getting-started/signers.md
@@ -0,0 +1,38 @@
+# Signers
+
+NDK uses signers _optionally_ passed in to sign events. Note that it is possible to use NDK without signing events (e.g. [to get someone's profile](https://github.com/nostr-dev-kit/ndk-cli/blob/master/src/commands/profile.ts)).
+
+Signing adapters can be passed in when NDK is instantiated or later during runtime.
+
+### Using a NIP-07 browser extension (e.g. Alby, nos2x)
+
+Instatiate NDK with a NIP-07 signer
+
+```ts
+// Import the package, NIP-07 signer and NDK event
+import NDK, { NDKEvent, NDKNip07Signer } from "@nostr-dev-kit/ndk";
+
+const nip07signer = new NDKNip07Signer();
+const ndk = new NDK({ signer: nip07signer });
+```
+
+NDK can now ask for permission, via their NIP-07 extension, to...
+
+**Read the user's public key**
+
+```ts
+nip07signer.user().then(async (user) => {
+ if (!!user.npub) {
+ console.log("Permission granted to read their public key:", user.npub);
+ }
+});
+```
+
+**Sign & publish events**
+
+```ts
+const ndkEvent = new NDKEvent(ndk);
+ndkEvent.kind = 1;
+ndkEvent.content = "Hello, world!";
+ndkEvent.publish(); // This will trigger the extension to ask the user to confirm signing.
+```
\ No newline at end of file
diff --git a/docs/getting-started/usage.md b/docs/getting-started/usage.md
new file mode 100644
index 00000000..068f985c
--- /dev/null
+++ b/docs/getting-started/usage.md
@@ -0,0 +1,57 @@
+# Usage
+
+## Instantiate an NDK instance
+
+You can pass an object with several options to a newly created instance of NDK.
+
+- `explicitRelayUrls` – an array of relay URLs.
+- `signer` - an instance of a [signer](#signers).
+- `cacheAdapter` - an instance of a [Cache Adapter](#caching)
+- `debug` - Debug instance to use for logging. Defaults to `debug("ndk")`.
+
+```ts
+// Import the package
+import NDK from "@nostr-dev-kit/ndk";
+
+// Create a new NDK instance with explicit relays
+const ndk = new NDK({
+ explicitRelayUrls: ["wss://a.relay", "wss://another.relay"],
+});
+```
+
+If the signer implements the `getRelays()` method, NDK will use the relays returned by that method as the explicit relays.
+
+```ts
+// Import the package
+import NDK, { NDKNip07Signer } from "@nostr-dev-kit/ndk";
+
+// Create a new NDK instance with just a signer (provided the signer implements the getRelays() method)
+const nip07signer = new NDKNip07Signer();
+const ndk = new NDK({ signer: nip07signer });
+```
+
+Note: In normal client use, it's best practice to instantiate NDK as a singleton class. [See more below](#architecture-decisions--suggestions).
+
+## Connecting
+
+After you've instatiated NDK, you need to tell it to connect before you'll be able to interact with any relays.
+
+```ts
+// Import the package
+import NDK from "@nostr-dev-kit/ndk";
+
+// Create a new NDK instance with explicit relays
+const ndk = new NDK({
+ explicitRelayUrls: ["wss://a.relay", "wss://another.relay"],
+});
+// Now connect to specified relays
+await ndk.connect();
+```
+
+## Architecture decisions & suggestions
+
+- Users of NDK should instantiate a single NDK instance.
+- That instance tracks state with all relays connected, explicit and otherwise.
+- All relays are tracked in a single pool that handles connection errors/reconnection logic.
+- RelaySets are assembled ad-hoc as needed depending on the queries set, although some RelaySets might be long-lasting, like the `explicitRelayUrls` specified by the user.
+- RelaySets are always a subset of the pool of all available relays.
diff --git a/docs/index.md b/docs/index.md
new file mode 100644
index 00000000..52fac990
--- /dev/null
+++ b/docs/index.md
@@ -0,0 +1,18 @@
+---
+# https://vitepress.dev/reference/default-theme-home-page
+layout: home
+
+hero:
+ name: "NDK Documentation"
+ tagline: "Nostr Development Kit Docs"
+ actions:
+ - theme: brand
+ text: Getting Started
+ link: /getting-started/introduction.html
+ - theme: secondary
+ text: References
+ link: https://github.com/nostr-dev-kit/ndk/blob/master/REFERENCES.md
+
+---
+
+NDK is a nostr development kit that makes the experience of building Nostr-related applications, whether they are relays, clients, or anything in between, better, more reliable and overall nicer to work with than existing solutions.
\ No newline at end of file
diff --git a/docs/internals/subscriptions.md b/docs/internals/subscriptions.md
new file mode 100644
index 00000000..ab328ce8
--- /dev/null
+++ b/docs/internals/subscriptions.md
@@ -0,0 +1,205 @@
+# Subscriptions Lifecycle
+When an application creates a subscription a lot of things happen under the hood.
+
+Say we want to see `kind:1` events from pubkeys `123`, `456`, and `678`.
+
+```ts
+const subscription = ndk.subscribe({ kinds: [1], authors: [ "123", "456", "678" ]})
+```
+
+Since the application level didn't explicitly provide a relay-set, which is the most common use case, NDK will calculate a relay set based on the outbox model plus a variety of some other factors.
+
+So the first thing we'll do before talking to relays is, decide to *which* relays we should talk to.
+
+The `calculateRelaySetsFromFilters` function will take care of this and provide us with a map of relay URLs and filters for each relay.
+
+This means that the query, as specified by the client might be broken into distinct queries specialized for the different relays.
+
+For example, if we have 3 relays, and the query is for `kind:1` events from pubkeys `a` and `b`, the `calculateRelaySetsFromFilters` function might return something like this:
+
+```ts
+{
+ "wss://relay1": { kinds: [1], authors: [ "a" ] },
+ "wss://relay2": { kinds: [1], authors: [ "b" ] },
+}
+```
+
+```mermaid
+flowchart TD
+ Client -->|"kinds: [1], authors: [a, b]"| Subscription1
+ Subscription1 -->|"kinds: [1], authors: [a]"| wss://relay1
+ Subscription1 -->|"kinds: [1], authors: [b]"| wss://relay2
+```
+
+## Subscription bundling
+Once the subscription has been split into the filters each relay should receive, the filters are sent to the individual `NDKRelay`'s `NDKRelaySubscriptionManager` instances.
+
+`NDKRelaySubscriptionManager` is responsible for keeping track of the active and scheduled subscriptions that are pending to be executed within an individual relay.
+
+This is an important aspect to consider:
+
+> `NDKSubscription` have a different lifecycle than `NDKRelaySubscription`. For example, a subscription that is set to close after EOSE might still be active within the `NDKSubscription` lifecycle, but it might have been already been closed within the `NDKRelaySubscription` lifecycle, since NDK attempts to keep the minimum amount of open subscriptions at any given time.
+
+## NDKRelaySubscription
+Most NDK subscriptions (by default) are set to be executed with a grouping delay. Will cover what this looks like in practice later, but for now, let's understand than when the `NDKRelaySubscriptionManager` receives an order, it might not execute it right away.
+
+The different filters that can be grouped together (thus executed as a single `REQ` within a relay) are grouped within the same `NDKRelaySubscription` instance and the execution scheduler is computed respecting what each individual `NDKSubscription` has requested.
+
+(For example, if a subscription with a `groupingDelay` of `at-least` 500 millisecond has been grouped with another subscription with a `groupingDelay` of `at-least` 1000 milliseconds, the `NDKRelaySubscriptionManager` will wait 1000 ms before sending the `REQ` to this particular relay).
+
+### Execution
+Once the filter is executed at the relay level, the `REQ` is submitted into that relay's `NDKRelayConnectivity` instance, which will take care of monitoring for responses for this particular REQ and communicate them back into the `NDKRelaySubscription` instance.
+
+Each `EVENT` that comes back as a response to our `REQ` within this `NDKRelaySubscription` instance is then compared with the filters of each `NDKSubscription` that has been grouped and if it matches, it is sent back to the `NDKSubscription` instance.
+
+
+# Example
+
+If an application requests `kind:1` of pubkeys `123`, `456`, and `789`. It creates an `NDKSubscription`:
+
+```ts
+ndk.subscribe({ kinds: [1], authors: [ "123", "456", "789" ]}, { groupableDelay: 500, groupableDelayType: 'at-least' })
+// results in NDKSubscription1 with filters { kinds: [1], authors: [ "123", "456", "789" ] }
+```
+
+Some other part of the application requests a kind:7 from pubkey `123` at the same time.
+
+```ts
+ndk.subscribe({ kinds: [7], authors: [ "123" ]}, { groupableDelay: 500, groupableDelayType: 'at-most' })
+// results in NDKSubscription2 with filters { kinds: [7], authors: [ "123" ] }
+```
+
+```mermaid
+flowchart TD
+ subgraph Subscriptions Lifecycle
+ A[Application] -->|"kinds: [1], authors: [123, 456, 678], groupingDelay: at-least 500ms"| B[NDKSubscription1]
+
+ A2[Application] -->|"kinds: [7], authors: [123], groupingDelay: at-most 1000ms"| B2[NDKSubscription2]
+ end
+```
+
+Both subscriptions have their relayset calculated by NDK and, the resulting filters are sent into the `NDKRelaySubscriptionManager`, which will decide what, and how filters can be grouped.
+
+```mermaid
+flowchart TD
+ subgraph Subscriptions Lifecycle
+ A[Application] -->|"kinds: [1], authors: [123, 456, 678], groupingDelay: at-least 500ms"| B[NDKSubscription1]
+ B --> C{Calculate Relay Sets}
+
+ A2[Application] -->|"kinds: [7], authors: [123], groupingDelay: at-most 1000ms"| B2[NDKSubscription2]
+ B2 --> C2{Calculate Relay Sets}
+ end
+
+ subgraph Subscription Bundling
+ C -->|"kinds: [1], authors: [123]"| E1[wss://relay1 NDKRelaySubscriptionManager]
+ C -->|"kinds: [1], authors: [456]"| E2[wss://relay2 NDKRelaySubscriptionManager]
+ C -->|"kinds: [1], authors: [678]"| E3[wss://relay3 NDKRelaySubscriptionManager]
+
+ C2 -->|"kinds: [7], authors: [123]"| E1
+ end
+```
+
+The `NDKRelaySubscriptionManager` will create `NDKRelaySubscription` instances, or add filters to them if `NDKRelaySubscription` with the same filter fingerprint exists.
+
+```mermaid
+flowchart TD
+ subgraph Subscriptions Lifecycle
+ A[Application] -->|"kinds: [1], authors: [123, 456, 678], groupingDelay: at-least 500ms"| B[NDKSubscription1]
+ B --> C{Calculate Relay Sets}
+
+ A2[Application] -->|"kinds: [7], authors: [123], groupingDelay: at-most 1000ms"| B2[NDKSubscription2]
+ B2 --> C2{Calculate Relay Sets}
+ end
+
+ subgraph Subscription Bundling
+ C -->|"kinds: [1], authors: [123]"| E1[wss://relay1 NDKRelaySubscriptionManager]
+ C -->|"kinds: [1], authors: [456]"| E2[wss://relay2 NDKRelaySubscriptionManager]
+ C -->|"kinds: [1], authors: [678]"| E3[wss://relay3 NDKRelaySubscriptionManager]
+
+ C2 -->|"kinds: [7], authors: [123]"| E1
+
+ E1 -->|"Grouping Delay: at-most 1000ms"| F1[NDKRelaySubscription]
+ E2 -->|"Grouping Delay: at-least 500ms"| F2[NDKRelaySubscription]
+ E3 -->|"Grouping Delay: at-least 500ms"| F3[NDKRelaySubscription]
+ end
+```
+
+Each individual `NDKRelaySubscription` computes the execution schedule of the filters it has received and sends them to the `NDKRelayConnectivity` instance, which in turns sends the `REQ` to the relay.
+
+```mermaid
+flowchart TD
+ subgraph Subscriptions Lifecycle
+ A[Application] -->|"kinds: [1], authors: [123, 456, 678], groupingDelay: at-least 500ms"| B[NDKSubscription1]
+ B --> C{Calculate Relay Sets}
+
+ A2[Application] -->|"kinds: [7], authors: [123], groupingDelay: at-most 1000ms"| B2[NDKSubscription2]
+ B2 --> C2{Calculate Relay Sets}
+ end
+
+ subgraph Subscription Bundling
+ C -->|"kinds: [1], authors: [123]"| E1[wss://relay1 NDKRelaySubscriptionManager]
+ C -->|"kinds: [1], authors: [456]"| E2[wss://relay2 NDKRelaySubscriptionManager]
+ C -->|"kinds: [1], authors: [678]"| E3[wss://relay3 NDKRelaySubscriptionManager]
+
+ C2 -->|"kinds: [7], authors: [123]"| E1
+
+ E1 -->|"Grouping Delay: at-most 1000ms"| F1[NDKRelaySubscription]
+ E2 -->|"Grouping Delay: at-least 500ms"| F2[NDKRelaySubscription]
+ E3 -->|"Grouping Delay: at-least 500ms"| F3[NDKRelaySubscription]
+
+ F1 -->|"REQ: kinds: [1, 7], authors: [123]"| G1[NDKRelayConnectivity]
+ F2 -->|"REQ: kinds: [1], authors: [456]"| G2[NDKRelayConnectivity]
+ F3 -->|"REQ: kinds: [1], authors: [678]"| G3[NDKRelayConnectivity]
+ end
+
+ subgraph Execution
+ G1 -->|"Send REQ to wss://relay1 after 1000ms"| R1[Relay1]
+ G2 -->|"Send REQ to wss://relay2 after 500ms"| R2[Relay2]
+ G3 -->|"Send REQ to wss://relay3 after 500ms"| R3[Relay3]
+ end
+```
+
+As the events come from the relays, `NDKRelayConnectivity` will send them back to the `NDKRelaySubscription` instance, which will compare the event with the filters of the `NDKSubscription` instances that have been grouped together and send the received event back to the correct `NDKSubscription` instance.
+
+```mermaid
+flowchart TD
+ subgraph Subscriptions Lifecycle
+ A[Application] -->|"kinds: [1], authors: [123, 456, 678], groupingDelay: at-least 500ms"| B[NDKSubscription1]
+ B --> C{Calculate Relay Sets}
+
+ A2[Application] -->|"kinds: [7], authors: [123], groupingDelay: at-most 1000ms"| B2[NDKSubscription2]
+ B2 --> C2{Calculate Relay Sets}
+ end
+
+ subgraph Subscription Bundling
+ C -->|"kinds: [1], authors: [123]"| E1[wss://relay1 NDKRelaySubscriptionManager]
+ C -->|"kinds: [1], authors: [456]"| E2[wss://relay2 NDKRelaySubscriptionManager]
+ C -->|"kinds: [1], authors: [678]"| E3[wss://relay3 NDKRelaySubscriptionManager]
+
+ C2 -->|"kinds: [7], authors: [123]"| E1
+
+ E1 -->|"Grouping Delay: at-most 1000ms"| F1[NDKRelaySubscription]
+ E2 -->|"Grouping Delay: at-least 500ms"| F2[NDKRelaySubscription]
+ E3 -->|"Grouping Delay: at-least 500ms"| F3[NDKRelaySubscription]
+
+ F1 -->|"REQ: kinds: [1, 7], authors: [123]"| G1[NDKRelayConnectivity]
+ F2 -->|"REQ: kinds: [1], authors: [456]"| G2[NDKRelayConnectivity]
+ F3 -->|"REQ: kinds: [1], authors: [678]"| G3[NDKRelayConnectivity]
+ end
+
+ subgraph Execution
+ G1 -->|"Send REQ to wss://relay1 after 1000ms"| R1[Relay1]
+ G2 -->|"Send REQ to wss://relay2 after 500ms"| R2[Relay2]
+ G3 -->|"Send REQ to wss://relay3 after 500ms"| R3[Relay3]
+
+ R1 -->|"EVENT: kinds: [1]"| H1[NDKRelaySubscription]
+ R1 -->|"EVENT: kinds: [7]"| H2[NDKRelaySubscription]
+ R2 -->|"EVENT"| H3[NDKRelaySubscription]
+ R3 -->|"EVENT"| H4[NDKRelaySubscription]
+
+ H1 -->|"Matched Filters: kinds: [1]"| I1[NDKSubscription1]
+ H2 -->|"Matched Filters: kinds: [7]"| I2[NDKSubscription2]
+ H3 -->|"Matched Filters: kinds: [1]"| I1
+ H4 -->|"Matched Filters: kinds: [1]"| I1
+ end
+```
\ No newline at end of file
diff --git a/docs/markdown-examples.md b/docs/markdown-examples.md
new file mode 100644
index 00000000..f9258a55
--- /dev/null
+++ b/docs/markdown-examples.md
@@ -0,0 +1,85 @@
+# Markdown Extension Examples
+
+This page demonstrates some of the built-in markdown extensions provided by VitePress.
+
+## Syntax Highlighting
+
+VitePress provides Syntax Highlighting powered by [Shiki](https://github.com/shikijs/shiki), with additional features like line-highlighting:
+
+**Input**
+
+````md
+```js{4}
+export default {
+ data () {
+ return {
+ msg: 'Highlighted!'
+ }
+ }
+}
+```
+````
+
+**Output**
+
+```js{4}
+export default {
+ data () {
+ return {
+ msg: 'Highlighted!'
+ }
+ }
+}
+```
+
+## Custom Containers
+
+**Input**
+
+```md
+::: info
+This is an info box.
+:::
+
+::: tip
+This is a tip.
+:::
+
+::: warning
+This is a warning.
+:::
+
+::: danger
+This is a dangerous warning.
+:::
+
+::: details
+This is a details block.
+:::
+```
+
+**Output**
+
+::: info
+This is an info box.
+:::
+
+::: tip
+This is a tip.
+:::
+
+::: warning
+This is a warning.
+:::
+
+::: danger
+This is a dangerous warning.
+:::
+
+::: details
+This is a details block.
+:::
+
+## More
+
+Check out the documentation for the [full list of markdown extensions](https://vitepress.dev/guide/markdown).
diff --git a/docs/mobile/index.md b/docs/mobile/index.md
new file mode 100644
index 00000000..e78b9544
--- /dev/null
+++ b/docs/mobile/index.md
@@ -0,0 +1,53 @@
+# NDK Mobile
+
+A React Native/Expo implementation of [NDK (Nostr Development Kit)](https://github.com/nostr-dev-kit/ndk) that provides a complete toolkit for building Nostr applications on mobile platforms.
+
+## Features
+
+- 🔐 Multiple signer implementations (NIP-07, NIP-46, Private Key)
+- 💾 SQLite-based caching for offline support
+- 🔄 Subscription management with automatic reconnection
+- 📱 React Native and Expo compatibility
+- 🪝 React hooks for easy state management
+- 👛 Integrated wallet support
+
+## Installation
+
+```sh
+npm install @nostr-dev-kit/ndk-mobile
+```
+
+## Usage
+
+When using this library don't import `@nostr-dev-kit/ndk` directly, instead import `@nostr-dev-kit/ndk-mobile`. `ndk-mobile` exports the same classes as `ndk`, so you can just swap the import.
+
+Once you have imported the library, you can use the `NDKProvider` to wrap your application. Pass as props all the typical arguments you would pass to an `new NDK()` call.
+
+```tsx
+function App() {
+ return