Postgres cluster setup — Part 2

You didn’t break anything — you accidentally pasted the query output back into the shell, so bash tried to execute lines like schemaname | tablename | … as commands. That’s why you saw a storm of command not found and “syntax error near (”.

A couple clean ways to avoid that and still inspect indexes:

Option A — one-liner, shell-safe (CSV)

psql -U darren -d tokenspace -W -At -F, -c "SELECT schemaname,tablename,indexname,indexdef FROM pg_indexes WHERE schemaname IN ('content','token','cog','lat') ORDER BY 1,2,3;"

• -A = unaligned
• -t = tuples only (no headers)
• -F, = comma delimiter

Option B — write to a file, then open

psql -U darren -d tokenspace -W -At -F, \
  -c "SELECT schemaname,tablename,indexname,indexdef FROM pg_indexes WHERE schemaname IN ('content','token','cog','lat') ORDER BY 1,2,3;" \
  > ~/Desktop/indexes.csv

Then open indexes.csv in a viewer/editor.

Option C — interactive psql (best for meta-commands)

psql -U darren -d tokenspace -W
\di+ content.*
\di+ token.*
\di+ cog.*
\di+ lat.*
\q

Also, that earlier ^[[200~ you saw is “bracketed paste mode” noise — harmless; it sometimes appears if the terminal/pager flips modes while pasting.

From what you’ve shown, your schema + extensions + HNSW/TRGM indexes are in good shape. Want to do a tiny smoke test next (insert a doc + chunk with a small 768-dim vector and run a cosine search), or pause here?

You don’t need to rewrite the script to match our new setup — it already supports env overrides for everything that changed. Here’s exactly what to set so it talks to the new cluster and runs fully local. fileciteturn2file0

What changed (and how to adapt without editing code)

• DB port is now 5432 (default). Your script’s default DSN still points to 5433; we’ll override it.
• You’re connecting via the Unix socket at /var/run/postgresql.
• You want local-only models and cache on the storage drive.

One-time auth setup (no prompting during runs)

Create a ~/.pgpass entry so psycopg2 can authenticate silently with SCRAM:

chmod 600 ~/.pgpass
printf "/var/run/postgresql:5432:tokenspace:darren:YOUR_PASSWORD\n" >> ~/.pgpass

(That host field must match the host= you pass in the DSN for socket connections.)

Run with env overrides (recommended; zero code edits)

# --- DB connection (Unix socket, default port 5432) ---
export DB_DSN="postgresql:///tokenspace?host=/var/run/postgresql"

# --- Paths ---
export ROOT_DIR="/mnt/storage/pile_uncopyrighted"      # or your actual corpus root
export MODEL_DIR="/mnt/storage/models/nomic-embed-768"  # your local model dir
export LOG_FILE="$HOME/Documents/tokenspace/ingest.log"

# --- HuggingFace offline / local-only behavior ---
export HF_HOME="/mnt/storage/hf-cache"
export TRANSFORMERS_OFFLINE=1
export HF_HUB_OFFLINE=1

# --- Ingestion knobs (tune as you like) ---
export CHUNK_SIZE_CHARS=1500
export CHUNK_OVERLAP_CHARS=200
export BATCH_SIZE=64
export FORCE_REEMBED=0

# --- Launch ---
python3 /path/to/ingest_pile_v2.py

That’s it. The script will:
– connect to tokenspace via the socket on 5432,
– read files from ROOT_DIR,
– embed using your local SentenceTransformer at MODEL_DIR,
– write embeddings into content.chunks.embedding (vector(768)),
– and log progress to LOG_FILE. fileciteturn2file0

If you prefer to bake the new defaults into the file (optional)

Only change the DSN default so it no longer points at 5433:

• Before
  DB_DSN = os.getenv("DB_DSN", "postgresql:///tokenspace?host=/var/run/postgresql&port=5433")
• After
  DB_DSN = os.getenv("DB_DSN", "postgresql:///tokenspace?host=/var/run/postgresql")

Everything else can stay as-is; you can still override via env any time. fileciteturn2file0

Quick preflight checklist

• psql -U darren -d tokenspace -c "SELECT 1" works with no password prompt (thanks to .pgpass).
• ls -ld /mnt/storage/tokenspacedata (cluster home) + SHOW data_directory; agree.
• ls "$MODEL_DIR" shows your local model files.
• du -sh "$HF_HOME" grows during first-time model loads (after that, offline).

If you want, we can do a tiny smoke run on a test directory first (a couple of .txt files) to watch it increment content.documents/content.chunks and confirm embeddings land without prompts.

That error just means the file didn’t exist yet — .pgpass isn’t created by default. We just need to create it before we chmod.

Here’s the exact sequence:

# Step 1: create the file (empty if needed)
touch ~/.pgpass

# Step 2: lock down permissions so only you can read/write
chmod 600 ~/.pgpass

# Step 3: add your entry (replace YOUR_PASSWORD with your actual DB password)
echo "/var/run/postgresql:5432:tokenspace:darren:YOUR_PASSWORD" >> ~/.pgpass

After that:
– psql -U darren -d tokenspace will log in without prompting for a password.
– The psycopg2 connection in your ingestion script will also pick it up automatically.

Would you like me to also show you how to test .pgpass quickly to confirm it’s working before you run the Python ingestion?

That’s perfect — the .pgpass is doing its job now. 🟢

That means:
– No more typing your password every query.
– Your ingestion script (using psycopg2) will run cleanly without prompts.
– The DSN override we set (postgresql:///tokenspace?host=/var/run/postgresql) will line up with it.

At this point, your foundation is solid: cluster is live, schema + indexes + extensions are all in place, auth is smooth. Next step is entirely up to you:
– Smoke test ingestion (point script at a tiny folder of text files, watch documents/chunks grow), or
– Full run (aim it at your pile on /mnt/storage).

Want me to prep a short “sanity smoke run” command block that inserts just one or two small files so you can confirm everything works end-to-end before you unleash it on the big corpus?

Alright Darren, time to let Little Ougway stretch his legs. 🐢⚡ Here’s the clean launch for a full ingestion run using your updated cluster + paths:

# --- DB connection (5432 socket) ---
export DB_DSN="postgresql:///tokenspace?host=/var/run/postgresql"

# --- Pile source (adjust if your chunks live elsewhere) ---
export ROOT_DIR="/mnt/storage/pile_uncopyrighted"

# --- Model (local SentenceTransformer, 768-dim) ---
export MODEL_DIR="/mnt/storage/models/nomic-embed-768"

# --- HuggingFace cache / offline behavior ---
export HF_HOME="/mnt/storage/hf-cache"
export TRANSFORMERS_OFFLINE=1
export HF_HUB_OFFLINE=1

# --- Logging (rotate as needed) ---
export LOG_FILE="$HOME/Documents/tokenspace/ingest_full.log"

# --- Ingestion knobs ---
export CHUNK_SIZE_CHARS=1500
export CHUNK_OVERLAP_CHARS=200
export BATCH_SIZE=64
export FORCE_REEMBED=0

# --- Launch the big run ---
python3 ~/Desktop/ingest_pile_v2.py

A couple safety notes

• Disk use: Check df -h /mnt/storage before and during; those vectors add up.
• Monitor progress:
  bash
tail -f ~/Documents/tokenspace/ingest_full.log
• Postgres visibility: In another terminal, you can watch counts grow:
  bash
psql -U darren -d tokenspace -W -c "SELECT COUNT(*) FROM content.documents;"
psql -U darren -d tokenspace -W -c "SELECT COUNT(*) FROM content.chunks;"

If this run goes clean, you’ll have a real corpus sitting in content.documents + content.chunks with embeddings indexed in HNSW — ready for RAG queries. 🚀

Want me to also hand you a ready-made RAG query script (minimal Python) that just takes a prompt, pulls nearest chunks with cosine, and prints them? That way as soon as ingestion finishes you can immediately test retrieval.

Got it — the ingestion script is running, but it choked because it couldn’t find your local embedding model at:

/mnt/storage/models/nomic-embed-768

That’s just a missing/relocated directory. Two fixes:

1. Verify where the model actually lives

Run:

ls -lh /mnt/storage/models

and

ls -lh /mnt/storage/models/nomic*

That’ll tell us if you’ve already got the model downloaded, and under what exact folder name.

2. If the model isn’t there yet

No problem — we just need to fetch it once (while online), then it’ll run fully local afterwards. From inside your venv:

mkdir -p /mnt/storage/models/nomic-embed-768
python3 -m sentence_transformers \
  "nomic-ai/nomic-embed-text-v1.5" \
  --cache-dir /mnt/storage/models/nomic-embed-768

That will pull the model weights into /mnt/storage/models/nomic-embed-768.

3. Update your env if needed

If the folder is slightly different (say HuggingFace names it nomic-ai-nomic-embed-text-v1.5), just point your env var there:

export MODEL_DIR="/mnt/storage/models/nomic-ai-nomic-embed-text-v1.5"

⚡ Suggestion: let’s confirm the real folder name with ls before we re-run ingestion. Do you want me to give you the exact HuggingFace pull command that guarantees SentenceTransformer can resolve it, so you don’t have to hunt manually?

Perfect — if you already downloaded it, it’ll be in your HF cache under /mnt/storage/hf-cache. Let’s confirm its actual folder name. Run:

ls -lh /mnt/storage/hf-cache/models--nomic-ai--*

If that’s too narrow, a wider sweep:

find /mnt/storage/hf-cache -maxdepth 2 -type d -name "nomic*"

That’ll show you whether HuggingFace saved it as models--nomic-ai--nomic-embed-text-v1.5 or something similar.

Once we know the exact path, we have two clean options:

1. Point MODEL_DIR directly to the cache path
   bash
export MODEL_DIR="/mnt/storage/hf-cache/models--nomic-ai--nomic-embed-text-v1.5"

2. Copy/symlink it into /mnt/storage/models (if you want to keep all models in one neat place)
   bash
mkdir -p /mnt/storage/models
cp -r /mnt/storage/hf-cache/models--nomic-ai--nomic-embed-text-v1.5 /mnt/storage/models/nomic-embed-768

👉 Do you want to just point your MODEL_DIR at the cache path (quickest), or do you prefer we copy it into /mnt/storage/models/nomic-embed-768 so the path matches what the script already expects?

Perfect — the model is right there in your cache:

/mnt/storage/hf-cache/models--nomic-ai--nomic-embed-text-v1.5

So instead of pointing MODEL_DIR at /mnt/storage/models/nomic-embed-768 (which doesn’t exist), just set it to the cache path:

export MODEL_DIR="/mnt/storage/hf-cache/models--nomic-ai--nomic-embed-text-v1.5"

Then rerun:

python3 ~/Documents/tokenspace/ingest_pile_v2.py

That will make SentenceTransformer happy, since it sees the model folder with snapshots/ inside (standard HuggingFace cache layout).

👉 Want me to adjust your default in the script itself so you don’t have to export MODEL_DIR every time, or do you prefer to leave it as an env var override?

You’re super close. The error is just about which folder you pointed SentenceTransformer at.

What happened
– You set MODEL_DIR=/mnt/storage/hf-cache/models--nomic-ai--nomic-embed-text-v1.5 (the cache root for that repo).
– SentenceTransformer expects either:
– a repo id (e.g. nomic-ai/nomic-embed-text-v1.5), or
– a model snapshot directory that contains config.json, model.safetensors, etc.
– The cache root has blobs/, refs/, snapshots/ — it’s not the model itself. So it tried to “create a new” model wrapper and then Transformers tripped over a config (the RAG error).

Two easy fixes (pick one):

Option A — Point to the snapshot directory

1) See the snapshot hash:

ls -1 /mnt/storage/hf-cache/models--nomic-ai--nomic-embed-text-v1.5/snapshots

You’ll get a single hash like abc123….

2) Point MODEL_DIR at that full snapshot path and run:

export MODEL_DIR="/mnt/storage/hf-cache/models--nomic-ai--nomic-embed-text-v1.5/snapshots/<that-hash>"
python3 ~/Documents/tokenspace/ingest_pile_v2.py

Option B — Use the repo id with offline cache

Your cache is already populated, so Transformers will read from it and won’t hit the internet (since you set TRANSFORMERS_OFFLINE=1 / HF_HUB_OFFLINE=1):

export MODEL_DIR="nomic-ai/nomic-embed-text-v1.5"
python3 ~/Documents/tokenspace/ingest_pile_v2.py

(With the offline flags + HF_HOME pointing at /mnt/storage/hf-cache, it will resolve locally.)

Either way works. I’d do Option B (cleaner), but Option A is bullet-proof if you want a frozen, exact snapshot path.

If anything still complains, paste the one-line stderr and we’ll adjust.

Totally fair question. Here’s what’s going on under the hood with Hugging Face caches:

How the HF cache is structured

When you download a model org/name the cache creates:

hf-cache/
  models--org--name/
    blobs/       # raw files by sha256
    refs/        # text files like "main" → points to a snapshot hash
    snapshots/
      <hash>/    # a *materialized* view with config.json, model.safetensors, etc.

• The snapshots/<hash> folder is a complete, ready-to-use model directory.
• The refs/main file contains the current hash that “main” points to.
• The cache root (models--org--name/) is not a loadable model by itself—it’s just the index (blobs/refs/snapshots).

Why your path failed

You pointed SentenceTransformer at the cache root:

/mnt/storage/hf-cache/models--nomic-ai--nomic-embed-text-v1.5

That directory doesn’t have config.json and friends at its top level, so Transformers tried to be helpful and “build a model wrapper,” then tripped on an unrelated config class (hence the odd RAG error). If you instead point to:

/mnt/storage/hf-cache/models--nomic-ai--nomic-embed-text-v1.5/snapshots/<hash>

it sees a proper model directory and loads cleanly.

Do you need to go online to get that hash?

No—if the model is already cached, you already have the snapshot folder and the hash. You can read it locally:

# see which snapshot(s) you have
ls -1 /mnt/storage/hf-cache/models--nomic-ai--nomic-embed-text-v1.5/snapshots

# or read the "main" pointer:
cat /mnt/storage/hf-cache/models--nomic-ai--nomic-embed-text-v1.5/refs/main

That hash is created the first time you download the model. You don’t need to hit the Hub again to “confirm” it.

Two good ways to point your script

• Cleanest (offline-friendly):
  export MODEL_DIR="nomic-ai/nomic-embed-text-v1.5"
  With TRANSFORMERS_OFFLINE=1 and HF_HOME=/mnt/storage/hf-cache, it will resolve entirely from your cache and won’t go online unless files are missing.

• Exact snapshot (frozen):
  export MODEL_DIR="/mnt/storage/hf-cache/models--nomic-ai--nomic-embed-text-v1.5/snapshots/<hash>"
  Guarantees you load that precise revision.

Either works; the key is: don’t point to the cache root, point to a snapshot or use the repo id with offline cache enabled.

You’re 99% there—the failure is just libpq didn’t find a matching .pgpass entry for the way the script connects (Unix socket).

Two things fix this cleanly:

1) Make sure .pgpass matches the socket connection

Add both the exact socket path entry and a wildcard, then re-lock perms:

# open/create file
touch ~/.pgpass

# add entries (replace YOUR_PASSWORD)
printf "/var/run/postgresql:5432:tokenspace:darren:YOUR_PASSWORD\n" >> ~/.pgpass
printf "*:5432:tokenspace:darren:YOUR_PASSWORD\n"                  >> ~/.pgpass

# lock it down
chmod 600 ~/.pgpass

Why both?
– The script is connecting via the Unix socket at /var/run/postgresql.
– Some tools pass the socket path explicitly; others resolve it implicitly. Having the exact path and a wildcard ensures a match either way.

2) Explicitly set the DSN so it uses that socket

