restructure docs to have a more useful sidebar.

docs/.vitepress/config.js

@@ -7,11 +7,32 @@ export default {
     nav: [
       {text: 'Home', link: '/'},
       {text: 'Why', link: '/why'},
-      {text: 'Use Cases', link: '/use-cases'},
-      {text: 'Get Started', link: '/getting-started'},
-      {text: 'Cookbook', link: '/cookbook'},
+      {text: 'Docs', link: '/getting-started'},
       {text: 'Source', link: 'https://github.com/fiatjaf/khatru'}
     ],
+    sidebar: [
+      {
+        text: 'Core Concepts',
+        items: [
+          { text: 'Event Storage', link: '/core/eventstore' },
+          { text: 'Authentication', link: '/core/auth' },
+          { text: 'HTTP Integration', link: '/core/embed' },
+          { text: 'Request Routing', link: '/core/routing' },
+          { text: 'Management API', link: '/core/management' },
+          { text: 'Media Storage', link: '/core/blossom' },
+        ]
+      },
+      {
+        text: 'Cookbook',
+        items: [
+          { text: 'Search', link: '/cookbook/search' },
+          { text: 'Dynamic Relays', link: '/cookbook/dynamic' },
+          { text: 'Generating Events Live', link: '/cookbook/custom-live-events' },
+          { text: 'Custom Stores', link: '/cookbook/custom-stores' },
+          { text: 'Using something like Google Drive', link: '/cookbook/google-drive' },
+        ]
+      }
+    ],
     editLink: {
       pattern: 'https://github.com/fiatjaf/khatru/edit/master/docs/:path'
     }

docs/cookbook/index.md

@@ -1,11 +0,0 @@
-# Cookbook
-
-- [Dealing with `AUTH` messages and authenticated users](auth)
-- [Configuring the Relay Management API](management)
-- [Using the eventstore library](eventstore)
-- [Custom store: creating Nostr events on the fly from a non-Nostr source](custom-stores)
-- [Custom store: reading from Google Drive](google-drive)
-- [Live event generation](custom-live-events)
-- [Embedding `khatru` inside other Go HTTP servers](embed)
-- [Generating relays dynamically and serving them from the same path](dynamic)
-- [Routing between multiple relays](routing)

docs/core/eventstore.md

@@ -96,7 +96,3 @@ For example, maybe you want kind 1 events in `db1` and kind 30023 events in `db3
 		}
 	})
 ```
-
-## Search
-
-See [search](search).

docs/core/management.md

@@ -2,7 +2,7 @@
 outline: deep
 ---
 
-# Setting up the Relay Management API
+# Management API
 
 [NIP-86](https://nips.nostr.com/86) specifies a set of RPC methods for managing the boring aspects of relays, such as whitelisting or banning users, banning individual events, banning IPs and so on.
 

docs/core/routing.md

@@ -2,7 +2,7 @@
 outline: deep
 ---
 
-# Routing
+# Request Routing
 
 If you have one (or more) set of policies that have to be executed in sequence (for example, first you check for the presence of a tag, then later in the next policies you use that tag without checking) and they only apply to some class of events, but you still want your relay to deal with other classes of events that can lead to cumbersome sets of rules, always having to check if an event meets the requirements and so on. There is where routing can help you.
 

docs/index.md

@@ -9,9 +9,6 @@ hero:
     - theme: brand
       text: Get Started
       link: /getting-started
-    - theme: alt
-      text: Cookbook
-      link: /cookbook/
 
 features:
   - title: It's a library
@@ -20,19 +17,19 @@ features:
     details: This is not an executable that you have to tweak with config files, it's a library that you import and use, so you just write code and it does exactly what you want.
   - title: It's very very customizable
     icon: 🎶
-    link: /cookbook/embed
+    link: /core/embed
     details: Run arbitrary functions to reject events, reject filters, overwrite results of queries, perform actual queries, mix the relay stuff with other HTTP handlers or even run it inside an existing website.
   - title: It plugs into event stores easily
     icon: 📦
-    link: /cookbook/eventstore
+    link: /core/eventstore
     details: khatru's companion, the `eventstore` library, provides all methods for storing and querying events efficiently from SQLite, LMDB, Postgres, Badger and others.
   - title: It supports NIP-42 AUTH
     icon: 🪪
-    link: /cookbook/auth
+    link: /core/auth
     details: You can check if a client is authenticated or request AUTH anytime, or reject an event or a filter with an "auth-required:" and it will be handled automatically.
   - title: It supports NIP-86 Management API
     icon: 🛠️
-    link: /cookbook/management
+    link: /core/management
     details: You just define your custom handlers for each RPC call and they will be exposed appropriately to management clients.
   - title: It's written in Go
     icon: 🛵

docs/use-cases.md

@@ -1,27 +0,0 @@
-# Use cases
-
-`khatru` is being used today in the real world by
-
-* [pyramid](https://github.com/github-tijlxyz/khatru-pyramid), a relay with a invite-based whitelisting system similar to [lobste.rs](https://lobste.rs)
-* [triflector](https://github.com/coracle-social/triflector), a relay which enforces authentication based on custom policy
-* [countries](https://git.fiatjaf.com/countries), a relay that stores and serves content differently according to the country of the reader or writer
-* [jingle](https://github.com/fiatjaf/jingle), a simple relay that exposes part of `khatru`'s configuration options to JavaScript code supplied by the user that is interpreted at runtime
-* [njump](https://git.njump.me/njump), a Nostr gateway to the web that also serves its cached content in a relay interface
-* [song](https://git.fiatjaf.com/song), a personal git server that comes with an embedded relay dedicated to dealing with [NIP-34](https://nips.nostr.com/34) git-related Nostr events
-* [relay29](https://github.com/fiatjaf/relay29), a relay that powers most of the [NIP-29](https://nips.nostr.com/29) Nostr groups ecosystem
-* [fiatjaf.com](https://fiatjaf.com), a personal website that serves the same content as HTML but also as Nostr events.
-* [gm-relay](https://github.com/ptrio42/gm-relay), a relay that only accepts GM notes once a day.
-
-## Other possible use cases
-
-Other possible use cases, still not developed, include:
-
-* Bridges: `khatru` was initially developed to serve as an RSS-to-Nostr bridge server that would fetch RSS feeds on demand in order to serve them to Nostr clients. Other similar use cases could fit.
-* Paid relays: Nostr has multiple relays that charge for write-access currently, but there are many other unexplored ways to make this scheme work: charge per each note, charge per month, charge per month per note, have different payment methods, and so on.
-* Other whitelisting schemes: _pyramid_ implements a cool inviting scheme for granting access to the relay, same for _triflector_, but there are infinite other possibilities of other ways to grant access to people to an exclusive or community relay.
-* Just-in-time content generation: instead of storing a bunch of signed JSON and serving that to clients, there could be relays that store data in a more compact format and turn it into Nostr events at the time they receive a request from a Nostr client -- or relays that do some kind of live data generation based on who is connected, not storing anything.
-* Community relays: some internet communities may want relays that restrict writing or browsing of content only to its members, essentially making it a closed group -- or it could be closed for outsiders to write, but public for them to read and vice-versa.
-* Automated moderation schemes: relays that are owned by a group (either a static or a dynamic group) can rely on signals from their members, like mutes or reports, to decide what content to allow in its domains and what to disallow, making crowdfunded moderation easy.
-* Curation: in the same way as community relays can deal with unwanted content, they can also perform curation based on signals from their members (for example, if a member of the relay likes some note from someone that is outside the relay that note can be fetched and stored), creating a dynamic relay that can be browsed by anyone that share the same interests as that community.
-* Local relays: a relay that can be only browsed by people using the WiFi connection of some event or some building, serving as a way to share temporary or restricted content that only interests people sharing that circumstance.
-* Cool experiments: relays that only allow one note per user per day, relays that require proof-of-work on event ids], relays that require engagement otherwise you get kicked, relays that return events in different ordering, relays that impose arbitrary funny rules on notes in order for them to be accepted (i.e. they must contain the word "poo"), I don't know!

docs/why.md

@@ -8,3 +8,31 @@ If you want to craft a relay that isn't completely dumb, but it's supposed to
 * and other stuff.
 
 `khatru` provides a simple framework for creating your custom relay without having to reimplement it all from scratch or hack into other relay codebases.
+
+# Use cases
+
+`khatru` is being used today in the real world by
+
+* [pyramid](https://github.com/github-tijlxyz/khatru-pyramid), a relay with a invite-based whitelisting system similar to [lobste.rs](https://lobste.rs)
+* [triflector](https://github.com/coracle-social/triflector), a relay which enforces authentication based on custom policy
+* [countries](https://git.fiatjaf.com/countries), a relay that stores and serves content differently according to the country of the reader or writer
+* [jingle](https://github.com/fiatjaf/jingle), a simple relay that exposes part of `khatru`'s configuration options to JavaScript code supplied by the user that is interpreted at runtime
+* [njump](https://git.njump.me/njump), a Nostr gateway to the web that also serves its cached content in a relay interface
+* [song](https://git.fiatjaf.com/song), a personal git server that comes with an embedded relay dedicated to dealing with [NIP-34](https://nips.nostr.com/34) git-related Nostr events
+* [relay29](https://github.com/fiatjaf/relay29), a relay that powers most of the [NIP-29](https://nips.nostr.com/29) Nostr groups ecosystem
+* [fiatjaf.com](https://fiatjaf.com), a personal website that serves the same content as HTML but also as Nostr events.
+* [gm-relay](https://github.com/ptrio42/gm-relay), a relay that only accepts GM notes once a day.
+
+## Other possible use cases
+
+Other possible use cases, still not developed, include:
+
+* Bridges: `khatru` was initially developed to serve as an RSS-to-Nostr bridge server that would fetch RSS feeds on demand in order to serve them to Nostr clients. Other similar use cases could fit.
+* Paid relays: Nostr has multiple relays that charge for write-access currently, but there are many other unexplored ways to make this scheme work: charge per each note, charge per month, charge per month per note, have different payment methods, and so on.
+* Other whitelisting schemes: _pyramid_ implements a cool inviting scheme for granting access to the relay, same for _triflector_, but there are infinite other possibilities of other ways to grant access to people to an exclusive or community relay.
+* Just-in-time content generation: instead of storing a bunch of signed JSON and serving that to clients, there could be relays that store data in a more compact format and turn it into Nostr events at the time they receive a request from a Nostr client -- or relays that do some kind of live data generation based on who is connected, not storing anything.
+* Community relays: some internet communities may want relays that restrict writing or browsing of content only to its members, essentially making it a closed group -- or it could be closed for outsiders to write, but public for them to read and vice-versa.
+* Automated moderation schemes: relays that are owned by a group (either a static or a dynamic group) can rely on signals from their members, like mutes or reports, to decide what content to allow in its domains and what to disallow, making crowdfunded moderation easy.
+* Curation: in the same way as community relays can deal with unwanted content, they can also perform curation based on signals from their members (for example, if a member of the relay likes some note from someone that is outside the relay that note can be fetched and stored), creating a dynamic relay that can be browsed by anyone that share the same interests as that community.
+* Local relays: a relay that can be only browsed by people using the WiFi connection of some event or some building, serving as a way to share temporary or restricted content that only interests people sharing that circumstance.
+* Cool experiments: relays that only allow one note per user per day, relays that require proof-of-work on event ids], relays that require engagement otherwise you get kicked, relays that return events in different ordering, relays that impose arbitrary funny rules on notes in order for them to be accepted (i.e. they must contain the word "poo"), I don't know!