Federated send moves out of the share dialog into its own act (#529, 3/3)

Cordy commented

2026-09-17 01:14:25 +00:00

Owner

Third slice of #529, and the thing #529 was originally opened for. Approved from sharing-rework-529-mockup.html rev 1.

Independent of #570 and #571 — it touches a different code path and could land in any order.

Why it is a separate act

Sending to another instance is not granting access to this file; it is transmitting a copy into a different administrative domain, where access is governed by that instance's administrators. Putting it inside a panel about who may open this file here muddles two different decisions — and it is visibly broken at 390px, with recipient field, permission select and Send competing for one row (#389).

Scope

Leaves the share panel entirely. The interim hiding already shipped; this removes it properly.
New entry from the row kebab: Send to another instance…, gated on peering or OCM being enabled and hidden when neither is.
One entry that branches by transport. Cairn Peering and Open Cloud Mesh are two transports for one user intention; two menu entries would make the user pick a protocol before picking a person. The destination select simply omits whichever transport is not configured.
Adopts the peering send pattern already built in v0.4.2–v0.4.7: recipient picker over known contacts (/api/v1/ocm/contacts exists), permission choice, and a clear failure surface for the allow-list error — which belongs in the flow on failure, not as a permanent hint.
Copy stating that a copy is transferred and governed by the destination instance.

House rules

i18n ×4; #389 fence gate; the phone treatment is a sheet, per #389. No competitor product names in UI copy.

Third slice of #529, and the thing #529 was originally opened for. Approved from `sharing-rework-529-mockup.html` rev 1. Independent of #570 and #571 — it touches a different code path and could land in any order. ## Why it is a separate act Sending to another instance is not granting access to this file; it is transmitting a copy into a different administrative domain, where access is governed by *that* instance's administrators. Putting it inside a panel about who may open this file here muddles two different decisions — and it is visibly broken at 390px, with recipient field, permission select and Send competing for one row (#389). ## Scope - **Leaves the share panel entirely.** The interim hiding already shipped; this removes it properly. - **New entry from the row kebab:** *Send to another instance…*, gated on peering or OCM being enabled and hidden when neither is. - **One entry that branches by transport.** Cairn Peering and Open Cloud Mesh are two transports for one user intention; two menu entries would make the user pick a protocol before picking a person. The destination select simply omits whichever transport is not configured. - **Adopts the peering send pattern** already built in v0.4.2–v0.4.7: recipient picker over known contacts (`/api/v1/ocm/contacts` exists), permission choice, and a clear failure surface for the allow-list error — which belongs *in the flow* on failure, not as a permanent hint. - Copy stating that a copy is transferred and governed by the destination instance. ## House rules i18n ×4; #389 fence gate; the phone treatment is a sheet, per #389. No competitor product names in UI copy.

Cordy added this to the v0.7 — Closed beta (dogfood + hardening) milestone

2026-09-17 01:14:25 +00:00

Cordy referenced this issue

2026-09-17 01:14:39 +00:00

Federated sharing UX: separate it from the share dialog and design its own flow #529

Cordy referenced this issue

2026-09-17 12:20:14 +00:00

Shares gain an addressee: store, authorisation, read path (#529, 1/3) #570

Cordy referenced this issue

2026-09-17 20:47:09 +00:00

feat(#571): share dialog — people and groups, internal link, public link #581

Cordy referenced this issue

2026-09-18 02:38:24 +00:00

Departed owners: freeze, surface, transfer (#569 implementation) #597

Cordy referenced this issue

2026-09-18 02:38:40 +00:00

Groups "Used by" gains the real share count (#529 scope addition, extracted) #598

Cordy commented

2026-09-18 10:28:20 +00:00

Author

Owner

Mockup batch A is drawn: batch-a-572-577-598-mockup.html (design folder), blocks 1–4 cover this issue — kebab entry placement + gating, the one dialog (picker open / recipient chosen), the in-flow allow-list failure, and the #389 phone sheet. One open question flagged in the file: the write-permission label, Edit their copy vs plain Edit. Build waits on markup.

Mockup batch A is drawn: `batch-a-572-577-598-mockup.html` (design folder), blocks 1–4 cover this issue — kebab entry placement + gating, the one dialog (picker open / recipient chosen), the in-flow allow-list failure, and the #389 phone sheet. One open question flagged in the file: the write-permission label, *Edit their copy* vs plain *Edit*. Build waits on markup.

Cordy commented

2026-09-18 10:51:55 +00:00

Author

Owner

Scope correction from mockup review (rev 2 drawn: batch-a-572-577-598-mockup-rev2.html).

Rev 1's premise — "Cairn Peering and OCM are two transports for one user intention" — was wrong. They are two intentions:

Peering is a send: a copy is pushed to a specific other Cairn instance's inbox and is the recipient's from then on. Not revocable; lives in Transfers.
OCM is a share: an access grant the remote person comes and picks up. Revocable from here; lives in My shares.

And since Cairn speaks OCM too, Cairn↔Cairn OCM is possible — so the destination's software can never pick the transport; only the user's intention can. One dialog that branches by transport would misfile a share as a send.

This issue narrows to the peering send act:

Kebab entry renamed "Send a copy to another instance…", gated on peering alone (feat.peerSend).
Dialog is recipient + send. The permission select is dropped — with OCM out, it has no subject: a delivered copy belongs to the recipient. (Flagged for veto in the mockup.)
In-flow failure surface stays (peer not configured / recipient unresolved / unreachable / refused).
Phone sheet per #389, simpler for it.

OCM sharing moves to a new issue: it joins the share panel as a federated addressee in the merged recipient picker (rows tagged Federated · host, boundary notice before confirm, grant revocable from My shares). Rev 2 blocks 4–5 draw it.

**Scope correction from mockup review (rev 2 drawn: `batch-a-572-577-598-mockup-rev2.html`).** Rev 1's premise — "Cairn Peering and OCM are two transports for one user intention" — was wrong. They are two intentions: - **Peering is a send**: a copy is pushed to a specific other Cairn instance's inbox and is the recipient's from then on. Not revocable; lives in Transfers. - **OCM is a share**: an access grant the remote person comes and picks up. Revocable from here; lives in My shares. And since Cairn speaks OCM too, Cairn↔Cairn OCM is possible — so the destination's software can never pick the transport; only the user's intention can. One dialog that branches by transport would misfile a share as a send. **This issue narrows to the peering send act:** - Kebab entry renamed **"Send a copy to another instance…"**, gated on peering alone (`feat.peerSend`). - Dialog is recipient + send. The permission select is dropped — with OCM out, it has no subject: a delivered copy belongs to the recipient. (Flagged for veto in the mockup.) - In-flow failure surface stays (peer not configured / recipient unresolved / unreachable / refused). - Phone sheet per #389, simpler for it. OCM sharing moves to a new issue: it joins the **share panel** as a federated addressee in the merged recipient picker (rows tagged `Federated · host`, boundary notice before confirm, grant revocable from My shares). Rev 2 blocks 4–5 draw it.

Cordy referenced this issue

2026-09-18 10:52:07 +00:00

OCM sharing joins the share panel as a federated addressee #603

Cordy commented

2026-09-18 11:34:23 +00:00

Author

Owner

Mockup approved (batch A rev 2, blocks 1–3, no markup — ships as drawn). The permission-select drop stands: the send dialog is recipient + send. Building.

forgejo-actions referenced this issue from a commit

2026-09-18 11:41:05 +00:00

#572: the peering act is 'Send a copy to another instance' and says so

Cordy referenced this issue

2026-09-18 11:41:54 +00:00

#572: peering send act — "Send a copy to another instance" #604

Cordy referenced this issue from a commit

2026-09-18 11:44:24 +00:00

Merge pull request '#572: peering send act — "Send a copy to another instance"' (#604) from fix-572 into main

forgejo-actions referenced this issue from a commit

2026-09-18 12:18:24 +00:00

changelog: v0.6.216 (#572 send-a-copy, #598 Used-by counts, #577 row chip)

Cordy referenced this issue

2026-09-18 12:18:54 +00:00

changelog: v0.6.216 #607

Cordy commented

2026-09-18 12:27:25 +00:00

Author

Owner

Shipped in v0.6.216 (PR #604), live on both dogfoods. The peering act is "Send a copy to another instance…": renamed kebab entry, dialog title/label/button reworded, governance lead line, permission select dropped, i18n ×4, guard test send-copy.test.js. The OCM half lives on as #603. Closing.

Shipped in **v0.6.216** (PR #604), live on both dogfoods. The peering act is "Send a copy to another instance…": renamed kebab entry, dialog title/label/button reworded, governance lead line, permission select dropped, i18n ×4, guard test `send-copy.test.js`. The OCM half lives on as #603. Closing.

Cordy closed this issue

2026-09-18 12:27:34 +00:00

Cordy referenced this issue

2026-09-18 12:27:39 +00:00

Federated sharing UX: separate it from the share dialog and design its own flow #529

Rows
Columns

Federated send moves out of the share dialog into its own act (#529, 3/3) #572

Why it is a separate act

Scope

House rules