Federated view looks nothing like the approved mockup (dogfood finding, first live OCM share) #459

Closed
opened 2026-09-09 22:03:41 +00:00 by Cordy · 1 comment
Owner

First live NC → Cairn share (2026-09-10, #454 fixed) surfaced the gap between the shipped Federated view and the approved ocm-federation-mockup.html (variants 3–6). Deltas, tab by tab:

Shares tab (mockup variant 4)

Live: plain row 📁 nextcloud.c0rdyceps.ch / 1 shared with you · 0 shared by you. Mockup: one fedcard per federation — folder glyph, mono server name, product chip ("Nextcloud"), reachable/unreachable chip right-aligned, sub-line with counts suppressing zero parts ("1 shared with you", not "· 0 shared by you") plus contact context when one exists; ordered by most recent activity.

Requests tab (mockup variant 6)

Live: plain row with text-link Accept/Decline, metadata only "Shared by Cordyborski · read". Mockup: cards with left accent border — glacier for invited-contact senders, amber with an explicit warning for non-contact senders on relaxed servers ("not an invited contact; this server is allowed with 'any user'"). The live Cordyceps-4.jpg request was exactly this case and showed no warning — the trust cue the design centres on is missing. Cards also carry: received/sent chips, remote-badge, file/folder type, relative time, real button styling, and sent-awaiting cards with Withdraw (currently absent).

Contacts tab (mockup variant 3)

Live: bare "Generate invite" text link + description + paste input with "Accept invite" text link. Mockup: two structured cards ("Invite someone on another server" with primary button; "Accept an invite you received" with input + primary button), the one-time keyblock presentation, a contacts table (Contact / Server / Established / Remove), and open invites listed with expiry + revoke.

Scope

Frontend-only (all data already served by the API; the amber case needs the contact-flag on the requests payload — verify it is exposed, else tiny API addition). i18n ×4 for new strings. The nav-dot question is deliberately split out into its own issue (bell notifications) — this issue must not reintroduce dots.

House rules: karpathy-guidelines, Superpowers, house one-shot on a branch; target already approved (mockup) so build directly, screenshots at review.

First live NC → Cairn share (2026-09-10, #454 fixed) surfaced the gap between the shipped Federated view and the approved `ocm-federation-mockup.html` (variants 3–6). Deltas, tab by tab: ## Shares tab (mockup variant 4) Live: plain row `📁 nextcloud.c0rdyceps.ch / 1 shared with you · 0 shared by you`. Mockup: one **fedcard** per federation — folder glyph, mono server name, **product chip** ("Nextcloud"), **reachable/unreachable chip** right-aligned, sub-line with counts **suppressing zero parts** ("1 shared with you", not "· 0 shared by you") plus contact context when one exists; ordered by most recent activity. ## Requests tab (mockup variant 6) Live: plain row with text-link Accept/Decline, metadata only "Shared by Cordyborski · read". Mockup: **cards with left accent border** — glacier for invited-contact senders, **amber with an explicit warning for non-contact senders on relaxed servers** ("not an invited contact; this server is allowed with 'any user'"). The live Cordyceps-4.jpg request was exactly this case and showed no warning — the trust cue the design centres on is missing. Cards also carry: received/sent chips, remote-badge, file/folder type, relative time, real button styling, and **sent-awaiting cards with Withdraw** (currently absent). ## Contacts tab (mockup variant 3) Live: bare "Generate invite" text link + description + paste input with "Accept invite" text link. Mockup: two structured cards ("Invite someone on another server" with primary button; "Accept an invite you received" with input + primary button), the one-time keyblock presentation, a **contacts table** (Contact / Server / Established / Remove), and open invites listed with expiry + revoke. ## Scope Frontend-only (all data already served by the API; the amber case needs the contact-flag on the requests payload — verify it is exposed, else tiny API addition). i18n ×4 for new strings. The nav-dot question is deliberately split out into its own issue (bell notifications) — this issue must not reintroduce dots. House rules: karpathy-guidelines, Superpowers, house one-shot on a branch; target already approved (mockup) so build directly, screenshots at review.
Author
Owner

Shipped in v0.6.146 (PR #461), live on both dogfoods. All three tabs rebuilt as the approved cards; the amber non-contact warning renders for exactly the Cordyceps-4.jpg case that exposed it (contact flag now on the payload, policy joined from the servers array); reachability chips fed by the new user-level POST /api/v1/ocm/check (allow-listed fqdns only). Nikola verifies visually on next login.

Shipped in v0.6.146 (PR #461), live on both dogfoods. All three tabs rebuilt as the approved cards; the amber non-contact warning renders for exactly the Cordyceps-4.jpg case that exposed it (contact flag now on the payload, policy joined from the servers array); reachability chips fed by the new user-level `POST /api/v1/ocm/check` (allow-listed fqdns only). Nikola verifies visually on next login.
Cordy closed this issue 2026-09-09 22:37:13 +00:00
Sign in to join this conversation.
No labels
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Cordy/Cairn#459
No description provided.