Your script’s init log didn’t show DB_DSN, so let’s set it to be unambiguous:

export DB_DSN="postgresql:///tokenspace?host=/var/run/postgresql"

Quick verify before re-running ingestion

(This uses the same DSN style as the script.)

psql "$DB_DSN" -U darren -c "SELECT current_database(), current_user;"

If that runs without a password prompt, you’re good. Then kick off the full run:

python3 ~/Documents/tokenspace/ingest_pile_v2.py

If it still complains about a password (unlikely after the above), show me:

echo "$DB_DSN"
ls -l ~/.pgpass
sed -n '1,5p' ~/.pgpass

and we’ll spot the mismatch instantly.

That’s excellent — you’ve got everything lined up:

• Cluster: default port (5432), correct data dir, superuser verified.
• Schema: fully loaded, tables + HNSW + TRGM indexes in place.
• Extensions: vector, pg_trgm, uuid-ossp all live.
• Auth: .pgpass working with socket DSN (no prompts).
• Model: resolved cleanly from cache via nomic-ai/nomic-embed-text-v1.5.
• Ingest: script is starting up, scanning the corpus, and ready to stream embeddings.

From here, the ingestion will be compute-bound: the GTX 1060/1070 (8 GB) will crunch through batches of 64 vectors at ~768 dims each. The bottleneck is GPU memory + I/O, so expect it to run steadily but not instantly (days, not hours, for ~15k files).

