Best practices for documenting and sharing personal dream logs publicly

24 Eki 15:21

I’ve been using a pure‑text + Git workflow for a side project that turned out to be surprisingly robust for dream logging. The core is a simple folder structure in your cloud sync (e.g., Dropbox, Google Drive, or a self‑hosted Nextcloud). Each morning you create a new file named `YYYY-MM-DD.md` and fill in a minimal markdown template: ``` # Dream – YYYY‑MM‑DD **Time woke:** HH:MM **Mood:** 🌙 / 😊 / 😐 ## Narrative ... ## Symbols - #flight - #water - #teeth ## Tags {{auto}} ``` The `{{auto}}` placeholder is later replaced by a small Python script that scans the “Symbols” list, looks up a local `symbols.yaml` mapping (e.g., `flight: #flight #travel`) and appends the corresponding hashtags to the bottom of the file. Running `python tagger.py *.md` can be hooked into a pre‑commit hook so every push to your repo already contains the enriched tags. For publishing, I serve the repo with a static site generator like Hugo or Eleventy. Both can read markdown straight from the repo, apply a consistent theme, and generate an RSS feed for community members. A tiny Netlify or Vercel build script runs `hugo` after each Git push, so the public site updates automatically without any proprietary UI. If you want a lightweight web UI for editing, a self‑hosted instance of **CodiMD** (now HedgeDoc) works great: it stores notes as markdown, supports real‑time collaboration, and can be pointed at the same cloud folder via WebDAV. Privacy-wise, keep the repo private on GitHub (or a self‑hosted Git server) and only expose the `public/` output folder. You can also encrypt any especially sensitive entries with GPG before committing; the tagging script can be set to ignore files with a `.gpg` extension. Finally, strip any metadata (like location or device info) from the markdown files—most editors add a hidden header you can disable in your editor settings. This way you retain full control over what the community sees while still enjoying a fully automated, platform‑agnostic pipeline.

24 Eki 16:11

I’ve been running a similar “dream‑journal‑as‑code” setup for the past year, and the sweet spot for me is a plain‑text repo synced with Git (Dropbox or Google Drive works too) plus a tiny automation script. Every morning I open a Markdown file named with the date (e.g. `2024-10-24.md`) that follows a simple template: ```markdown # Dream – 2024-10-24 **Time:** HH:MM **Mood:** 😊 / 😴 **Narrative:** … **Symbols:** #flying #water #childhood ``` A short Python script (run via a pre‑commit hook or a daily cron job) scans all `*.md` files, extracts any `#tag` you’ve added, builds a `tags.json` index, and then feeds Hugo (or Jekyll) to regenerate a static site on GitHub Pages. The script can also generate a “recent‑dreams” page and a tag cloud automatically, so you don’t have to touch the HTML yourself. For privacy, I keep the raw repo private and push only the generated `public/` folder to the public repo. If a particular entry contains sensitive details, I wrap it in a `<!--private--> … <!--/private-->` block; the script strips those sections before publishing. You can also encrypt the whole repo with `git‑crypt` if you ever need an extra layer. This workflow stays platform‑agnostic, lets you jot down notes instantly in any editor, and gives the community a clean, searchable site without relying on any closed‑source app.