Legacy Feedback Worker

This document records the network feedback system that existed before Niamoto switched to local diagnostic report generation. The legacy system is kept here only as restoration context. The active application no longer depends on a Cloudflare Worker, R2 bucket, GitHub token, or feedback API key.

Current Active Behavior

The app now generates a local Markdown diagnostic report from the feedback modal. The report is designed to be readable by a user and copyable into a GitHub issue. The report includes:

  • feedback type, title, and optional description

  • redacted app context

  • recent console errors, failed API requests, navigation history, crashes, and local state snapshot when available

  • optional screenshot embedded as a data URL

No network request is made to submit feedback, and the FastAPI app does not register /api/feedback/submit.

Legacy Architecture

The previous flow had three parts:

  1. React collected the feedback payload and screenshot.

  2. FastAPI exposed POST /api/feedback/submit and relayed the multipart body to a configured public endpoint.

  3. The Cloudflare Worker uploaded an optional screenshot to R2 and created a GitHub issue. Its source used to live under workers/niamoto-feedback-proxy/.

The worker source was removed from the active repository cleanup after commit 200e7e95. Restore it from Git history only if the network feedback flow is explicitly brought back.

The worker expected:

  • POST /feedback

  • multipart field payload, containing JSON

  • optional multipart field screenshot, normally image/jpeg

  • header X-Feedback-Key

The worker bindings and secrets were:

  • FEEDBACK_BUCKET: R2 bucket for screenshots

  • R2_PUBLIC_URL: public base URL for uploaded screenshots

  • GITHUB_REPO: target repository, for example owner/repo

  • GITHUB_TOKEN: GitHub token allowed to create issues

  • FEEDBACK_API_KEY: shared secret compared with X-Feedback-Key

The app-side build/runtime variables were:

  • NIAMOTO_FEEDBACK_WORKER_URL

  • NIAMOTO_FEEDBACK_API_KEY

  • legacy aliases: FEEDBACK_WORKER_URL, FEEDBACK_API_KEY, VITE_FEEDBACK_WORKER_URL, VITE_FEEDBACK_API_KEY

Legacy Security Model

The old FastAPI proxy existed so the frontend never exposed GitHub or R2 credentials. It also:

  • rejected missing feedback configuration

  • rejected private or invalid feedback endpoint URLs

  • revalidated DNS immediately before forwarding

  • pinned the resolved public addresses during the outbound request

  • limited screenshots before forwarding them

The worker then validated the shared X-Feedback-Key before touching R2 or GitHub.

Restoration Checklist

Only restore this system if a maintained public relay exists. Do not point released builds at personal infrastructure.

To restore the legacy network flow:

  1. Restore the worker source from Git history, for example:

    git restore --source 200e7e95 -- workers/niamoto-feedback-proxy

  2. Reintroduce the FastAPI feedback router at src/niamoto/gui/api/routers/feedback.py from Git history before the local report migration.

  3. Register it in src/niamoto/gui/api/app.py with:

    app.include_router(feedback.router, prefix="/api/feedback", tags=["feedback"])

  4. Change src/niamoto/gui/ui/src/features/feedback/lib/feedback-api.ts back to posting FormData to /api/feedback/submit.

  5. Restore the Tauri build/runtime forwarding if packaged desktop builds should embed or pass feedback worker settings.

  6. Configure a maintained worker-compatible service and secrets:

    NIAMOTO_FEEDBACK_WORKER_URL=https://example-feedback-relay.example
NIAMOTO_FEEDBACK_API_KEY=...

  7. Keep the frontend from sending worker URLs or API keys in form fields. The backend should read trusted configuration from its environment only.

  8. Restore or recreate tests covering:

    • frontend posts only to /api/feedback/submit

    • frontend does not send worker config or secrets

    • backend rejects missing config

    • backend rejects private feedback endpoints

    • backend forwards screenshot and payload to /feedback

    • worker rejects bad X-Feedback-Key

    • worker creates GitHub issues and handles R2 failures without losing the feedback body

Preferred Future Alternative

If someone wants shared feedback collection later, prefer a neutral, project-owned endpoint with clear maintainers and documented credentials. The local report flow should remain available as a no-infrastructure fallback.