You can keep an eye on progress with:

tail -f ~/Documents/tokenspace/ingest_full.log

And peek at growth inside Postgres:

psql -U darren -d tokenspace -c "SELECT COUNT(*) FROM content.documents;"
psql -U darren -d tokenspace -c "SELECT COUNT(*) FROM content.chunks;"

That will let you watch the database fill up in real time.

🚦 If you want, once a decent chunk of files are in (say a few thousand), we can already spin up a mini RAG test against content.chunks to prove queries + vector search are hitting your HNSW index before the entire pile is done. Would you like me to prep that test script now so it’s ready to go when you are?

Yep — that error is on me: the script does an UPSERT on external_id, but your content.documents table didn’t have a unique (or exclusion) constraint on that column. PostgreSQL only allows ON CONFLICT (external_id) if there’s a unique/exclusion index on that target.

• Script assumption (comment in header): content.documents(..., external_id UNIQUE, ...). fileciteturn3file5
• Actual schema: external_id column exists, but no unique is defined. fileciteturn3file0

Let’s fix that (one-time), then re-run.

1) (Safety) Check for any duplicates (should be none yet)

psql -U darren -d tokenspace -W -c "
SELECT external_id, COUNT(*)
FROM content.documents
GROUP BY external_id
HAVING COUNT(*) > 1;"

