From 1323c28c0c737e6cd64423932779bcf9dd231545 Mon Sep 17 00:00:00 2001
From: Nystik <236107-Nystik@users.noreply.gitlab.com>
Date: Thu, 9 Apr 2026 01:03:38 +0200
Subject: [PATCH] documentation adjustments

---
 README.md            | 6 ++++--
 docs/ARCHITECTURE.md | 6 +++---
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/README.md b/README.md
index c1c098e..23cc345 100644
--- a/README.md
+++ b/README.md
@@ -6,7 +6,7 @@
   <h3 align="center">Ignis</h3>
 
   <p align="center">
-    Run Obsidian in the browser. No VNC required.
+    Run Obsidian in the browser. No remote desktop required.
   </p>
 </section>
 
@@ -52,11 +52,13 @@ Ignis has **no built-in authentication**. The server is completely open by defau
 
 If you are exposing Ignis to the internet, **you should really** put an authentication layer in front of it. Options include:
 
-- A reverse proxy with basic auth (nginx, Caddy, Traefik)
+- A reverse proxy with Basic Auth (nginx, Caddy, Traefik)
 - An SSO proxy like Authelia, Authentik, or OAuth2 Proxy
 - A VPN (Tailscale, WireGuard)
 - Cloudflare Application Tunnel
 
+Example for Basic Auth, and Authelia can be found [here](examples).
+
 > [!CAUTION]
 > Do not run Ignis on a public network without auth. Anyone with the url can read and write your vault files.
 
diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md
index 01fa103..facfca5 100644
--- a/docs/ARCHITECTURE.md
+++ b/docs/ARCHITECTURE.md
@@ -24,7 +24,7 @@ The shim layer makes Obsidian think it's running in Electron. The bridge plugin
 
 ### Loading
 
-The Obsidian index file is patched to run the shim loader first. It replaces the module system and makes a blocking HTTP request to fetch the vault's directory tree into memory. The request has to be blocking because Obsidian makes synchronous filesystem calls during page load, before the event loop is running, so the cache has to already be populated.
+Obsidian's index file is intercepted during serving and the shim loader is loaded ahead of Obsidian's own scripts. It replaces the module system and makes a blocking HTTP request to fetch the vault's directory tree into memory. The request has to be blocking because Obsidian makes synchronous filesystem calls during page load, before the event loop is running, so the cache has to already be populated.
 
 ### Modules
 
@@ -49,7 +49,7 @@ Sync calls use synchronous XHR to ensure blocking behavior. Async calls use fetc
 
 ### IPC
 
-IPC is faked with a synchronous dispatcher that maps channel names to handlers.
+IPC is implemented as a synchronous dispatcher that maps channel names to handlers.
 
 ### Obsidian Plugin Compatibility
 
@@ -97,4 +97,4 @@ A basic plugin system for extending the server. Still early, the core lifecycle
 
 An Ignis plugin is a Node.js package under `server/plugins/<name>/` that exports an id, name, and a `register` function. On load it receives a context object with access to config, the WebSocket server, a file watcher, an Express router, a logger, and a persistent data directory. Plugins are enabled and disabled per vault, with state persisted in `data/plugin-config.json`.
 
-When enabled, a plugin's Express router is mounted at `/api/ext/<pluginId>/`. A plugin can also optionally bundle an Obsidian plugin, a directory containing a standard Obsidian plugin (manifest.json, main.js) that gets auto-installed into the vault on enable and removed on disable. This bridges the server and client sides: the Ignis plugin handles server logic and routes, while the bundled Obsidian plugin provides the in-app UI or behavior.
+When enabled, a plugin's Express router is mounted at `/api/ext/<pluginId>/`. A plugin can also optionally bundle an Obsidian plugin, a directory containing a standard Obsidian plugin (manifest.json, main.js) that gets auto-installed into the vault on enable and removed on disable. This bridges the server and client sides: the Ignis plugin handles server logic and routes, while the bundled Obsidian plugin provides the in-app UI or behavior.
\ No newline at end of file