From 5c9034c861458094939f194588eb04494a148967 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 4 May 2026 21:49:08 +0000 Subject: [PATCH] Resolve Q16/Q17: media_uri at source, Immich out-of-band MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Q16 → image bytes stay in their source (Memos / Nextcloud / Obsidian); Phase-3.2 backfill fetches by media_uri. Zero copy. - Q17 → Immich stays out-of-band; Nexa does not call Immich's smart-search. - New Q18 carries forward the unresolved sub-question of whether SAIA's LiteLLM gateway already proxies an embedding model — a 1-line check that could let us skip TEI in 3.1. --- docs/11-open-questions.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/11-open-questions.md b/docs/11-open-questions.md index 03eca23..7d60c48 100644 --- a/docs/11-open-questions.md +++ b/docs/11-open-questions.md @@ -16,10 +16,9 @@ Items that **block progress** and need a human decision before a workflow can be - [ ] **Q4 — Obsidian sync mechanism.** `system_prime.txt` references Obsidian Context, but the current setup syncs via Nextcloud (`nc.nuclide.systems` → `Notizen` folder, ~200 MB). Should Nexa watch the **filesystem on LXC 105** (NC data dir) or **the Nextcloud WebDAV API**? FS is cheaper, WebDAV is portable. - [ ] **Q5 — Karakeep vs. Hoarder naming.** Zoraxy host is `hoarder.nuclide.systems` but containers are `karakeep-*` and Homepage labels it Karakeep. Same product (rename 2024). Pick one display name for docs and prompts. -- [ ] **Q16 — Image-attachment queue ergonomics (Phase 3.2).** The agreed plan is: in 3.1 we record images as `nexa:Note` with `nexa:pendingVisualIndex true` but don't embed them. Open sub-questions for when 3.2 lands: - - Where to store image bytes between capture and indexing? Three options: (a) leave them in their source (Memos attachments dir / Nextcloud / Obsidian), reference by `media_uri`; (b) copy to a staging area on the docker host; (c) push to `s3.nuclide.systems` immediately. **Recommendation: (a)** — zero copy, smallest blast radius. - - Does SAIA already proxy any embedding model? If the SAIA backend offers e.g. `mistral-embed` we could simplify 3.1 by skipping TEI. Worth a 1-line check in the LiteLLM admin UI. -- [ ] **Q17 — Reuse Immich's CLIP for photo-library queries?** Immich already runs CLIP server-side on the photo library. For images that live *in Immich*, querying its smart-search API is cheaper than re-embedding. Is the Immich API key OK to add to the n8n workflow, or do we treat Immich as out-of-band? +- [x] **Q16 — Image-attachment queue ergonomics → leave bytes at source, reference by `media_uri`.** Zero copy. Memos attachments stay in Memos's data dir, Nextcloud images stay in Nextcloud, Obsidian images stay in the `Notizen` folder; the Phase-3.2 backfill workflow fetches them on demand via the URI scheme. Sub-question on whether SAIA already proxies an embedding model is still worth a 1-line check in the LiteLLM admin UI before deploying TEI — moved to Q18. +- [x] **Q17 — Immich out-of-band.** Nexa does not call the Immich smart-search API. Photo-library queries stay inside Immich; if a Nexa workflow ever needs photo context it will go through a Memos-mediated handoff rather than a direct API. +- [ ] **Q18 — Does SAIA already proxy an embedding model?** 1-line check in the LiteLLM admin UI: list models on the Nexa virtual key. If the SAIA backend offers e.g. `mistral-embed`, we can skip TEI in Phase 3.1 entirely. If not, deploy TEI as planned. ## Identifiers needed (auto-discoverable, but list now if known)