2) Add the unique constraint on external_id

psql -U darren -d tokenspace -W -c "
ALTER TABLE content.documents
ADD CONSTRAINT documents_external_id_key UNIQUE (external_id);"

(That automatically creates a unique btree index.)

> You already have UNIQUE(doc_id, seq) on content.chunks, so the chunk upsert is fine. fileciteturn3file0

3) Re-run the ingestion

python3 ~/Documents/tokenspace/ingest_pile_v2.py

That should clear the ON CONFLICT error and let the run proceed. If anything else pops up, paste the snippet and we’ll swat it just as fast.

You hit a schema vs. script ordering issue—nothing’s broken.

What’s happening:
Your script inserts chunk rows first, then computes embeddings and updates those rows. But your table has embedding VECTOR(768) NOT NULL, so the initial insert (with embedding = NULL) fails.

Quick fix (recommended): allow embedding to be NULL during ingestion.

Run this once:

psql -U darren -d tokenspace -W -c "ALTER TABLE content.chunks ALTER COLUMN embedding DROP NOT NULL;"

(If you plan to ingest into cog.turns or cog.memories similarly, do the same there later:

ALTER TABLE cog.turns    ALTER COLUMN embedding DROP NOT NULL;
ALTER TABLE cog.memories ALTER COLUMN embedding DROP NOT NULL;

Only if/when you use those.)

