Per-space shared trash, merged into the one "Deleted files" view

Cordy commented

2026-08-03 20:30:18 +00:00

Owner

Nikola's spec (2026-08-03): deleting a file inside a shared space must NOT land it in the deleting user's personal trash — it belongs to a trash inherently linked to the space, visible to everyone who can read and/or write that space. And deliberately no second trash surface in the UI: the existing "Deleted files" view shows both — your personal deletions, plus deletions from every space you have access to.

Design:

Space trash lives inside the space: deletions under /spaces/<name>/ move to /spaces/<name>/.trash/ (with the same JSON sidecar pattern as personal trash). Everything then composes for free:
- Authorization: scope already grants members access to the space subtree — read-only members see the space's trash too, per the spec ("read and/or write").
- Encryption (#18): trashed space content stays under the space path ⇒ stays on the group key. This removes the current re-key-to-deleter behaviour on space deletes (cleaner and cheaper than what v0.3.25 ships).
- Retention / legal holds / audit (#61/#63): apply unchanged, since paths never leave the space.
Trash decorator: route by path — space paths → /spaces/<name>/.trash/<id>, everything else → /.trash/<user>/<id> as today. Restore recreates within the space; purge honours retention/holds as today. Auto-purge (#77) sweeps space trashes with the same guard rails.
Listing: GET /api/v1/trash returns the union of the caller's personal trash and the trash of each space their groups grant — each entry tagged with its origin (personal / space name). The web UI's existing Deleted files view renders the origin as a small chip; restore/purge buttons work per entry (purge inside a space limited to write members? — decide: v1 proposal = write members may restore and purge, read-only members only see).
Hide /.trash within space listings in the browser the same way the root .trash is hidden (#75).

Open question for Nikola: may read-only members restore space files, or only view the trash? Proposal: restore/purge require write access; read-only sees entries only.

Works independently of #94 (self-service spaces) — applies to IdP-created spaces already today.

Nikola's spec (2026-08-03): deleting a file inside a shared space must NOT land it in the deleting user's personal trash — it belongs to a trash **inherently linked to the space**, visible to everyone who can read and/or write that space. And deliberately **no second trash surface in the UI**: the existing "Deleted files" view shows both — your personal deletions, plus deletions from every space you have access to. **Design:** - Space trash lives **inside the space**: deletions under `/spaces/<name>/` move to `/spaces/<name>/.trash/` (with the same JSON sidecar pattern as personal trash). Everything then composes for free: - **Authorization**: scope already grants members access to the space subtree — read-only members see the space's trash too, per the spec ("read and/or write"). - **Encryption (#18)**: trashed space content stays under the space path ⇒ stays on the **group key**. This *removes* the current re-key-to-deleter behaviour on space deletes (cleaner and cheaper than what v0.3.25 ships). - **Retention / legal holds / audit (#61/#63)**: apply unchanged, since paths never leave the space. - Trash decorator: route by path — space paths → `/spaces/<name>/.trash/<id>`, everything else → `/.trash/<user>/<id>` as today. Restore recreates within the space; purge honours retention/holds as today. Auto-purge (#77) sweeps space trashes with the same guard rails. - Listing: `GET /api/v1/trash` returns the union of the caller's personal trash and the trash of each space their groups grant — each entry tagged with its origin (`personal` / space name). The web UI's existing Deleted files view renders the origin as a small chip; restore/purge buttons work per entry (purge inside a space limited to write members? — decide: v1 proposal = write members may restore and purge, read-only members only see). - Hide `/.trash` within space listings in the browser the same way the root `.trash` is hidden (#75). **Open question for Nikola:** may read-only members *restore* space files, or only view the trash? Proposal: restore/purge require write access; read-only sees entries only. Works independently of #94 (self-service spaces) — applies to IdP-created spaces already today.

Cordy referenced this issue

2026-08-03 20:34:24 +00:00

Live group resolution: membership changes should apply without re-login #96

Cordy referenced this issue

2026-08-03 20:34:32 +00:00

Self-service spaces: create, own, and manage member access from the web UI #94

Cordy commented

2026-08-03 20:34:34 +00:00

Author

Owner

Decision (Nikola, 2026-08-03): read-only members see space trash entries but cannot restore or purge — "a read-only auditor does not resurrect files into the live tree; if needed they reach out to the authors in person." Restore/purge require write membership. Greenlit; building now.

**Decision (Nikola, 2026-08-03):** read-only members see space trash entries but cannot restore or purge — "a read-only auditor does not resurrect files into the live tree; if needed they reach out to the authors in person." Restore/purge require write membership. Greenlit; building now.

Cordy referenced this issue from a commit

2026-08-03 20:37:29 +00:00

feat(trash): per-space shared trash routing + membership authorization (#95)

Cordy referenced this issue from a commit

2026-08-03 20:38:49 +00:00

feat(trash): route space deletions to the space's own trash (#95)

Cordy referenced this issue from a commit

2026-08-03 20:39:25 +00:00

feat(trash): sweeper also purges space trashes with the same guard rails (#95)

Cordy referenced this issue from a commit

2026-08-03 20:40:23 +00:00

test(trash): space trash routing, visibility, authorization, sweep (#95)