This issue is partially related to nextcloud/notifications#2897 but with more context.
Problem
There are several scalability and UX issues in the current activity/notification model when a file is shared with large groups or updated frequently.
Scenario 1: Duplicate activity entries for group shares
If a file is shared with a team/group of 50 users, every file change creates 50 separate activity records (one per user).
This causes:
- excessive database growth,
- redundant duplicated records,
- inefficient activity storage.
A possible optimization would be to store a single activity entry for the group/share target and resolve visibility dynamically when rendering the activity stream.
However, there are some non-trivial edge cases:
- nested groups,
- users belonging to multiple groups that have access to the same file,
- preventing duplicate entries in the activity feed.
Scenario 2: Synchronous fan-out is slower than the main action
When an entity (for example, a file) is shared with many users or a large group, writing activity entries and notifications can take longer than the actual primary action (saving/updating the file) 🙈.
This becomes especially noticeable for large shares.
Would it make sense to move activity/notification fan-out into background jobs (queue-based processing), so the main user action completes faster?
Scenario 3: Excessive noise from aggressive autosave (Collabora)
With aggressive autosave settings in Collabora Online (for example every 60 seconds), each save generates:
- a new activity entry,
- a new notification for every user with access.
This creates a lot of noise and can quickly flood activity feeds and notification centers.
Possible improvements:
- rate limiting similar events,
- aggregation ("Document X was updated 15 times in the last hour"),
- debounce windows for repetitive updates.
Expected outcome
A more scalable and less noisy activity system for:
- large group shares,
- high-frequency collaborative editing,
- reduced DB pressure,
- better user experience.
Let's think/discuss together how can we improve that. I can participate in some of that improvements as well (but let's agreed on solution first)
This issue is partially related to nextcloud/notifications#2897 but with more context.
Problem
There are several scalability and UX issues in the current activity/notification model when a file is shared with large groups or updated frequently.
Scenario 1: Duplicate activity entries for group shares
If a file is shared with a team/group of 50 users, every file change creates 50 separate activity records (one per user).
This causes:
A possible optimization would be to store a single activity entry for the group/share target and resolve visibility dynamically when rendering the activity stream.
However, there are some non-trivial edge cases:
Scenario 2: Synchronous fan-out is slower than the main action
When an entity (for example, a file) is shared with many users or a large group, writing activity entries and notifications can take longer than the actual primary action (saving/updating the file) 🙈.
This becomes especially noticeable for large shares.
Would it make sense to move activity/notification fan-out into background jobs (queue-based processing), so the main user action completes faster?
Scenario 3: Excessive noise from aggressive autosave (Collabora)
With aggressive autosave settings in Collabora Online (for example every 60 seconds), each save generates:
This creates a lot of noise and can quickly flood activity feeds and notification centers.
Possible improvements:
Expected outcome
A more scalable and less noisy activity system for:
Let's think/discuss together how can we improve that. I can participate in some of that improvements as well (but let's agreed on solution first)