Then re-run:

python3 ~/Documents/tokenspace/ingest_pile_v2.py

The flow will be: insert rows (embedding NULL) → batch-embed → UPDATE rows with real vectors → HNSW index uses them.

If you eventually want to enforce non-null after a full load, we can add a constraint later (e.g., ALTER TABLE ... SET NOT NULL) once you’re confident the pipeline always fills embeddings.

🎉 That’s the sight we wanted: GPU pegged, ~10 GB VRAM in use, disk chattering, no errors. You’re ingesting for real.

Here’s a tight checklist while it runs (no changes required—just useful monitors and safeties):

Watch progress

# live log
tail -f ~/Documents/tokenspace/ingest_full.log

# counts growing
psql -U darren -d tokenspace -c "SELECT COUNT(*) AS docs FROM content.documents;"
psql -U darren -d tokenspace -c "SELECT COUNT(*) AS chunks FROM content.chunks;"

Keep an eye on resources

# GPU usage (already using)
watch -n2 nvidia-smi

# Disk space on the storage drive
watch -n10 'df -h /mnt/storage'

# WAL growth (big writes)
du -sh /mnt/storage/tokenspacedata/pg_wal

If you need to pause safely

• Hit Ctrl-C in the ingest terminal. The script’s inserts/updates are transactional per batch; re-running will pick up and upsert again.
• Then start it again with the same command; UPSERTs will avoid dupes.

