# Riff Feed social and profile porting guide

**Source boundary (2026-10-12):** This describes the checked local source and the public Riff Feed audit in `audits/creator-onboarding-20261012/RAJEEV_PORT_AUDIT.md` at the parent project root. It is an integration guide, not a claim that any Riff Feed applet was published, claimed, or tested with a real account. The Vercel service's private source and like database were unavailable.

## What the current host provides

| Concern | Current contract | What it proves |
| --- | --- | --- |
| Account favorites | First-party `/feed` reads and writes `/api/identity/favorites` for a signed-in account. Guests use a bounded browser-local list. | A private saved item for that account or browser. There is no public count. |
| Share | First-party `/feed` prepares an exact-version canonical link, then offers native share, clipboard, and selectable URL paths. | A link was prepared or an outcome was observed. Native return and copy do not prove recipient delivery. |
| App profile | Optional SDK 1.8 `runtime.profile.get()` or `createProfileClient().get()` returns a bounded family-scoped projection, or `{available:false}`. | A user preference/name suggestion for this app family, not creator ownership. Avatar is `null`. |
| Creator identity | `/api/creator-account` scopes submissions and usage to an authenticated owner or validated read-only creator capability. | Ownership comes from the explicit account claim/registration and family records, never a feed label or username. |
| Creator usage | `creatorUsage()` reads `identity_activity_daily` only for owned uploaded family IDs. | Advisory play/preview heartbeats and active time, with partial coverage. No likes or shares. |
| Analytics social events | `like-changed`, `share-attempt`, and `share-result` have schemas and an internal-test collector. The `/feed` bridge requires exact curated version and commit. | Test-observed actions where that collector is enabled. This is not a production creator social service. |

`/feed-test` browser likes and displayed glass statistics are illustrative and are not an integration source. The Riff Feed Vercel `/api/feed` contract belongs to that separate service; no app package should call it from the isolated RCF runtime.

## Applet integration recipe for Rajeev

1. Intake each of the 20 applets as a distinct candidate with authorized source, exact commit, license, title, slug, media, and intended revision. The two existing `/feed-test` ports are prototypes and omit their original social backends. Do not derive ownership from the public `Riff Lab` display label. Use the platform's explicit creator account claim or registration before assigning ownership or edit access.
2. Keep gameplay and local like state usable for a guest. The first-party `/feed` heart is a private favorite: signed-in changes call `/api/identity/favorites`; guest changes stay in local storage, with an in-memory fallback. Applets cannot reach that account endpoint from their isolated runtime. If an applet needs its own heart, label it as local until a reviewed host service exists. Do not equate a favorite with a like event or expose anyone's saved list to a creator.
3. Construct public links with the RCF canonical version/share helpers (`shared/share-links.js` and the host's `feedMainShareURL`/`createCompactLink` path). Preserve the applet's bounded declared content state and parent/revision lineage. Use native share where offered, with clipboard and selectable URL fallbacks. Report copied links, native share returns, manual copies, cancellation, and failure separately; never call these delivered shares or unique recipients.
4. Read `runtime.profile.get()` asynchronously only when a preference helps the applet. Begin usable play before it resolves; apply a username only to an unset field or on explicit user choice, use text insertion, and respect current choices and saved app state. Handle `{available:false}`, timeout and late responses. The profile has no creator credential, global account ID, email, or avatar support. Names and public scores require separate consent.
5. For a creator view, authorize with exact `creator_id` from the owner session or validated dashboard capability, then join uploaded records by `COALESCE(riff_contributions.family_id, riff_contributions.id)`. A slug is a display label, not an access key. Existing `creatorUsage()` already enforces this pattern for play/preview usage. A curated app needs a separately verified curated-family ownership assignment before its data appears under a creator.

## Social stats gap and minimum safe service boundary

There is presently **no trustworthy creator-scoped like/share aggregate** for uploaded families. `identity_favorites.app_id` is a feed key and its rows are private account data; it is neither an owned-family key nor a public popularity table. `riff_analytics_events.app_id` uses curated release IDs and the current bootstrap only installs in `internal-test` mode. Uploaded `/feed` cards deliberately have no social analytics context. Joining either store to a creator by similar slug, title, label, or account email would disclose or misattribute data. Returning `0` for these missing metrics would falsely imply complete measurement; the dashboard should omit them or say “unavailable.”

The remaining production social-stats work is to add a versioned first-party host contract with these boundaries before any UI counter: exact uploaded family and submission identity from a trusted launch; server-derived owner scope; bounded and deduplicated event IDs; explicit guest/account merge rules; separate current-like state and event counts; retention and abuse limits; opt-out/coverage semantics; and a creator aggregate that returns only owned-family totals. Keep private favorite rows out of that aggregate. Distinguish likes, unlikes, share attempts, native returns, clipboard/manual copies, and recipient opens. Recipient delivery cannot be inferred from a share result. No new SDK capability or public count is activated by this guide.

## Narrow source references

- `shell/feed.js`: account favorites, guest fallback, exact share path, and curated-only social context.
- `server/identity/api.js` and `migrations/0025_identity.sql`: private favorite API/table.
- `shared/analytics-contract.js`, `shared/analytics-bootstrap.js`, `shared/analytics-config.js`, `shared/analytics-summary.js`: event names, exact-release bridge, disabled default, and test aggregate definitions.
- `server/identity-reports/usage.js`, `server/identity-creators/service.js`: owned-family usage and read-only creator dashboard.
- `docs/USER_PROFILE.md`: optional SDK 1.8 profile projection and fallback.