OCM sharing joins the share panel as a federated addressee

Cordy commented

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

Owner

Split out of #572 during mockup review. Peering and OCM turned out to be two intentions, not two transports: peering sends a copy (pushed, recipient's inbox, theirs from then on, not revocable, lives in Transfers); OCM shares access (an invitation the remote person comes and picks up, revocable from here, lives in My shares). #572 narrows to the send; this issue is the share.

Drawn in batch-a-572-577-598-mockup-rev2.html, blocks 4–5.

Scope

Merged, tagged picker. The share panel's recipient picker (#571) grows OCM contacts alongside local accounts and groups. Federated rows carry a warn-toned Federated tag plus the host — the tone the UI already uses for "reachable beyond this instance". Only established OCM contacts appear; no entry is invented for arbitrary hosts (#552 rule).
Boundary line before confirm. Picking a federated recipient surfaces one notice: the grant leaves this instance; the remote instance is told the share exists and fetches on open; revoking here cuts that access.
A grant like any other. Same roles (Can view / Can edit), same revocation, same audit trail. AddresseeKind grows a federated kind (or an addressee field carrying user@host) — store decision at build time.
My shares lists federated grants with a Federated badge and the host; Revoke works.
Cairn↔Cairn OCM is explicitly supported. Both acts can target the same destination host; nothing infers the act from the destination's software.

Not in scope

The peering send act (#572).
OCM server allow-list admin (exists under Federation).
Incoming OCM shares (the receiving side) — separate surface, separate issue when reached.

House rules

i18n ×4; #389 fence gate; phone treatment inherits the share panel's sheet; no competitor product names in UI copy ("OCM"/"Open Cloud Mesh" is a protocol name and fine).

Split out of #572 during mockup review. Peering and OCM turned out to be two intentions, not two transports: peering **sends a copy** (pushed, recipient's inbox, theirs from then on, not revocable, lives in Transfers); OCM **shares access** (an invitation the remote person comes and picks up, revocable from here, lives in My shares). #572 narrows to the send; this issue is the share. Drawn in `batch-a-572-577-598-mockup-rev2.html`, blocks 4–5. ## Scope - **Merged, tagged picker.** The share panel's recipient picker (#571) grows OCM contacts alongside local accounts and groups. Federated rows carry a warn-toned `Federated` tag plus the host — the tone the UI already uses for "reachable beyond this instance". Only established OCM contacts appear; no entry is invented for arbitrary hosts (#552 rule). - **Boundary line before confirm.** Picking a federated recipient surfaces one notice: the grant leaves this instance; the remote instance is told the share exists and fetches on open; revoking here cuts that access. - **A grant like any other.** Same roles (Can view / Can edit), same revocation, same audit trail. `AddresseeKind` grows a federated kind (or an addressee field carrying `user@host`) — store decision at build time. - **My shares** lists federated grants with a `Federated` badge and the host; Revoke works. - **Cairn↔Cairn OCM is explicitly supported.** Both acts can target the same destination host; nothing infers the act from the destination's software. ## Not in scope - The peering send act (#572). - OCM server allow-list admin (exists under Federation). - Incoming OCM shares (the receiving side) — separate surface, separate issue when reached. ## House rules i18n ×4; #389 fence gate; phone treatment inherits the share panel's sheet; no competitor product names in UI copy ("OCM"/"Open Cloud Mesh" is a protocol name and fine).

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

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

Cordy commented

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

Author

Owner

Mockup approved (batch A rev 2, blocks 4–5, no markup — ships as drawn): merged tagged picker, boundary notebox before confirm, federated grant in My shares with working Revoke.

Cordy referenced this issue

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

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

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

forgejo-actions referenced this issue from a commit

2026-09-18 12:43:50 +00:00

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

Cordy referenced this issue

2026-09-18 12:45:01 +00:00

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

Cordy referenced this issue from a commit

2026-09-18 12:47:36 +00:00

Merge pull request '#603: OCM sharing joins the share panel as a federated addressee' (#608) from fix-603 into main

Cordy referenced this issue

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

changelog: v0.6.217 #609

forgejo-actions referenced this issue from a commit

2026-09-18 12:48:53 +00:00

changelog: v0.6.217 (#603 federated addressee in the share panel)

Cordy referenced this issue

2026-09-18 13:00:32 +00:00

changelog: v0.6.217 (take 2) #610

Cordy commented

2026-09-18 13:09:58 +00:00

Author

Owner

Shipped in v0.6.217 (PR #608), live on both dogfoods. As approved (batch A rev 2, blocks 4–5): the recipient picker offers established OCM contacts tagged Federated with the host (pure fed-matches block — no entry invented for unknown hosts, per #552); picking one surfaces the boundary notice; Add creates the OCM share through the existing endpoint with the panel's role mapped to perms. My shares lists outbound federated shares between grants and links (host + Federated badge + role) with a working revoke via /api/v1/ocm/shares/out/{id}/end. The interim free-text "send to a federated address" row, its CSS kill-switch, handler, and dead i18n keys are gone. i18n ×4.

Not in scope, as written: the receiving side's surface, and OCM server admin. Worth a live A↔B eyeball once a second OCM-speaking instance is around (pairs naturally with #106's peering dogfood). Closing.

Shipped in **v0.6.217** (PR #608), live on both dogfoods. As approved (batch A rev 2, blocks 4–5): the recipient picker offers established OCM contacts tagged `Federated` with the host (pure `fed-matches` block — no entry invented for unknown hosts, per #552); picking one surfaces the boundary notice; Add creates the OCM share through the existing endpoint with the panel's role mapped to perms. My shares lists outbound federated shares between grants and links (host + Federated badge + role) with a working revoke via `/api/v1/ocm/shares/out/{id}/end`. The interim free-text "send to a federated address" row, its CSS kill-switch, handler, and dead i18n keys are gone. i18n ×4. Not in scope, as written: the receiving side's surface, and OCM server admin. Worth a live A↔B eyeball once a second OCM-speaking instance is around (pairs naturally with #106's peering dogfood). Closing.

Cordy closed this issue

2026-09-18 13:10:03 +00:00

Cordy referenced this issue

2026-09-18 14:43:33 +00:00

Details pane hosts the preview: the two right panes become one #615

Cordy referenced this issue from a commit

2026-09-21 01:04:15 +00:00

fix-pane4: shareKindFederated insert made conditional (#603 already ships it)

Cordy referenced this issue

2026-09-21 01:08:36 +00:00

Pane v2 sweep: scrollable body, header fixes, federated badge, dead CSS pruned #636

Cordy referenced this issue