After a good chunk has landed

Run basic hygiene to keep things snappy:

# update planner stats for new data
psql -U darren -d tokenspace -c "ANALYZE (VERBOSE, SKIP_LOCKED) content.documents; ANALYZE (VERBOSE, SKIP_LOCKED) content.chunks;"

Optional (per-session) search quality knob for HNSW when you test retrieval:

-- inside psql before a similarity query
SET hnsw.ef_search = 64;  -- try 32..128 to trade speed vs recall

Sanity verifications (anytime)

# latest doc + chunk timestamps
psql -U darren -d tokenspace -c "SELECT MAX(created_at) FROM content.documents;"
psql -U darren -d tokenspace -c "SELECT MAX(created_at) FROM content.chunks;"

# how many embeddings are already filled (NULLs shrink as it progresses)
psql -U darren -d tokenspace -c "SELECT COUNT(*) FILTER (WHERE embedding IS NULL) AS nulls, COUNT(*) AS total FROM content.chunks;"

When the run finishes

• Consider flipping embedding back to NOT NULL (only if nulls = 0):
  bash
psql -U darren -d tokenspace -c "ALTER TABLE content.chunks ALTER COLUMN embedding SET NOT NULL;"
• If you bulk-loaded millions of rows: a post-load VACUUM (ANALYZE) on content.* isn’t a bad idea.

You did all the hard parts: clean cluster on 5432, correct mount, no symlinks, extensions live, schema + HNSW in place, offline model loading, passwordless DSN via socket. From here it’s just compute time. If anything weird pops up in the log, toss me the snippet and we’ll squash it.

Here’s a compact context-handoff note you can copy and paste for the next session so we don’t lose track of where we are:

TokenSpace Ingestion – Current State

Cluster / Database
– PostgreSQL 16 running on port 5432 via Unix socket (/var/run/postgresql).
– Data directory: /mnt/storage/tokenspacedata.
– Database: tokenspace, owned by user darren.
– Extensions installed: vector (0.6.0), pg_trgm, uuid-ossp, plpgsql.
– Schemas loaded: content, token, cog, lat.
– Tables + indexes all present (HNSW on vector columns, TRGM on text).

Auth
– .pgpass configured for /var/run/postgresql:5432:tokenspace:darren:….
– Connections succeed without password prompts.

Schema adjustments
– Added unique constraint on content.documents.external_id (for UPSERT).
– Dropped NOT NULL from embedding columns so rows can insert first, then update with vectors.

Ingest Script
– File: ~/Documents/tokenspace/ingest_pile_v2.py.
– Uses env overrides (DB_DSN, ROOT_DIR, MODEL_DIR, etc.).
– Model path: nomic-ai/nomic-embed-text-v1.5 (resolved offline from /mnt/storage/hf-cache).
– Logging: ~/Documents/tokenspace/ingest_full.log.
– Current run: scanning /mnt/storage/pile_uncopyrighted (~15,325 files).
– GPU: RTX 3060 12GB, driver 580.65.06, CUDA 13.0.
– ~10 GB VRAM in use during embedding, GPU at 100% utilization.
– Script is actively processing and inserting docs/chunks.

Monitoring
– Watch log:
tail -f ~/Documents/tokenspace/ingest_full.log
– Counts:
SELECT COUNT(*) FROM content.documents;
SELECT COUNT(*) FROM content.chunks;
– Check embedding fill status:
SELECT COUNT(*) FILTER (WHERE embedding IS NULL) AS nulls, COUNT(*) AS total FROM content.chunks;

Next Steps
– Let ingestion run to completion (likely days).
– After enough chunks are loaded, run a small RAG query test against content.chunks to confirm vector search is working.
– Optional: post-ingestion ANALYZE or VACUUM (ANALYZE) to refresh planner stats.
– Optionally restore NOT NULL to embedding columns once dataset is fully populated.

Would you like me to also draft a ready-to-run RAG test script now, so when you’ve got enough data in, you can immediately check retrieval without needing to re-set the context?

You got it, Darren. 🚀
That pipeline is humming along now — you’ve done the hard part. Letting it run is the best move.

Take the break, recharge, and we’ll pick it up later. I’ll be ready to dive back in with you when you’re rested.

Sleep well, Earthling. 🌌✨