Closed general

Native in-app feedback mechanism (public discussion + private log-share to gchat, linked by shared ID)

Drew Owens · 3mo ago ·closed by John Lauer

Type: Feature request · [hd-feedback]

Today, filing HD feedback means hand-authoring adom-wiki discussion posts (like this one) and manually hunting down logs on the host. We want a native, in-app feedback mechanism so any user can file a well-formed, log-backed report in a few clicks.

UX

A Feedback button in the HD UI (e.g. profile menu / Adom menu, or a toolbar affordance) opens a small form:

  • Title — free text.
  • Workspace / area — dropdown, populated from currently-open workspaces (e.g. VSCode, Wiki, plus whatever tabs are open) and always including two fixed entries: General HD and Other.
  • Comments — multi-line text field for the user's description.
  • Share logs — checkbox/toggle. When on, HD collects the relevant logs and attaches them (see privacy split below).

Where things go (privacy split)

  • Discussion item → public wiki (adom/hydrogen-desktop). Contains title, selected workspace/area, and user comments. No raw logs — logs are frequently host-path / environment-specific and shouldn't be public.
  • Logs → private Google Chat space (webhook). When "share logs" is on, HD bundles the logs (at minimum %APPDATA%\hydrogen-desktop\hydrogen-desktop.log and %LOCALAPPDATA%\inc.adom.desktop\logs\Adom Desktop.log, + build stamp / version / OS) and posts them to a dedicated gchat space via webhook. Requires: (1) create the space, (2) provision an incoming webhook, (3) store the webhook URL as an HD secret (not in the client bundle).

Linking the two

  • Each feedback submission generates a unique shared ID (e.g. HDFB-<short-uuid>).
  • That ID is written into both the public discussion body and the gchat log message, so a reviewer (or John's agent) can jump from a public report to its private logs and back. Logs stay private; only the correlation ID is public.

Provenance tag

  • Discussions created by this mechanism must carry a clear indicator that they were machine-generated by the HD feedback flow — a label/tag such as hd-feedback (and/or a footer line Filed via HD in-app feedback · HDFB-xxxx · HD vX.Y.Z). This distinguishes them from hand-written discussions and lets reviewers filter/triage them.

Implementation notes / open questions

  • Discussion creation: reuse the same adom-wiki discussion create API this post used, with --category feedback and the hd-feedback label. Confirm the wiki supports labels on create (there's a discussion triage verb for labels) so the tag is queryable, not just body text.
  • Workspace list source: HD already exposes open tabs via the control port (GET /workspace/tabs) — the dropdown can populate from that live.
  • Log collection path: the pull path used to gather logs for the current reports (adom-desktop pull_file) is a working reference; the native flow should read the same two log files directly since HD owns them.
  • Secret handling: the gchat webhook URL must live server-side / in an HD secret store, never shipped in the frontend.
  • Consent: make it explicit in the form that "share logs" sends log contents to an internal Adom gchat space (not the public wiki).

Meta

This request was itself filed by hand (Claude → adom-wiki) precisely because the native flow doesn't exist yet — it's the paper-cut this feature removes.

3 Replies

John Lauer · 2mo ago

Status (2026-08-03): still wanted, not yet built. Design as filed remains right (public discussion + private log share, linked by HDFB id). Two building blocks now exist: the wiki CLI's issue verbs with labels, and HD's log endpoints; the gchat webhook + form UI remain. Keeping open.

John Lauer · 1mo ago

Triaged with John today: fix now, and it starts with the case that hurt most this week: a new user whose setup stopped at "Wait for code-server" before they had signed in, with no way to send us anything. John's decision: no anonymous intake; users create an Adom login and report a wiki issue. So:

  1. The "Something needs fixing" card gets "Report this problem" next to Retry. Not signed in: it opens the same sign-in window ah already uses (account creation included), then continues.
  2. With a session, ah bundles the setup log, the app log tail, versions and machine facts (never the token), files an issue on adom/hydrogen through the wiki REST API from the host side (no container needed), attaches the bundle, and shows the link. The user is the reporter, so replies reach them.
  3. The same action lives in the Adom menu as "Report a problem" for anything after setup, which is this issue as you designed it. The private log share to gchat drops; the attachment on the issue covers it.
John Lauer · 1mo ago

Shipped in Hydrogen 1.0.391, verified, closing.

Three ways in, one path out:

  1. The setup card. When setup stops with an error, the card now offers "Report this problem" next to Retry. If you are not signed in yet, it opens the same sign-in the card already uses (the wiki login page offers "Create an account" and Google sign-in), and files the report the moment a session exists.
  2. The Adom menu: "Report a problem..." opens a small dialog (title, optional details, Send report) and shows the issue link when it is filed.
  3. Your AI: POST /report/problem {title?, note?} on the control API, and the UI-bus command report-problem.open.

What a report carries: an issue on this page in the reporter's name, with the last 300 KB of hydrogen-desktop.log and a diagnostics.json (health, setup state, WSL status, the Doctor's checks, build info) attached, and the last 40 log lines inline so a reader sees the failure without opening anything. It authenticates with the desktop's own session token, which the wiki accepts as a Bearer, so nothing is ever sent anonymously (John's call, no anonymous intake). The private log share to gchat from the original design is dropped; the attachment covers it.

Proof: filed a test report from arav-rog through the control route; it landed as #78 in the signed-in user's name with both attachments reachable (307 KB log tail, 10 KB diagnostics), then deleted. The dialog was opened through the UI bus and captured on screen.

report-dialog

Log in to reply.