UI: send to peer, Transfers view, inbox dot, row quick actions — closes #105 #128

Merged

Cordy merged 1 commit from feat/peering-ui into main

2026-08-07 00:05:29 +00:00

Cordy commented

2026-08-07 00:04:48 +00:00

Owner

The end-user surface for peering, built to the wireframe Nikola approved, entirely inside web/static/index.html following its existing patterns.

What a user sees

Row quick actions — download and share icons directly in each file row, promoting the two most-used actions out of the ⋯ menu (they stay there too). Folders get neither; share appears only when shares are enabled. This was Nikola's addition to the wireframe.
"Send to peer" in the ⋯ menu next to Share, files only, gated on feat.peerSend. Two-field dialog: a peer dropdown fed by GET /peering/peers (which already returns only peers the caller may use, key-free) and a recipient username. Errors from the API render in the dialog; a started transfer closes it and reports via the status line.
Transfers sidebar view, modelled line-for-line on openTrashView: newest first, state chip (failed reuses the existing rochip style), failure reason, size and time. Owner-scoped by the API itself.
Inbox dot on Personal — one files?path=/home/Inbox list per minute, newest child mtime against a localStorage watermark. Viewing the Inbox clears it. No walking, no counting, per the decision.

Mechanics

feat.peerSend is set by probing GET /api/v1/peering/peers at boot: 200 → nav appears and the poll starts; 404/401 (peering unconfigured or unauthenticated) → everything stays hidden. No new server surface needed.
All strings carry EN/DE/FR/IT in the I18N table; the language-change refresh dispatch learned the transfers branch.
Fixed in passing: um-peering had two data-i18n attributes (invalid HTML, first one won — the button was mislabelled "License").
Appended <style>+<script> block rather than inline splices for the new logic; the script was syntax-checked with node --check against a stub harness before commit.

Honest limits

Not visually verified. Post-conditions and syntax checks prove structure, not layout. First real render happens on the dogfood after the next tag — worth a look before calling #105 done-done, though beta (v0.6) is the declared review point.
The send dialog's recipient is free text by design (no roster exists cross-instance); typos surface as a failed transfer with UNKNOWN_RECIPIENT in the Transfers view.
The admin-side warning about group-only receivers lists (carried on #105 from #123) is not in this PR — it belongs to the peering admin panel, not the file browser, and remains open on the issue.

12 anchored splices, all first-try; go build ./... clean.

The end-user surface for peering, built to the wireframe Nikola approved, entirely inside `web/static/index.html` following its existing patterns. ## What a user sees - **Row quick actions** — download and share icons directly in each file row, promoting the two most-used actions out of the ⋯ menu (they stay there too). Folders get neither; share appears only when shares are enabled. This was Nikola's addition to the wireframe. - **"Send to peer"** in the ⋯ menu next to Share, files only, gated on `feat.peerSend`. Two-field dialog: a peer dropdown fed by `GET /peering/peers` (which already returns only peers the caller may use, key-free) and a recipient username. Errors from the API render in the dialog; a started transfer closes it and reports via the status line. - **Transfers** sidebar view, modelled line-for-line on `openTrashView`: newest first, state chip (`failed` reuses the existing `rochip` style), failure reason, size and time. Owner-scoped by the API itself. - **Inbox dot** on Personal — one `files?path=/home/Inbox` list per minute, newest child mtime against a `localStorage` watermark. Viewing the Inbox clears it. No walking, no counting, per the decision. ## Mechanics - `feat.peerSend` is set by probing `GET /api/v1/peering/peers` at boot: 200 → nav appears and the poll starts; 404/401 (peering unconfigured or unauthenticated) → everything stays hidden. No new server surface needed. - All strings carry EN/DE/FR/IT in the `I18N` table; the language-change refresh dispatch learned the `transfers` branch. - Fixed in passing: `um-peering` had two `data-i18n` attributes (invalid HTML, first one won — the button was mislabelled "License"). - Appended `<style>`+`<script>` block rather than inline splices for the new logic; the script was syntax-checked with `node --check` against a stub harness before commit. ## Honest limits - **Not visually verified.** Post-conditions and syntax checks prove structure, not layout. First real render happens on the dogfood after the next tag — worth a look before calling #105 done-done, though beta (v0.6) is the declared review point. - The send dialog's recipient is free text by design (no roster exists cross-instance); typos surface as a failed transfer with `UNKNOWN_RECIPIENT` in the Transfers view. - The admin-side warning about group-only `receivers` lists (carried on #105 from #123) is **not** in this PR — it belongs to the peering admin panel, not the file browser, and remains open on the issue. 12 anchored splices, all first-try; `go build ./...` clean.

Cordy added 1 commit

2026-08-07 00:04:49 +00:00