Gap (from Andy): Completely unrelated to the catalog lane — Velm has no way to store/attach files (uploads, images, attachments) anywhere today. No multipart handlers, no blob backend, no upload surface in the repo.
What this is
A first-class file store so app records can hold attachments (documents) and images, with previews where sensible. Backed by a pluggable blob store interface so the backend can grow from filesystem to S3/object storage.
Existing precedent / constraints
- Self-hostable, open-core AGPL, Postgres-based.
- No upload handlers exist today (grep: zero
multipart/upload/blob/FileServer). This is greenfield infra.
docs-* surfaces are markdown-backed, unrelated.
Proposed shape (draft, needs Andy's call)
- Blob store interface (
Put/Get/Delete/Stat) with a filesystem-backed implementation first, S3 as an open vs closed adapter (open-core question — decide).
- Storage keying: app-scoped IDs for attachments (map to the record model). Content-addressed (sha256) only if we want cross-record dedupe — lean no for attachments, keep simple.
- Upload handler: MIME allow-list, size caps, multipart ingestion.
- Attachment field type on records (stores file reference, renders a download/preview, surfaces backlinks).
Open questions (Andy to decide)
- Files where physically? (fs vs S3-first; pluggable interface assumed)
- S3 adapter open or closed-core?
- MIME allow-list + max size defaults.
- Thumbnails/previews auto-generated (Go-side, no heavy native deps)?
Definition of done
- Blob interface + filesystem backend implemented & tested.
- Upload endpoint + attachment field type wired into records.
- Previews/thumbnails for images.
- Configurable blob store.
See session memory /space/project for the conversation that sparked this.
Gap (from Andy): Completely unrelated to the catalog lane — Velm has no way to store/attach files (uploads, images, attachments) anywhere today. No multipart handlers, no blob backend, no upload surface in the repo.
What this is
A first-class file store so app records can hold attachments (documents) and images, with previews where sensible. Backed by a pluggable blob store interface so the backend can grow from filesystem to S3/object storage.
Existing precedent / constraints
multipart/upload/blob/FileServer). This is greenfield infra.docs-*surfaces are markdown-backed, unrelated.Proposed shape (draft, needs Andy's call)
Put/Get/Delete/Stat) with a filesystem-backed implementation first, S3 as an open vs closed adapter (open-core question — decide).Open questions (Andy to decide)
Definition of done
See session memory /space/project for the conversation that sparked this.