FeedaaS

One-liner

Business-logic agnostic activity feed infrastructure. It knows about posts, follow graphs, timelines, and engagement — nothing else.

Why

Same logic as ChataaS — multiple products need social feed features, but the business semantics are entirely different. One product’s post is a match result, another’s is an event announcement, but the underlying publish, distribute, rank, and aggregate engagement layer is the same.

Completely independent from ChataaS. Chat is a conversation system (room membership, bidirectional interaction, realtime delivery). Feed is a publication system (post visibility, fan-out, timeline assembly, engagement aggregation). Similar engineering patterns don’t justify a shared service boundary — different business semantics means no coupling.

Design Principles

• FeedaaS only knows post / follow graph / timeline / engagement — not business semantics
• verb is a finite set (posted, matched, announced, shared); object_ref and metadata are opaque — the host decides how to render
• No dependency on other infra services — even when engineering patterns look similar

Core Primitives

Primitive	Responsibility
Post	Published item with verb + opaque metadata + visibility
FollowEdge	Who subscribes to whom, drives feed eligibility
TimelineEntry	Materialized projection — each viewer’s personalized timeline
Engagement	Independent interaction resource (like, repost)

Data Flow

Post write is synchronous. Timeline materialization is async (Oban fan-out worker). Home timeline reads from TimelineEntry; profile timeline reads directly from Post by actor_id.

v0 ranking is strict reverse-chronological. No recommendation engine.

Status

Skeleton stage. RFC defines the service boundary, Ash resources are in place, awaiting the first downstream consumer for validation.