Ponder

Data Flow

Verified data flows for feed, fact checking, chat, likes, search, saves, and profile state.

Feed Flow

  1. ForYouScreen watches forYouProvider.
  2. ForYouNotifier loads saved item IDs from savedItemIdsProvider, waits for profileUserProvider, and reads local feed preferences.
  3. FeedRepository.fetchDiscoverBatch queries content by discover categories, orders by publishedAt descending, and maps rows into ContentItem.
  4. feedPersonalizationSnapshotProvider merges local preferences, profile interests, and saved items.
  5. FeedPersonalizationSnapshot.prioritizeItems reranks the fetched batch client-side.
  6. RandomFeedSession manages paging, deduplication by item ID, and the next offset.
  7. User tuning actions call feedTuningProvider, which updates shared_preferences and, for signed-in users, writes feedPreferences, boostedTags, suppressedTags, and sometimes interests on the users row.

The feed stays broad: personalization changes ordering and category preference, not a hard one-topic filter.

Fact-Check Flow

  1. FactCheckScreen validates the typed claim and enforces a daily local limit in shared_preferences (fc_date, fc_count).
  2. factCheckProvider calls FactCheckRepository.checkClaim.
  3. FactCheckRepository.findFactCheck performs an exact normalized cache match against the fact_checks table after a full-text search.
  4. If no exact cache hit exists, the repository executes Appwrite Function fact_check with JSON { "claim": "...", "userId": "..." }.
  5. The function optionally checks a seven-day backend cache, calls Perplexity if needed, writes a fact_checks row when Appwrite credentials are available, and returns a structured result.
  6. The repository enriches results with related content when source URL or title match, and records signed-in history in user_fact_check_history.

Chat Flow

  1. FriendsScreen opens a ThreadScreen by calling FriendsService.getOrCreateThread.
  2. With functions configured, FriendsService executes chat_write with action getOrCreateThread.
  3. chat_write reads the current user from the Appwrite execution headers, verifies accepted friendship, finds or creates a row in threads, and returns { "thread": ... }.
  4. ThreadScreen watches threadMessagesProvider, which polls every two seconds through FriendsService.getThreadMessages.
  5. FriendsService reads thread_messages, decrypts message bodies with ThreadMessageCipher, and maps rows into ThreadMessageModel.
  6. Sending text encrypts the body client-side and executes chat_write with action postMessage; the function creates a message row and updates threads.lastMessageAt.

Realtime subscription is not used in the current thread provider; polling is explicit in threadMessagesProvider.

Article Share Flow

  1. ShareArticleSheet uses friendsListProvider to show accepted friends.
  2. FriendsService.shareArticle encrypts the optional share message.
  3. The service executes chat_write with action shareArticle.
  4. chat_write validates friendship, creates or reuses a thread, writes a shares row with participant permissions, writes a typed article message in thread_messages, and updates threads.lastMessageAt.
  5. FriendsScreen activity reads shares through receivedSharesProvider and hydrates sender/article preview data through sharePreviewProvider.

Like Sync Flow

  1. Feed article cards call LikeService.isLiked, LikeService.getLikeCount, and LikeService.setLiked.
  2. setLiked creates or deletes a row in content_likes.
  3. After the row mutation, LikeService executes Appwrite Function like_sync with { "contentId": "...", "action": "increment" | "decrement" }.
  4. like_sync reads the content row, adjusts likeCount, clamps decrements at zero, writes the updated likeCount, and returns { "success": true, "likeCount": number }.
  5. If function execution fails after a like-row mutation, LikeService attempts to roll back the row mutation.

Save And Notes Flow

  1. Article detail and feed save actions depend on saveStateProvider or savedItemIdsProvider.
  2. Signed-in saves create rows in saved_items with itemId, userId, and saveDate.
  3. Unsave deletes the matching saved_items row.
  4. Notes update saved_items.notes through SavedContentRepository.updateSavedItemNote.
  5. savedItemsProvider hydrates saved rows by reading each referenced content row.

Search Flow

  1. SearchScreen writes the current query to searchQueryProvider.
  2. Submitted searches are stored in shared_preferences under search.recent.v1.
  3. searchResultsProvider queries SearchRepository.
  4. Content search uses full-text indexes on title, summary, body_text, body, and source when possible, then falls back to recent broad scans.
  5. Fact-check search uses claim and contextBlock full-text indexes when possible.
  6. Saved-item search is available only when signed in and searches hydrated saved content plus saved notes.