Finish SSH apps post

examples/blog.md

@@ -5,7 +5,7 @@ title: Example Blog Post
 isDraft: true
 isAgeRestricted: true
 authors: bad-manners
-# thumbnail: /src/assets/thumbnails/post_thumbnail.png
+# thumbnail: /src/assets/thumbnails/blog/post_thumbnail.png
 description: |
   Some funny text.
 # posts:

examples/game.md

@@ -8,7 +8,7 @@ isAgeRestricted: true
 authors: bad-manners
 contentWarning: >
   This game contains some stuff.
-# thumbnail: /src/assets/thumbnails/game_thumbnail.png
+# thumbnail: /src/assets/thumbnails/games/game_thumbnail.png
 description: |
   Some funny text.
 platforms: [web, windows, linux, macos, android, ios]

examples/story.md

@@ -9,7 +9,7 @@ authors: bad-manners
 # wordCount: 1000
 contentWarning: >
   Contains: Same size safe vore/endosoma (oral vore), with willing anthro male fox predator, and unwilling feral female wolf prey. Also includes other stuff.
-# thumbnail: /src/assets/thumbnails/story_thumbnail.png
+# thumbnail: /src/assets/thumbnails/stories/story_thumbnail.png
 description: |
   Some funny text.
 # posts:

package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "gallery.badmanners.xyz",
-  "version": "1.9.0",
+  "version": "1.10.0",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "gallery.badmanners.xyz",
-      "version": "1.9.0",
+      "version": "1.10.0",
       "hasInstallScript": true,
       "dependencies": {
         "@astrojs/check": "^0.9.3",

package.json

@@ -1,7 +1,7 @@
 {
   "name": "gallery.badmanners.xyz",
   "type": "module",
-  "version": "1.9.0",
+  "version": "1.10.0",
   "scripts": {
     "postinstall": "astro sync",
     "dev": "astro dev",

src/components/TocMdx.astro

@@ -21,16 +21,19 @@ const nestedHeadings = headings.reduce((acc, heading) => {
     let nextParent: NestedHeading = acc[acc.length - 1];
     while (nextParent.depth < heading.depth) {
       parent = nextParent;
-      if (!nextParent.children) {
-        nextParent.children = [];
+      if (!parent.children) {
         break;
       }
-      nextParent = nextParent.children[nextParent.children.length - 1];
+      nextParent = parent.children[parent.children.length - 1];
     }
     if (parent === null) {
       acc.push({ ...heading });
     } else {
-      parent.children!.push({ ...heading });
+      if (parent.children) {
+        parent.children.push({ ...heading });
+      } else {
+        parent.children = [{ ...heading }];
+      }
     }
   }
   return acc;

src/components/TocMdxHeading.astro

@@ -12,7 +12,7 @@ const { slug, text, children } = Astro.props;
 <li>
   <a href={`#${slug}`}>{text}</a>
   {
-    children ? (
+    children?.length ? (
       <ul>
         {children.map((child) => (
           <Astro.self {...child} />

src/content/blog/crossing-over-postmortem.mdx

@@ -3,7 +3,7 @@ title: "Jamming Over: A Postmortem"
 pubDate: 2024-03-26
 isAgeRestricted: true
 authors: bad-manners
-thumbnail: /src/assets/thumbnails/other/crossing_over_retrospective.png
+thumbnail: /src/assets/thumbnails/blog/crossing_over_retrospective.png
 description: |
   A retrospective about my first vore game, [Crossing Over](/games/crossing-over) – albeit more of an assortment of random thoughts than an actual postmortem. **Spoilers for Crossing Over ahead!**
 posts:

src/content/blog/ssh-all-the-way-down.mdx

@@ -4,7 +4,7 @@ title: SSH all the way down!
 pubDate: 2024-09-22
 isAgeRestricted: false
 authors: bad-manners
-thumbnail: /src/assets/thumbnails/other/ssh_all_the_way_down.png
+thumbnail: /src/assets/thumbnails/blog/ssh_all_the_way_down.png
 description: |
   A long investigation on how reverse port forwarding works in SSH; for fun at first, and then, fully embracing it.
 next: supercharged-ssh-apps-on-sish

src/content/blog/supercharged-ssh-apps-on-sish.mdx

@@ -1,11 +1,10 @@
 ---
 slug: supercharged-ssh-apps-on-sish
 title: Supercharged SSH applications on sish
-# pubDate: 2024-09-23
-isDraft: true
+pubDate: 2024-09-23
 isAgeRestricted: false
 authors: bad-manners
-# thumbnail: /src/assets/thumbnails/drafts/ssh_all_the_way_down.png
+thumbnail: /src/assets/thumbnails/blog/supercharged_ssh_apps_on_sish.png
 description: |
   After discovering the joys of a reverse port forwarding-based architecture, I dig even deeper into SSH itself to make the most of it.
 prev: ssh-all-the-way-down
@@ -26,7 +25,7 @@ import imageRusshAxum from "@assets/images/ssh/russh_axum.png";
 import imageCheckboxes from "@assets/images/ssh/checkboxes.png";
 import imageMultipaintByNumbers from "@assets/images/ssh/multipaint_by_numbers.png";
 
-This is my second post investigating SSH, learning all that it has to offer.
+This is my second post investigating SSH, and learning what it has to offer.
 
 <TocMdx headings={getHeadings()} />
 
@@ -39,7 +38,10 @@ In my [last post](/blog/ssh-all-the-way-down), I went over a saga of trying to s
     src={imageSishPublic}
     alt="Diagram entitled 'sish public', showing that Eric's machine with a service exposed on localhost port 3000 connects to sish via the command (ssh -R eric:80:localhost:3000 tuns.sh). This creates a bi-directional tunnel and exposes https://eric.tuns.sh to the Internet, which Tony accesses from a separate device."
   />
-  <figcaption>With a simple reverse shell command, we can expose anything to the Internet. © Antonio Mika</figcaption>
+  <figcaption>
+    With a simple reverse shell command, and a configured sish instance, we can expose anything to the Internet. ©
+    Antonio Mika
+  </figcaption>
 </figure>
 
 In fact, we can host anything TCP-based as long as we can create a secure shell to sish, even if it's running on the same host machine.
@@ -60,7 +62,7 @@ In a way, this is a two-fold solution. sish provides us with:
 1. A [reverse proxy](https://en.wikipedia.org/wiki/Reverse_proxy), which will handle and route any incoming traffic to the correct applications.
 2. A [hole-punching technique](<https://en.wikipedia.org/wiki/Hole_punching_(networking)>), letting us overcome any limitations that NAT imposes.
 
-But as of now, our applications all look something like this (in [Docker Compose](https://docs.docker.com/compose/) configuration):
+But as of now, all of our applications look something like this (in [Docker Compose](https://docs.docker.com/compose/) configuration):
 
 <figure>
 
@@ -95,7 +97,11 @@ services:
   <figcaption>A basic server connecting to sish via a persistent reverse SSH tunnel.</figcaption>
 </figure>
 
-It makes sense to have this separation into two images, if our application only uses an HTTP socket and isn't aware of the SSH tunneling shenanigans going on... which is most of the applications. But if we build our _own_ application, we could interact directly with SSH instead. In that case, how deep can we really integrate it with the existing architecture...?
+We have two images running for our application. One (`server`) is the actual webserver, while the other (`autosish`) handles the reverse port forwarding for us.
+
+It makes sense to have this separation into two images, if our application only uses an HTTP socket, and if it isn't aware of the SSH tunneling shenanigans going on... which is most of the applications.
+
+But if we build our _own_ application, we could interact directly with SSH instead. In that case, how deep can we really integrate it with the existing architecture...?
 
 In this post, we will work on a tunnel-aware application, and finding out more about the SSH protocol. Be forewarned that there will be plenty of [Rust](https://www.rust-lang.org/) code ahead!
 
@@ -105,7 +111,9 @@ But first of all, how does remote port forwarding through an SSH tunnel work?
 
 Better yet, how does _an SSH tunnel_ even work?
 
-In the previous post, I explained that SSH is an [application-layer protocol](https://en.wikipedia.org/wiki/Application_layer) that runs on top of TCP. Our SSH server is listening on a port (usually 22) and we are able to connect to it. It has its own protocols and implementations, but as long as it's implemented properly by a library, we are able to connect without the default SSH client.
+In the previous post, I explained that SSH is an [application-layer protocol](https://en.wikipedia.org/wiki/Application_layer) that runs on top of TCP. Our SSH server is listening on a port (usually 22) and we are able to connect to it.
+
+SSH has its own protocols and implementations as expected, but so long as it's implemented properly by a library, we should be able to connect without the default SSH client.
 
 <figure>
   <Image
@@ -153,9 +161,9 @@ async fn main() -> Result<()> {
 }
 ```
 
-If you're unfamiliar with Rust, this might be a lot at once. In summary, we're just importing some dependencies at the top, and at the bottom, inside of `fn main()`, we're setting up a client connection with `client::connect()`.
+If you're unfamiliar with Rust, this might be a lot at once. In summary, we're doing two things: at the top, we import any dependencies we need; and at the bottom, inside of `async fn main()`, we're setting up a client connection with `client::connect()`.
 
-Aside from this code, we also need to define the `Client` struct, which will be responsible for answering messages created by the server. This will implement the `russh::client::Handler` async trait, responsible for linking our methods to the ones that the library knows to call.
+Aside from this code, we also need to define the `Client` struct, which will be responsible for answering messages created by the server. This will implement the `russh::client::Handler` async trait, responsible for exposing our user-defined methods to the ones that the library knows to call.
 
 ```rust
 use async_trait::async_trait;
@@ -183,21 +191,21 @@ With these two pieces, we can try running our program with cargo like this:
 cargo run -- -R test -p 80 -i ~/.ssh/id_ed25519 sish.top
 ```
 
-We're using an argument parser to read the flags, [clap](https://docs.rs/clap/latest/clap/). The way it's set up, you can read this as being equivalent to the other command that we've seen so far:
+We're using [clap](https://docs.rs/clap/latest/clap/), an argument parser, to read the flags that are passed. The way it's set up, you can read this as being equivalent to the other command that we've seen so far:
 
 ```sh
 ssh -R test:80:localhost:???? -i ~/.ssh/id_ed25519 sish.top
 ```
 
-(Notice that we no longer specify the port in the localhost; we'll get to that later.)
+(Notice that we no longer specify the local port to forward remote connections to; we'll get to that later.)
 
 When we run this, it prints `Connected.` on our terminal, then immediately exits the program.
 
 At least we're doing...not nothing.
 
-You might've realized that we aren't actually doing anything with the connection when we create it. The `client::connect()` function simply establishes the TCP socket and checks for the server's key fingerprint, through the single method that we've implemented on the `Client` struct.
+You might've realized that the connection is being ignored right after we create it. The `client::connect()` function simply establishes the TCP socket and checks for the server's key fingerprint, through the single method that we've implemented on the `Client` struct.
 
-As you may have guessed from the identity file being passed to the command, we'll have to use that to authenticate now. So after we create a connection, we'll immediately call `session.authenticate_publickey()` to do so via public key cryptography. I've cut the repeated portion of the program below with a `// ... snip ...`:
+As you may have guessed from the identity file being passed to the command, we'll have to use that to authenticate now. So after we create a connection, we'll immediately call `session.authenticate_publickey()` to do so via public key cryptography. I've cut the repeated portion of the program below with a `snip`:
 
 ```rust
 use std::path::PathBuf;
@@ -211,11 +219,11 @@ async fn main() -> Result<()> {
     let secret_key = fs::read_to_string(args.identity_file)
         .await
         .with_context(|| "Failed to open identity file")?;
-    let secret_key =
-        Arc::new(decode_secret_key(&secret_key, None).with_context(|| "Invalid secret key")?);
+    let secret_key = decode_secret_key(&secret_key, None)
+        .with_context(|| "Invalid secret key")?;
 
     if session
-        .authenticate_publickey(args.login_name, secret_key)
+        .authenticate_publickey(args.login_name, Arc::new(secret_key))
         .await
         .with_context(|| "Error while authenticating with public key.")?
     {
@@ -230,9 +238,9 @@ async fn main() -> Result<()> {
 
 If your key is authorized with the given server, this will print `Public key authentication succeeded!` after connecting, then immediately exit again. Not a lot of progress, but bear with me.
 
-So connecting and authenticating is straightforward enough. You might draw a parallel with connecting to a website, then logging in with your credentials. What comes after you log in is a bit more freeform, and depends on what you intend to do on the website.
+So connecting and authenticating is straightforward enough. You might draw a parallel with first connecting to a website, then logging in with your credentials. What comes after you log in is a bit more freeform, and depends on what you intend to do on the website.
 
-With SSH, the analogy still holds. After creating a session, there are many options for what we can do next ([many of them available in russh](https://docs.rs/russh/0.45.0/russh/client/struct.Session.html)):
+With SSH, the analogy still holds. After creating a session, there are many options for what we can do next ([all of them available in russh](https://docs.rs/russh/0.45.0/russh/client/struct.Session.html)):
 
 - `request_pty()`: Request that an interactive [pseudoterminal](https://en.wikipedia.org/wiki/Pseudoterminal) is created by the server, allowing us to enter commands over a remote shell session. This is the most common usecase for SSH.
 - `request_x11()`: Request that an [X11 connection](https://en.wikipedia.org/wiki/X_Window_System) is displayed over the Internet. This lets us access graphical applications through SSH!
@@ -255,9 +263,9 @@ async fn main() -> Result<()> {
 }
 ```
 
-Once again, it succeeds and binds on what we'd expect, then exits immediately. I'm seeing a pattern here...
+Once again, it succeeds and binds on the provided host and port, then exits immediately. I'm seeing a pattern here...
 
-It turns out that there's one missing piece here, and that is to create an open-session channel. We'll get into the reasons why in the next section, but for now, let's push on with some more code.
+It turns out that there's one missing piece here, and that is to create an open-session channel. We'll get into the reason why in the next subsection, but for now, let's push on with some more code.
 
 ```rust
 use russh::{ChannelMsg, Disconnect};
@@ -271,6 +279,7 @@ async fn main() -> Result<()> {
         .channel_open_session()
         .await
         .with_context(|| "channel_open_session error.")?;
+    println!("Created open session channel.");
     let mut stdout = stdout();
     let mut stderr = stderr();
     let code = loop {
@@ -309,7 +318,7 @@ async fn main() -> Result<()> {
 }
 ```
 
-There's a lot going on in this one. First we create a channel with `session.channel_open_session()`, then we set up a `loop` that will read every message that we eventually get through this channel (by reading it with `channel.wait().await`) and handle it appropriately. Then, we try to close the session cleanly if possible.
+There's a lot going on in this one. First we create a channel with `session.channel_open_session()`, then we set up a `loop` that will read every message that we eventually get through this channel (by reading it with `channel.wait().await`). We have to handle each message type appropriately. Then, once the channel closes, we try to close the session cleanly if possible.
 
 When we run it this time, we expect it to simply exit after printing the–
 
@@ -323,43 +332,49 @@ HTTPS: https://test.sish.top
 
 Wait, the session is actually persisting?! And we even got some data from sish in the process!
 
-When we created the channel through `session.channel_open_session()`, the server automatically knew that it could send information to us through it. It is just a two-way tunnel where every message is secure, so we can read data and even send some back if we want (for example, with [`stdin`](https://en.wikipedia.org/wiki/Standard_streams)).
+When we created the channel through `session.channel_open_session()`, the server automatically knew that it could send us information through it. It is just a two-way tunnel where every message is secure, so we can read data, and even send some back if we want (for example, with [`stdin`](https://en.wikipedia.org/wiki/Standard_streams) if we're making a terminal application).
 
 That's cool and all, but more important is how it gave us a URL for our service – with automatic HTTPS, even! I wonder what happens if I try to open that link in my browser...
 
 ...
 
-...It just times out with "bad gateway", causing our SSH program to exit.
+...It just times out after a while with "bad gateway", causing our SSH program to exit.
 
-Well, that's less exciting. But at least it's doing _something_. Besides, if we never touch the link that it passed us, we can stay connected indefinitely. And as soon as we open the link anywhere, we consistently get disconnected from the SSH server. That's proof that there's a relation between what the browser sees and our little program.
+Well, that's less exciting. But at least it's doing _something_. Besides, if we never touch the link that it passed us, we can stay connected indefinitely. And as soon as we open the link on any device, we consistently get disconnected from the SSH server. That's proof that there's a relation between what the browser sees and our little Rust program.
 
-The reason why we get disconnected is because we aren't handling any requests that come in. Right now, there's no way to read HTTP requests, or send HTTP responses.
+The reason why we get disconnected is because we aren't handling any requests that come in. Right now, there's no way to read HTTP requests, even less sending HTTP responses.
 
 But I thought `channel_open_session()` was already doing that? Not really – it only serves to transfer messages between the client and the server. Instead, to handle each new connection, we need to use a new channel.
 
 Sounds simple enough. Then how do we create these channels? The answer is also simple: We don't.
 
-## Changing channels
+### Changing channels
 
 At this point, it's worth taking a detour from all of the code and explain how an SSH session actually works.
 
-[RFC 4254](https://datatracker.ietf.org/doc/html/rfc4254) is the document that dictates how SSH connections are supposed to work on a higher level. There are some interesting details, but most importantly for us is [5 - Channel Mechanism section](https://datatracker.ietf.org/doc/html/rfc4254#section-5):
+[RFC 4254](https://datatracker.ietf.org/doc/html/rfc4254) is the document that dictates how SSH connections are supposed to work on a higher level. There are some interesting details, but most importantly for us is the ["5. Channel Mechanism"](https://datatracker.ietf.org/doc/html/rfc4254#section-5) section:
 
 > All terminal sessions, forwarded connections, etc., are channels. Either side may open a channel. Multiple channels are multiplexed into a single connection.
 
 In other words, a connection can have multiple channels, each responsible for a part of the system. This explicitly includes forwarded connections, such as the ones we are looking for.
 
-Specifically, in [7.1 - Request Port Forwarding section](https://datatracker.ietf.org/doc/html/rfc4254#section-7.1), the mechanism for requesting a port is specified. It's exactly what we're doing right now. In the next section, [7.2 - TCP/IP Forwarding Channels](https://datatracker.ietf.org/doc/html/rfc4254#section-7.2), the expected behavior of the server is explained:
+Even more so, either side can open channels. Earlier, we opened one with `session.channel_open_session()` from the client-side, but the server is also allowed to open them if necessary.
+
+Specifically, we see that in the ["7.1. Request Port Forwarding"](https://datatracker.ietf.org/doc/html/rfc4254#section-7.1) section, the mechanism for requesting a port is specified. It's exactly what we're doing right now, using `session.tcpip_forward()` and what not.
+
+In the next section, ["7.2. TCP/IP Forwarding Channels"](https://datatracker.ietf.org/doc/html/rfc4254#section-7.2), the expected behavior of the server is explained:
 
 > When a connection comes to a port for which remote forwarding has been requested, a channel is opened to forward the port to the other side.
 
-So a new channel is being created and opened _for_ us. The channel is labeled `forwarded-tcpip`, which corresponds with the `server_channel_open_forwarded_tcpip()` method of `russh::client::Handler`. Previously, we only added a method to our `Client` struct that accepted all of the key fingerprints that the server provides, so we're gonna add a second one to handle the forwarding.
+So a new channel is being created and opened _for_ us. The channel is labeled `forwarded-tcpip`, which corresponds with the `server_channel_open_forwarded_tcpip()` method of `russh::client::Handler`.
 
-Remember, forwarded connections are channels, so we can use them just like the channel we get from `session.channel_open_session()`. And thankfully, Tokio has some utilities to make their usage trivial for our case.
+Previously, that `Handler` only had one defined method by our `Client` struct, which accepted all of the key fingerprints that the server provides. So we gotta add a second one to handle any received forwarding channels.
 
-## Back in session
+Remember, forwarded connections are channels, so we can use them just like the channel we get from `session.channel_open_session()`. And thankfully, as you'll see, Tokio has some utilities to make their usage trivial for our case.
 
-If I understood the documentation correctly, then we should be pretty close to actually getting something to the HTTP endpoint! We just need to create an HTTP server on our side to handle everything for us, then connect it to the data channel that we receive from the server.
+### Back in session
+
+If I understood the documentation correctly, then we should be pretty close to actually getting something to the HTTP endpoint! We just need to create an HTTP server on our side to handle everything for us, then connect it to the data channels that we receive from the server.
 
 First, let's make the simplest HTTP server with global state that we can:
 
@@ -376,25 +391,25 @@ struct AppState {
     data: Arc<AtomicUsize>,
 }
 
+/// A basic example endpoint that includes shared state.
+async fn hello(State(state): State<AppState>) -> String {
+    let request_id = state.data.fetch_add(1, Ordering::AcqRel);
+    format!("Hello, request #{}!", request_id)
+}
+
 /// A lazily-created Router, to be used by the SSH client tunnels.
 static ROUTER: LazyLock<Router> = LazyLock::new(|| {
     Router::new().route("/", get(hello)).with_state(AppState {
         data: Arc::new(AtomicUsize::new(1)),
     })
 });
-
-/// A basic example endpoint that includes shared state.
-async fn hello(State(state): State<AppState>) -> String {
-    let request_id = state.data.fetch_add(1, Ordering::AcqRel);
-    format!("Hello, request #{}!", request_id)
-}
 ```
 
-If you're unfamiliar with Rust's [synchronization primitives](https://doc.rust-lang.org/std/sync/index.html), this may be a bit hard to read. But all this does is create a lazily-evaluated HTTP server that responds to each subsequent request with a global counter (starting on 1, 2, 3, and so on).
+If you're unfamiliar with Rust's [synchronization primitives](https://doc.rust-lang.org/std/sync/index.html), this may be a bit hard to read. But all this does is create a lazily-evaluated HTTP server on `ROUTER` that responds to each subsequent request with a global counter (starting on 1, 2, 3, and so on).
 
-Remember that our goal is to serve this router to any channels received through `server_channel_open_forwarded_tcpip()` on our `Client`. If we were in the C world, we'd need to reference the channel directly by its ID – but in `russh`, a struct representing the channel is already given to us, abstracting that detail away.
+Remember that our goal is to serve this router to any channels received through `server_channel_open_forwarded_tcpip()`. If we were in the C world, we'd need to reference the channel directly by its ID – but in `russh`, a struct representing the channel is already given to us, abstracting that detail away and avoiding any mistakes on the programmer's part.
 
-In order to connect both parts, we'll turn the provided SSH channel into a stream, then use some magic with Hyper and Tower to be able to serve HTTP responses as if that stream were a TCP socket:
+In order to connect the `ROUTER` and the channel together, we'll turn the provided SSH channel into a [stream](https://tokio.rs/tokio/tutorial/streams), then use some magic with Hyper and Tower to be able to serve HTTP responses as if that stream were a TCP socket:
 
 ```rust
 use hyper::service::service_fn;
@@ -423,11 +438,13 @@ impl client::Handler for Client {
         session: &mut Session,
     ) -> Result<(), Self::Error> {
         let router = &*ROUTER;
-        let service = service_fn(move |req| router.clone().call(req));
+        let service = service_fn(
+            move |req| router.clone().call(req));
         let server = Builder::new(TokioExecutor::new());
         tokio::spawn(async move {
             server
-                .serve_connection_with_upgrades(TokioIo::new(channel.into_stream()), service)
+                .serve_connection_with_upgrades(
+                    TokioIo::new(channel.into_stream()), service)
                 .await
                 .expect("Invalid request");
         });
@@ -451,9 +468,9 @@ And, as you may have noticed, we never used a single TCP socket, other than to c
 
 But then, why does the SSH client require that you specify a numbered port for remote forwarding if it's unnecessary? I imagine that the reason for it is convenience. It's easier to map one socket (the remote one) to another (your local one), and ends up being what you want to do in the majority of cases anyway.
 
-However, you can see that the underlying SSH protocol is not too complicated, at least through the interfaces it exposes. We only had to write less than 200 lines of Rust code, and we're already doing things that the regular SSH client can't.
+However, you can see that the underlying SSH protocol is not too complicated, at least through the interfaces it exposes. We only had to write less than 200 lines of Rust code, and we're already doing things that the regular SSH client can't alone.
 
-In summary, this is what the code does:
+To summarize, this is what the code does:
 
 1. Starts a connection with the SSH server.
 2. Authenticates via public key.
@@ -465,23 +482,23 @@ If you want to see the final code, with some additional functionality for runnin
 
 ## Painting the bigger picture
 
-But a simple HTTP server isn't that interesting by itself, even though it's running just over SSH. Can we do better?
+But a simple HTTP server isn't that interesting by itself, even though it's running over SSH instead of a socket. Can we do better?
 
-Yes, we can. We get all the features that we'd expect, including support for WebSockets – but that's beyond the scope of this project.
+Yes, we can. We get all of the nice HTTP features that we'd expect, including support for [WebSocket](https://en.wikipedia.org/wiki/WebSocket) – but that's beyond the scope of this post.
 
-What I'm more interested in is pushing the limits of this solution in terms of simple HTTP. And since I was just starting to learn [htmx](https://htmx.org/), it seemed like the perfect opportunity to put it to the proof.
+What I'm more interested in is pushing the limits of this solution in terms of simple HTTP. And since I was just starting to learn [htmx](https://htmx.org/), it seemed like the perfect opportunity to put it to the test.
 
-At first, I made a simple application that stores a bunch of checkboxes, updates them when you click them, and then periodically polls the server to grab modifications done by other users. It was a dumb but easy idea to implement, but it didn't stop there.
+At first, I made a simple application that stores data for a bunch of checkboxes, then updates them when you click them, and periodically polls the server to grab modifications done by other users. It was a dumb but easy idea to implement, but I didn't stop there.
 
 <figure>
   <Image
     src={imageCheckboxes}
     alt="A screenshot of a browser with a Web 1.0-looking picross or nonogram grid, entitled Multipaint by Numbers, and containing instructions on how to play, as well as multiple colorful cursors."
   />
-  <figcaption>Running a poor man's clone of A Million Checkboxes.</figcaption>
+  <figcaption>Running a poor man's clone of One Million Checkboxes.</figcaption>
 </figure>
 
-Seeing the checkboxes getting filled and emptied in a grid reminded me a lot of nonograms. You might know them by picross or paint by numbers or not know them at all, but they are a kind of puzzle made by filling cells in a grid in order to reveal a pixelated image. So I thought, why not make a multiplayer version of it? And I called it Multipaint by Numbers, and worked on it over a few days.
+Seeing the checkboxes getting filled and emptied in a grid reminded me a lot of [nonograms](https://en.wikipedia.org/wiki/Nonogram). You might know them by "picross" or "paint by numbers", or not know them at all, but they are a kind of puzzle made by filling cells in a grid in order to reveal a pixelated image. So I thought, why not make a multiplayer version of it? And I called it Multipaint by Numbers, and worked on it over the next several days.
 
 <figure>
   <Image
@@ -491,25 +508,39 @@ Seeing the checkboxes getting filled and emptied in a grid reminded me a lot of
   <figcaption>A screenshot of me playing Multipaint by Numbers together with myself.</figcaption>
 </figure>
 
-It's a janky mess, but it technically works. It has click-and-drag, it has flagging, and it even has cursors that (try to) match those of other people currently playing as well! It's certainly janky, as HTMX wasn't designed for highly interactive applications like this one, but it was also quite a breath of fresh air compared to writing Javascript. In general, it was a fun learning experience.
+It's a janky mess, sure, but it definitely works! It has click-and-drag, it has flagging, and it even has cursors that (try to) match those of other people currently playing as well! It definitely feels buggy (rather than _actually_ being buggy) and unresponsive, since HTMX wasn't designed for highly interactive applications like this one. But it was quite a fun learning experience! If you've dabbled in full-stack development, I highly recommend checking out HTMX if you haven't – compared to JS, it's like a breath of fresh air.
 
-It's available to play on https://multipaint.sish.top, and you can see the source code [here](https://github.com/BadMannersXYZ/htmx-ssh-games).
+But if you just wanna play it yourself, Multipaint by Numbers is available to play on https://multipaint.sish.top, and you can find the source code [here](https://github.com/BadMannersXYZ/htmx-ssh-games).
 
 ## Awaiting the future
 
 Of course, none of these projects do anything special. It'd be better to just make them as plain HTTP applications, after all. Why go through such a roundabout way to make webapps?
 
-But there was reason. These were just toy projects to learn the basics about russh, Axum, and HTMX. And I was hoping to go in a new direction with this knowledge.
+But there was a reason. Both "400 Checkboxes" and "Multipaint by Numbers" were just toy projects to learn the basics about russh, Axum, and HTMX. And I was hoping to go in a new direction with this knowledge.
 
 Recall from my previous post the motivation for looking at SSH reverse port forwarding, in the first place: I wanted to expose services from my home network that would otherwise get blocked by NAT.
 
-This ties in with an idea I've had for a game for a while. It's supposed to run on on your computer, but is controlled remotely through the phone (or a separate browser window), with interactivity that connects and synchronizes both ends. They could be running on the same network, but maybe people use their phone on cellular data, with a wildly different [ASN](<https://en.wikipedia.org/wiki/Autonomous_system_(Internet)>) backing it up.
+This ties in with an idea I've had for a game for a while. It's supposed to run on on your computer, but is controlled remotely through the phone (or a separate browser window), with interactivity that connects and synchronizes both ends. They could be running on the same network, but maybe people use their phone on cellular data, therefore having a completely different [ASN](<https://en.wikipedia.org/wiki/Autonomous_system_(Internet)>) backing it up.
 
-If you are familiar with [WebRTC](https://en.wikipedia.org/wiki/WebRTC), you might be thinking that this isn't so different from a [TURN server](https://webrtc.org/getting-started/turn-server), and it's definitely similar! But for my project, I think that an SSH-based solution might work better:
+Well, what if you could connect your phone to your computer without worrying about NAT? What if it was as simple as accessing a web page? What if the phone interactions were as simple as touching buttons in a mobile-first webapp?
+
+If you've played any of the [Jackbox Party games](https://en.wikipedia.org/wiki/The_Jackbox_Party_Pack), you're already familiar with this kind of architecture (and it was one of the inspirations for this idea!). The only difference is that a single device will connect to the game, instead of multiple players.
+
+On the other hand, if you are familiar with [WebRTC](https://en.wikipedia.org/wiki/WebRTC), you might be thinking that this isn't so different from a [TURN server](https://webrtc.org/getting-started/turn-server), and it's definitely similar! But for my project, I think that an SSH-based solution might work better:
 
 - Setting up a new sish instance for my project is not very complicated, whereas WebRTC makes me want to pull my hair.
-- I was already planning on using HTML for the mobile interface (instead of a native app, for instance), so a hypermedia-driven library like HTMX may suit my needs better than translating the plain data that WebRTC sends.
+- I was already planning on using HTML for the mobile interface (instead of, say, [a native app](https://aws.amazon.com/compare/the-difference-between-web-apps-native-apps-and-hybrid-apps/)), so a hypermedia-driven library like HTMX may suit my needs better than translating the plain data that WebRTC sends.
   - However, it'd still require some Javascript on the mobile end of it, for things like [rollback netcode](https://en.wikipedia.org/wiki/Netcode#Rollback).
-- SSH already comes with built-in authentication and encryption mechanisms, meaning that I wouldn't have to roll out my own. (In fact, the people who are behind sish and tuns.sh leverage this – plus _forward_ TCP connections – [to create SSH tunnel-based logins for services](https://pico.sh/tunnels).)
+- SSH already comes with built-in authentication and encryption mechanisms, meaning that I wouldn't have to roll out my own. (In fact, the people behind sish and tuns.sh leverage this feature of SSH – plus _forward_ TCP connections – to create [tunnel-based logins for services](https://pico.sh/tunnels).)
+- The dependency on SSH is transparent, letting me work on the communication channel as if it were a plain webserver – or if it were any other application, for that matter. There is no lock-in to a specific technology like there is with WebRTC.
+- Since I plan on having a web interface on the mobile device anyway, this scheme avoids adding extra logic for a separate webserver. The sish proxy will only handle upgrading our HTTP connection to HTTPS essentially, and the webserver can be embedded on the computer application, similarly to a [thin client](https://en.wikipedia.org/wiki/Thin_client).
 
-TO-DO
+With that said, there's nothing inherently wrong with WebRTC though (other than it being [a complex mess of protocols](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols)), and I'm not dismissing it straight away for this project.
+
+Our chosen path still has disadvantages too, one of them being that I'd be forced to use [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) for communication. But since having a web interface on the remote controller was already part of the initial idea, that'd be unavoidable even if I picked WebRTC for the project. Another challenge is the added overhead of the proxy server, but with proper latency-based rollback, this can be mitigated – and isn't so different from what would happen with a TURN server, really.
+
+One final bonus that we get over a traditional client-server architecture is keeping the responsibilities as they should actually be. Normally, this kind of game would require a central server that coordinates with two or more clients – the computer running the game, and the mobile phone(s) running the controller. With remote port forwarding, the computer **will** be the server, exposed directly through the Internet. The mobile phone will be a regular client of that server, and there's no opaque abstraction over their communication other than HTTP itself.
+
+I've had this idea for a while now, but I was struggling to make it work with a traditional server-side architecture. It turns out that I don't need to implement anything myself. sish is configurable enough that it can serve many purposes, be it hosting multiple services, or managing multiple game connections. And for my project, it's definitely a viable solution that I'll look more into.
+
+But for now, that's all I have to say about it. I hope that this blog post has given a good insight about the inner workings of SSH, and perhaps even gave you ideas to try out yourself!

src/content/blog/taken-in-breakdown.mdx

@@ -3,7 +3,7 @@ title: "Taken In: Story breakdown!"
 pubDate: 2024-01-23
 isAgeRestricted: true
 authors: bad-manners
-thumbnail: /src/assets/thumbnails/other/taken_in_breakdown.png
+thumbnail: /src/assets/thumbnails/blog/taken_in_breakdown.png
 description: |
   First time annotating a vore story; in this case, [Taken In](/stories/taken-in). Here, I go over my writing process while offering additional tidbits of information.
 posts:

src/content/games/crossing-over.md

@@ -4,7 +4,7 @@ pubDate: 2024-02-28
 authors: bad-manners
 contentWarning: >
   This visual novel is a game about death, fishing, and vore. It contains purely fictional content deemed inappropriate for minors. It also deals with heavy subject matters like depression, abuse, and suicide, which may be unsuitable for some audiences. If you continue, you acknowledge that you're an adult, and accept responsibility for your actions.
-thumbnail: /src/assets/thumbnails/game_crossing_over_cover.png
+thumbnail: /src/assets/thumbnails/games/crossing_over_cover.png
 description: |
   [**Crossing Over**](https://bad-manners.itch.io/crossing-over) is the story of a soul and their journey towards the Hereafter. With the help of Marco, a soul ferrier, they will remember their past and fish unexpected objects out of the ethereal river.
 

src/content/stories/accommodation.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 4800
 contentWarning: >
   Contains: Non-fatal size difference anal vore, with unwilling to willing female okapi predator, unwilling to willing male gray wolf prey, and long-term endosoma. Also includes straight sexual situations.
-thumbnail: /src/assets/thumbnails/bm_5_accommodation.png
+thumbnail: /src/assets/thumbnails/stories/bm_5_accommodation.png
 description: |
   Cynthia accidentally ends up with what initially seems like a pain in the butt, but turns out to be the opposite.
 

src/content/stories/addictive-additions.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 11200
 contentWarning: >
   Contains: Non-fatal oral vore and anal vore, with willing pred and multiple consensual similar sized prey (both willing, and semi-willing to unwilling in partial vore), and implied perma endo with trait theft. Also includes consensual sexual situations (M/M, M/F), hyper, male pregnancy worship, marriage play, clothing play, and semi-public lewdness.
-thumbnail: /src/assets/thumbnails/bm_comm_1_addictive_additions.png
+thumbnail: /src/assets/thumbnails/stories/bm_comm_1_addictive_additions.png
 description: |
   A couple meets a new, kinky acquaintance at a party, who's more than happy to take control for them.
 

src/content/stories/annivoresary.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 3000
 contentWarning: >
   Contains: willing, non-fatal oral vore, with smaller male anthro fox pred, and larger male anthro wolf prey. Also includes bondage and sexual situations.
-thumbnail: /src/assets/thumbnails/bm_3_annivoresary.png
+thumbnail: /src/assets/thumbnails/stories/bm_3_annivoresary.png
 description: |
   Happy Vore Day! These two boyfriends certainly have been awaiting this date eagerly...
 posts:

src/content/stories/better-in-bully-batter.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 19100
 contentWarning: >
   Contains: Non-fatal similar size cock vore, with willing pred, multiple unwilling/semi-willing prey, and implied perma endo with trait theft. Also includes consensual sexual situations (M/M, M/F), hyper, cock sizeplay, netorare/cuckoldry and marriage play, cum inflation and weight gain, auto-fellatio, public sexual situations, and public vore.
-thumbnail: /src/assets/thumbnails/bm_comm_2_better_in_bully_batter.png
+thumbnail: /src/assets/thumbnails/stories/bm_comm_2_better_in_bully_batter.png
 description: |
   Years after graduating, a whole week to meet with former high-school classmates can lead to certain developments. Some more salacious, and others completely unexpected. And for a former bully, it happens to be both.
 

src/content/stories/big-haul.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 9100
 contentWarning: >
   Contains: Non-fatal size difference unbirth, with semi-willing trans male anthro lemur pred, and unwilling cis male anthro sergal prey. Also includes gay sex with trans and cis characters, fatfur, daddy play, implied long-term endosoma, booze, and rudeness.
-thumbnail: /src/assets/thumbnails/bm_16_big_haul.png
+thumbnail: /src/assets/thumbnails/stories/bm_16_big_haul.png
 description: |
   Coming back empty-handed from his latest heist, a space pirate ends up getting his hands on an even better haul.
 posts:

src/content/stories/birdroom.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 3000
 contentWarning: >
   Contains: non-fatal similar size anal vore, willing male feral gryphon pred, willing male anthro mimic hybrid prey, gay sex.
-thumbnail: /src/assets/thumbnails/bm_10_birdroom.png
+thumbnail: /src/assets/thumbnails/stories/bm_10_birdroom.png
 description: |
   Beetle finds an odd-shaped friend deep in his work, and does what he does best: be a messy distraction.
 

src/content/stories/bladder-filler.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 1900
 contentWarning: >
   Contains: non-fatal size difference cock vore to clean bladder, with willing male feral gryphon pred, and willing 2nd person PoV feral dragon prey. Also includes implied long-term endosoma.
-thumbnail: /src/assets/thumbnails/bm_ff_15_bladder_filler.png
+thumbnail: /src/assets/thumbnails/stories/bm_ff_15_bladder_filler.png
 description: |
   Always watch what you wish for... Blather the right thing to the right gryphon, and you might wash up in a bladder!
 

src/content/stories/bottom-of-the-food-chain.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 4500
 contentWarning: >
   Contains: Non-fatal size difference oral vore, with semi-willing male feral snake pred and semi-willing feral vole prey.
-thumbnail: /src/assets/thumbnails/bm_14_bottom_of_the_food_chain.png
+thumbnail: /src/assets/thumbnails/stories/bm_14_bottom_of_the_food_chain.png
 description: |
   A unique opportunity falls onto Muno's coils, but he's not too pleased about it...
 

src/content/stories/butting-into-their-plans.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 1400
 contentWarning: >
   Contains: first person point-of-view, non-fatal size difference anal vore, willing male feral drake pred, willing PoV ambiguous anthro prey, rimming.
-thumbnail: /src/assets/thumbnails/bm_ff_11_butting_into_their_plans.png
+thumbnail: /src/assets/thumbnails/stories/bm_ff_11_butting_into_their_plans.png
 description: |
   With other plans for tonight, a drake unwittingly ends up becoming the main attraction for someone else... Not that he'd complain.
 

src/content/stories/delicacy-s-dare.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 8000
 contentWarning: >
   Contains: Non-fatal micro oral vore, with willing male deer predator, willing to unwilling male dragon prey, and messy stomach with food digestion.
-thumbnail: /src/assets/thumbnails/bm_6_delicacy_s_dare.png
+thumbnail: /src/assets/thumbnails/stories/bm_6_delicacy_s_dare.png
 description: |
   Alqpra is willing to get his hands dirty in order to settle a score with Sonos... And a lot more than just his hands.
 

src/content/stories/eggs-for-months.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 7700
 contentWarning: >
   Contains: size difference, non-fatal sheath vore, with male feral gryphon pred and female anthro crow prey. Also includes dubious consent sex scenes, and lots of egg play and insertion (oral, cock, vaginal).
-thumbnail: /src/assets/thumbnails/bm_1_eggs_for_months.png
+thumbnail: /src/assets/thumbnails/stories/bm_1_eggs_for_months.png
 description: |
   Avelia needs help with a curse, but things quickly take a weird turn. Egg shenanigans ensue.
 posts:

src/content/stories/engaging-contacts.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 6000
 contentWarning: >
   Contains: Non-fatal size difference oral vore and unbirth, with willing female wyvern pred and multiple unwilling/semi-willing/willing female anthro prey. Also includes lesbian sex, pet play, and implied full tour.
-thumbnail: /src/assets/thumbnails/bm_11_engaging_contacts.png
+thumbnail: /src/assets/thumbnails/stories/bm_11_engaging_contacts.png
 description: |
   An innocuous message might have a more obscure purpose than it initially appears. But Sally is not the first one to make that mistake tonight...
 

src/content/stories/flavorful-favor.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 9400
 contentWarning: >
   Contains: Non-fatal oral vore, cock vore, and unbirth, with willing male gryphon predator, willing/semi-willing smaller female kobold predator/prey, and unwilling/semi-willing micro male mouse prey. Also includes full tour, prey transfer (cock to womb), and straight/gay sexual situations.
-thumbnail: /src/assets/thumbnails/bm_8_flavorful_favor.png
+thumbnail: /src/assets/thumbnails/stories/bm_8_flavorful_favor.png
 description: |
   One, fearful and furry; one, formidable and feathery; and one, fired-up for the follow-up. A threesome fatefully forced into a fantastical face-to-face.
 

src/content/stories/for-the-night.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 1500
 contentWarning: >
   Contains: non-fatal same size anal vore, willing anthro male dog pred, willing anthro female pony prey, straight anal sex, threesome, sexuality play.
-thumbnail: /src/assets/thumbnails/bm_ff_7_for_the_night.png
+thumbnail: /src/assets/thumbnails/stories/bm_ff_7_for_the_night.png
 description: |
   Sometimes, what a couple needs is a third-party to spice things up. And Brand will make sure that this night is unforgettable.
 posts:

src/content/stories/gentle-and-cruel.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 5200
 contentWarning: >
   Contains: Non-fatal size difference oral vore, with gentle male anthro badger pred, cruel monster pred, and willing to unwilling male anthro lynx prey. Also includes regurgitation, aftercare, thriller/horror scenes, and implied transformation.
-thumbnail: /src/assets/thumbnails/bm_15_gentle_and_cruel.png
+thumbnail: /src/assets/thumbnails/stories/bm_15_gentle_and_cruel.png
 description: |
   Jack celebrates a very special date with his boyfriend, but his secret might put Abdis in jeopardy...
 

src/content/stories/hate-to-sea-it.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 1200
 contentWarning: >
   Contains: non-fatal size difference unbirth, willing female feral orca pred, unwilling to semi-willing male feral dolphin prey, straight sex, hate sex.
-thumbnail: /src/assets/thumbnails/bm_ff_12_hate_to_sea_it.png
+thumbnail: /src/assets/thumbnails/stories/bm_ff_12_hate_to_sea_it.png
 description: |
   Sometimes, a date simply doesn't work out at all. And sometimes, they're both too petty and stubborn to simply give up on it.
 

src/content/stories/hungry-for-love.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 5900
 contentWarning: >
   Contains: Non-fatal size difference oral vore, with willing male spider predator, and willing female badger prey. Also includes straight sexual situations.
-thumbnail: /src/assets/thumbnails/bm_7_hungry_for_love.png
+thumbnail: /src/assets/thumbnails/stories/bm_7_hungry_for_love.png
 description: |
   Aloe has been bitten by the Valentine's Day bug, though her plans for some kinky fun go through an unforeseen change.
 posts:

src/content/stories/hyper-hunger.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 1300
 contentWarning: >
   Contains: non-fatal size difference oral vore, willing anthro ambiguous male pred, unwilling feral dog prey, food stuffing, messy stomach with smells, hyper cock, auto-fellatio.
-thumbnail: /src/assets/thumbnails/bm_ff_1_hyper_hunger.png
+thumbnail: /src/assets/thumbnails/stories/bm_ff_1_hyper_hunger.png
 description: |
   Fulfilling some hungers sometimes requires some additional, unwilling help.
 posts:

src/content/stories/insistence-and-assistance.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 1200
 contentWarning: >
   Contains: non-fatal same size oral vore, semi-willing anthro male cat pred, unwilling anthro male mouse prey, burping, regurgitation, force feeding, voyeurism.
-thumbnail: /src/assets/thumbnails/bm_ff_3_insistence_and_assistance.png
+thumbnail: /src/assets/thumbnails/stories/bm_ff_3_insistence_and_assistance.png
 description: |
   Some are predators, some are prey. And some want to keep things that way.
 posts:

src/content/stories/lactation-action.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 1400
 contentWarning: >
   Contains: non-fatal micro nipple vore and oral vore, willing anthro female ferret pred, willing anthro male brown bear prey/pred, willing/asleep anthro female seagull prey, breast play, shrinking and growing, lactation, breastfeeding, prey transfer, growing in stomach to same size, burping.
-thumbnail: /src/assets/thumbnails/bm_ff_6_lactation_action.png
+thumbnail: /src/assets/thumbnails/stories/bm_ff_6_lactation_action.png
 description: |
   Amy doesn't shirk from her friend's shrinking plans, hoping to milk as much fun as possible.
 posts:

src/content/stories/latest-catch.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 1500
 contentWarning: >
   Contains: non-fatal size difference cock vore, willing to semi-willing anthro non-binary rabbit pred, willing feral snake prey, masturbation, mouthplay, implied perma endo.
-thumbnail: /src/assets/thumbnails/bm_ff_5_latest_catch.png
+thumbnail: /src/assets/thumbnails/stories/bm_ff_5_latest_catch.png
 description: |
   A predatory rabbit likes snakes...perhaps a bit too much.
 posts:

src/content/stories/never-too-late.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 1100
 contentWarning: >
   Contains: non-fatal same size cock vore, asleep anthro male horse pred, willing anthro female aardwolf prey, masturbation, fellatio, alcohol.
-thumbnail: /src/assets/thumbnails/bm_ff_2_never_too_late.png
+thumbnail: /src/assets/thumbnails/stories/bm_ff_2_never_too_late.png
 description: |
   After a night full of fun, Mirembe tries to squeeze out the last pleasures she can.
 posts:

src/content/stories/noble-fire.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 6900
 contentWarning: >
   Contains: Non-fatal same size oral vore, with willing male anthro lion pred and semi-willing male anthro dog prey. Also includes sexual nudity and heavy themes like violence, blood, trauma, abuse, and fear.
-thumbnail: /src/assets/thumbnails/bm_12_noble_fire.png
+thumbnail: /src/assets/thumbnails/stories/bm_12_noble_fire.png
 description: |
   Blume brings his new acquaintance to his secret retreat, escaping from both the frost and the past snapping at their heels.
 

src/content/stories/overzealous-zenko.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 4900
 contentWarning: >
   Contains: Non-fatal size difference chest maw vore, with willing male kitsune-human centaur pred, unwilling female human prey, and implied perma endo.
-thumbnail: /src/assets/thumbnails/bm_r_1_overzealous_zenko.png
+thumbnail: /src/assets/thumbnails/stories/bm_r_1_overzealous_zenko.png
 description: |
   Under the pressure of following in his father's footsteps, Kuronosuke finds an unfortunate soul and offers his hospitality, whether she wants it or not.
 

src/content/stories/part-of-the-show.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 2000
 contentWarning: >
   Contains: non-fatal same size public oral vore, with willing male anthro mimic/maned wolf hybrid pred, semi-willing 2nd person PoV anthro prey. Also includes pole-dancing and mentions of alcohol.
-thumbnail: /src/assets/thumbnails/bm_ff_14_part_of_the_show.png
+thumbnail: /src/assets/thumbnails/stories/bm_ff_14_part_of_the_show.png
 description: |
   You attend a show, unaware of how personal it can turn out...
 

src/content/stories/pet-sit-saturday.md

@@ -5,7 +5,7 @@ authors: bad-manners
 wordCount: 11000
 contentWarning: >
   Contains: same size, non-fatal anal vore, with female anthro elephant pred, female anthro anteater unwilling prey, and female feral zorgoia pred/willing prey. Also includes object vore (anal), prey transfer, and masturbation.
-thumbnail: /src/assets/thumbnails/bm_2_pet_sit_saturday.png
+thumbnail: /src/assets/thumbnails/stories/bm_2_pet_sit_saturday.png
 description: |
   It's Hepje's first time pet-sitting, and a huge zorgoia might be too much for the inexperienced anteater...
 posts:

src/content/stories/playing-it-safe.md

@@ -6,7 +6,7 @@ authors: bad-manners
 wordCount: 9900
 contentWarning: >
   Contains: Size difference safe vore/endosoma (cock vore, unbirth, oral vore), with willing male anthro rhinoceros predator, willing female anthro beaver predator, and mostly willing male anthro squirrel prey. Also includes straight sex, prey transfer, condom filling with inflation and vore, implied full tour, office setting, and many puns.
-thumbnail: /src/assets/thumbnails/bm_20_playing_it_safe.png
+thumbnail: /src/assets/thumbnails/stories/bm_20_playing_it_safe.png
 description: |
   A white-collar squirrel asks his boss about a raise, but he gets far more than he bargained for.