DMS

An image storage solution for just in time retrieval with automatic categorizers

DONE

• BASIC RUST STRUCTURE
• HTMX + TAILWIND + DAISYUI + FONTAWESOME FRONTEND STUBS
• POSTGRES + RABBITMQ COMPOSE

RUST TODO

• BINARIES

  • webservice
  • registration-token
  • queue-worker-{thumbs|ocr|categorizer|etc}

• Upload Schema

  • file_name_original / file_name_generated
  • item_name / item_description (optional)
  • user_uploaded_id
  • date_uploaded
  • date_updated
  • item_path
  • tags (as described below)
  • other relevant fields

• Functionality

  • Login/Registration
    • Registration requires an invite token generated on the backend
    • username/password for the login setup
  • Search Your Uploads
  • Uploads
    • should support both html/api
    • should be able to add tags/descriptions for searching/grouping with support for namespaced tags ex we can have an describe this image output of: “humourous image of a dog in a labcoat overlooking a chemistry set….” and have that written to namespaced tags “desc:dog desc:labcoat desc:science desc:chemistry desc:humour”
  • categorizers (as queue jobs)
    • OCR of images
    • “Describe this image” via TBD VLM API
    • find similar images via API
    • descriptions-and-ocr-extract-tags

• Tags Should be Keyed via their origin, IE summarized OCR contents should be OCR:FirstText OCR:SecondText, Users should also be able to define their own additional categories, Series:Friends Series:Cheers

SCALING

• Categorizer workers should scale horizontally as competing consumers on shared RabbitMQ queues — running N replicas of a worker binary should “just work”
• Tune per-worker prefetch count separately from replica count (OCR is CPU-bound, VLM calls are I/O-bound)
• Jobs must be idempotent — safe to re-run on the same upload after redelivery (worker crash, ack timeout, etc.)
• Bounded queues + dead-letter queue for poison messages so a single bad image can’t wedge a worker pool

ANDROIDAPP TODO

• A share intent to upload an image with optional initial tags before the automatic classificationn kicks in from a photo app / browser
• A way to search via various tags to find the correct image
• An image detail screen with the ability to click through a tag and see other items that it has attached to
• A share intent to paste the selected image into another app

Android pairing flow (server side ✅, app first slice ✅)

1. User opens /api-tokens on the web → Generate token → server renders QR encoding dms://pair?base=<server-url>&token=<api-token>
2. Android app scans the QR with its camera (zxing-android-embedded), parses the URI scheme
3. App stores (base_url, api_token) in EncryptedSharedPreferences and attaches Authorization: Bearer <token> to every API call
4. App registers an intent filter for dms://pair so opening the URI from a browser/clipboard also triggers pairing
5. Sanity-check after pairing: GET /api/profile round-trips the username — shown on a “Signed in as …” home screen
6. Logout = drop stored token (user can revoke server-side from /api-tokens separately)

Android — next slices

• Share intent → multipart upload with tag dialog ✅
• Coil thumbnails from the derived-path convention (<path>.thumb.<ext>) ✅
• Search screen (free-text + tag filter, including ns:* wildcards via the server’s parser) ✅
• Detail screen with tag chips that pivot to a tag-filtered search ✅
• Share-out: download the upload to cache, hand it to another app via FileProvider ✅
• Add tags from the detail screen (writes via new JSON POST /api/uploads/{id}/tags) ✅
• Pull-to-refresh on home + search ✅
• Pagination beyond page 1 (infinite scroll on home + search) ✅
• Upload-progress UI on share-receive ✅
• Source-toggle search UI (parity with web /search) ✅ — backed by JSON GET /api/search; results carry matched_tags rendered as suggestion chips on the result cards