Riff + Rifflets: proposed platform convergence

Prepared for Dan, Rajeev, Phil and Samir · 2026-10-04 · Discussion proposal, not an agreed migration or a claim of existing interoperability.

Recommendation

Keep one creator/discovery/feedback system in the eventual Riff product, while treating a playable Rifflet as a new versioned content type with a client-side execution contract. Reuse the existing Riff media/agent workflow; add an explicit interactive-bundle adapter rather than pretending an HTML app is an image or video. Begin with a reversible linked pilot, then migrate hosting only after contract and security agreement.

What exists on each side

The Lab at https://riff.marantz.net/ has mobile-first playable experiences, controlled discovery metadata, portrait feed covers, a common menu, explicit public feedback/history, data-only riff contracts, private per-browser/per-app diagnostics, and reviewed personalized artifact infrastructure. Curated legacy apps share an origin and trusted runtime; generated artifacts have a separate isolated runtime contract. These are distinct trust boundaries.

The observed public onboarding at https://riff.samirp.org/llms.txt and https://riff.samirp.org/agents.md describes agent registration, private agent keys, media upload, image/video posts, reaction/review inboxes and remix jobs. Its MCP endpoint is https://us-west1-riff-samir.cloudfunctions.net/api/mcp . The documentation describes media posts and agent-driven remix work; it does not establish support for hosting arbitrary HTML/JS/WASM bundles, external interactive-launch fields, our analytics schemas or our instance lineage. Those are asks to verify with the owners. We read the onboarding as reference material, not authorization to register, post or contact people. The alternate spelling riff.samir.org is not the verified platform address.

Our earlier asks_for_riff.md already called for path hosting/embeds, structured maker briefs, version lineage, feedback, asset storage, agent inboxes, capability declarations, sandboxing, editable taste and content advisories. Carry those themes forward, but reconcile their historical implementation notes against current code. No claim that an earlier email was sent: this pass did not find a Riff draft in the connected Gmail search.

Shared object model

Use separate identifiers for creator, app family, executable release, personalized content instance, feed post, feedback item and build/remix job. An app release references a full source commit and immutable artifact digest. A child instance references its immediate parent and validated content; a feed post references the exact release/instance it launches. A post ID must never replace a source commit or be interpreted as a verified human identity.

Map our catalog summary, rich description, type, genres, interests, intended audience, requirements, cover and provenance into a versioned Riff maker brief. Review changes in intended audience or purpose for a derivative instead of blindly inheriting parent approval. Keep creator-declared tags separate from explicit user taste and behavior-derived evidence. Never import private analytics browser IDs/IPs as a public social identity.

Phase 1: linked pilot

Agree a post type or approved external launch link with Samir's owners. Publish an appropriate cover/preview plus a clearly labeled play destination for two or three reviewed Rifflets only after the API and authorization are confirmed. Existing media upload alone does not prove such a link field exists. Keep Lab hosting and URLs stable. Measure whether users reach a meaningful first action; distinguish cover impressions, launch clicks and actual app starts.

Acceptance: owners agree field/permission contract; exact launch source is recorded; mobile direct-route and preview work; all claims match content; feedback context returns to the correct app/release; rollback removes only the pilot post/adapter without breaking Lab links.

Phase 2: interoperable feedback and agent work

Bridge approved Riff review/remix requests into versioned work items referencing app/release/instance and an idempotency key. Preserve the upstream job ID, status, lease/renewal and reply semantics. Let the owner designate who can accept a request. An inbox next_action is advisory, not permission to spend or publish. Agents inspect bounded evidence, propose changes in isolated branches, test and ask the release owner to promote the reviewed artifact.

Reconcile public comment visibility, private diagnostics, deletion receipts, moderation and retention before copying records. Publish a concise reviewed outcome linked to a new version, not raw private traces. Avoid duplicate feedback histories with no source of truth: designate one canonical feedback record and retain mapped foreign IDs.

Phase 3: hosted interactive bundles

Agree a rifflet bundle manifest, dependency/assets digests, source license/provenance, spec version, permissions, networking, storage and lifecycle messages. Serve immutable assets via CDN/object storage. Lazy-load WASM/models; do rendering and sensor inference locally. Servers handle shared decisions, leaderboards, feedback, approved generation and artifacts—not every frame of gameplay.

Choose an isolated-origin model for untrusted creator code. Restrict sandbox/permission policy and validate postMessage origins plus message schemas. Keep admin credentials and private analytics outside content origins. Inventory cookies, local storage, service workers, CORS, camera/mic iframe policies, CSP and cross-origin isolation before moving apps. WebAssembly does not make arbitrary code safe by itself.

Acceptance: realistic memory/network load budgets, metadata validation, malicious-bundle rejection, pinned replay, permission-denial fallback, device lifecycle, telemetry failure resilience, asset MIME/cache behavior and rollback all demonstrated. Existing Pages/D1/R2 implementations may serve as adapters; merging products does not require migrating all databases on day one.

Phase 4: measured migration

Canary a small approved set. Compare meaningful starts and user-reported friction with clear denominators, not test-generated traffic. Keep old URLs, immutable versions, redirects and removal capabilities valid. Migrate schema/data in bounded idempotent batches with backups and reconciliation. Revoke superseded credentials only after readback and rollback rehearsal. Retire duplicate surfaces when both owners approve, not merely when a build succeeds.

Decisions for the founders

1. Is interactive content an external launch, sandboxed embed or uploaded executable bundle in the first pilot?
2. Which system owns app/release/instance IDs, feedback history and moderation decisions?
3. What are the trust tiers for reviewed curated code, generated code and arbitrary third-party uploads?
4. What can creators see in analytics; who can inspect private browser/IP traces; what is retained and deleted?
5. Which permission/lifecycle/asset APIs belong in the common SDK, and which stay app-owned?
6. Who may create agent identities, accept remix jobs, use paid tools and promote a release?
7. What is the supported compatibility window and rollback route for old shared links?

Proposed work split

Dan/product: select the pilot and acceptance promise; approve exposure/spend. Phil/architecture: runtime isolation, bundle/spec compatibility, client-first/WASM decisions and scale budgets. Samir/platform: supported API schema, auth, media/post integration, job routing and deployment ownership. Rajeev/discovery: creator brief, taxonomy, intended audiences and useful feedback loop. These are proposed responsibilities to confirm, not a record of agreement. Codex/Claude/other build agents own bounded branches, reviews and evidence under one release coordinator.

Next exchange

Share the current Canonical Rifflet Spec and Content Onboarding links. Ask for the current Riff format/API schema, a test environment, supported launch/embed contract and owner-approved scoped access. Do not send Git bearer keys in public posts or an admin page. Use RIFF_ADMIN_COORDINATION.md for the discussion agenda and AGENT_MERGE_RUNBOOK.md for execution after agreement. No new account, subscription, paid service or production migration is authorized by this planning document.