Universal activity feed system with fan-out-on-read/write strategies, activity aggregation, subscriptions, and entity feeds. Build Twitter-style timelines, notification feeds, or audit logs.

nself plugin run activity-feed init
nself plugin run activity-feed server

Activities are stored once. When a user requests their feed, the system queries all subscriptions and merges activities at read time. Best for systems with few reads relative to writes, or where feeds need to be fully up-to-date.

When an activity is created, copies are pre-materialized into each subscriber's feed table (feed_user_feeds). Best for systems with many reads and fewer writes (like social media timelines).

Set via ACTIVITYFEED_STRATEGY=write or the POST /v1/fanout endpoint.

The plugin supports these predefined verbs (extensible with custom strings):

created, updated, deleted, shared, liked, commented, followed, unfollowed, mentioned, assigned, completed, approved, rejected, published, archived

Materialized feed entries for fan-out-on-write strategy.

Standard webhook event tracking table with id, source_account_id, event_type, payload (JSONB), processed, processed_at, error, created_at.

Activities with the same aggregation_key within the ACTIVITYFEED_AGGREGATION_WINDOW_MINUTES window are grouped together. For example, "Alice, Bob, and 3 others liked your post" aggregates multiple liked activities on the same object.

The aggregation key is typically constructed as {verb}:{object_type}:{object_id}.

Feed returns empty -- Verify the user has active subscriptions. For fan-out-on-read, subscriptions must exist. For fan-out-on-write, run POST /v1/fanout after creating activities.

High latency on feed reads -- Switch to fan-out-on-write strategy (ACTIVITYFEED_STRATEGY=write) if read performance is critical.

Activities not appearing in feed -- Check that the activity's actor_type/actor_id or object_type/object_id matches a subscription's target_type/target_id.