Activity log for shared projects and collaboration sessions

[giswqs]

Summary

An activity log for shared projects and collaboration sessions: who opened, downloaded, forked, or changed the sharing of a project, and who joined, left, or edited during a live session.

Why

Sharing is currently write-only in the accountability sense. A project page shows a view count and a fork count — two integers — and nothing else. The owner of a shared project cannot answer any of the questions people actually ask:

• Has anyone actually opened the link I sent?
• Who downloaded the data?
• Who changed this project's visibility to public, and when? (Today, if a collaborator with write access changes sharing, nothing records it.)
• Who was in yesterday's session, and who made the edit that removed a layer?

The collaboration case is the sharpest. A session is deliberately ephemeral — presence is never persisted, chat is bounded and never written to a project — which is correct for privacy, but it means a host who returns to a mangled project has no way to see what happened. Combined with the documented limitation that a remote snapshot clears the local undo history, an unwanted change is both unattributable and unrecoverable.

Proposal

1. Project activity, on the share host

Record and expose to the owner: opens (with coarse granularity — a date and a count, not a visitor profile), raw .geolibre.json fetches, downloads, forks, version saves, ownership transfers, and every sharing change with the before/after value and the actor. Show it as an Activity tab on the project page and surface the last few entries in the Project Gallery's own-projects view.

2. Session activity, on the relay

workers/collab gains an opt-in, host-visible session log: join and leave with the participant identity the relay assigned, mode changes, per-participant permission changes, and a snapshot-accepted entry per revision with its rev and origin. The DO already persists latestSnapshot, a monotonic rev, and a bounded chat history, so a bounded log alongside them is a natural extension. Offer the host a download at session end, since the session itself is meant to disappear.

3. Privacy constraints, decided up front and documented

This feature collects data about people, so its limits belong in the design rather than in a later fix:

• Log actors and actions, not visitor fingerprints. No IP addresses beyond what is needed for abuse handling, and if any are kept, a short fixed retention.
• Bounded retention with a stated period, and owner-initiated deletion.
• Visible to the project or session owner and organization administrators; not public, and never part of the public listing.
• Anonymous opens of a public project are aggregate-only. "Someone opened this 40 times" is useful; identifying them is not the goal.
• Say in the docs what is logged. A logging feature nobody was told about is a worse outcome than no logging.

Scope notes

• Two independent halves. The share-host half needs identity to be meaningful; the relay half can use the relay-assigned clientId and works today.
• Feature-level edit attribution comes from the editor-tracking issue; this issue records project- and session-level events, and should link to rather than duplicate that.
• Coordinate with Autosave, crash recovery, and a Project History dialog #1522's project history so a user is not shown two unrelated timelines for the same project.

Effort

Medium per half.

---

Part of #1665 (access control umbrella).

[hooperjohn8]

RAG 这块切分粒度怎么定的 ⭐💡😄

[gomezrobert110]

🙌📌 版本语义化遵守得严格吗

[harrisonmichael809]

📦🚀 有没有 Docker 一键启动方案