feat: TikTok/Douyin ecosystem simulation (short video, livestream, e-commerce)

[akz142857]

Summary

I'd like to propose adding TikTok/Douyin ecosystem simulation support to MiroFish. This would extend the current Twitter and Reddit platforms with short video feed, livestream, and e-commerce conversion simulation — making MiroFish the first open-source framework capable of simulating TikTok-style social commerce.

Motivation

• TikTok/Douyin is the world's largest short-video platform (7-8B DAU), but no open-source simulation framework exists for its ecosystem
• MiroFish's vision is "Predicting Anything" — TikTok's content virality + livestream commerce is one of the most commercially valuable scenarios to simulate
• The existing OASIS architecture (Platform abstraction + ActionType + AgentGraph) provides a solid foundation for extension
• Use cases: brand launch rehearsal, KOL campaign simulation, content strategy testing, e-commerce funnel optimization

Proposed Design

Three-Phase Implementation

Phase 1 — Short Video Feed Simulation

• TikTok agent profile format (role: viewer / creator / streamer / merchant)
• Video content model (abstracted as attribute vectors, not actual video)
• Traffic Pool Racing algorithm (流量池赛马): 7-level traffic pools with relative ranking promotion/demotion
• Custom recommendation system: 70% interest-based + 15% following + 10% explore + 5% livestream
• Feed action space: create_video, watch_video, like, comment, share, follow, duet, stitch, not_interested, scroll_feed
• 3-second attention window simulation for completion rate modeling
• Content lifecycle with time decay (72h half-life) and re-distribution triggers

Phase 2 — Livestream Simulation

• Livestream room model with real-time multi-agent co-presence
• Streamer agent decision chain (product showcase, audience interaction, flash sales, urgency tactics)
• Viewer behavior: enter/exit, bullet comments, gifts, product clicks
• Livestream traffic scoring (stay duration, interaction rate, viewer growth, GPM)

Phase 3 — E-Commerce Closed Loop

• Product and Order data models
• Dual conversion funnels: short video shopping cart + livestream commerce
• Agent purchase decision model (price sensitivity, impulse buying, herd effect)
• Key metrics output: GPM, CVR, UV value, average order value, return rate

Technical Approach

• No OASIS fork required: Use custom Platform subclass, keeping compatibility with upstream upgrades
• MiroFish changes: ~6 modified files + ~6 new files
  • config.py — add OASIS_TIKTOK_ACTIONS
  • oasis_profile_generator.py — add to_tiktok_format()
  • simulation_config_generator.py — TikTok platform config generation
  • simulation_manager.py — add TIKTOK to PlatformType enum
  • simulation_runner.py — support TikTok simulation script
  • api/simulation.py — enable_tiktok parameter
  • New: run_tiktok_simulation.py, tiktok_platform.py, tiktok_recsys.py, tiktok_commerce.py, tiktok_livestream.py
• Frontend: New TikTokDashboard.vue for traffic pool visualization and e-commerce metrics

Key Differences from Twitter/Reddit

Dimension	Twitter/Reddit	TikTok (proposed)
Content	Text-based	Short video (attribute vectors)
Recommendation	Social graph / vote score	Algorithm-driven traffic pool racing
Lifecycle	Persistent	24-72h window + re-distribution
Interactions	Retweet/vote/comment	Like/comment/share/duet/stitch/purchase/gift
Commerce	None	Livestream commerce + video shopping cart
User roles	Uniform	Viewer / Creator / Streamer / Merchant

Contribution Plan

I've forked the repo at akz142857/MiroFish and have a detailed technical plan ready. I'd like to:

1. Submit PRs incrementally (Phase 1 → 2 → 3), not as one massive PR
2. Each PR will be self-contained and independently testable
3. Happy to adjust the design based on maintainer feedback before coding

I'd also consider contributing the core TikTokPlatform and TikTokRecsys upstream to camel-ai/oasis if that's preferred.

Questions for Maintainers

1. Does this direction align with MiroFish's roadmap?
2. Any preference on the Platform extension approach (custom subclass vs. OASIS upstream)?
3. Should I also propose a Platform Registry / adapter pattern to make future platform additions easier?

Looking forward to your feedback!

[d8lv426]

Hello. I think its a good idea. I think eventually we need to have Facebook as well.

[akz142857]

Update: Revised Technical Approach

After a deep audit of the OASIS v0.2.5 source code, I've identified critical constraints that require adjusting the implementation approach described above.

What Changed

The original proposal stated "No OASIS fork required" — this turns out to be incorrect for a production-quality TikTok simulation. Here's why:

Constraint	Impact
ActionType is a fixed Python Enum (33 members)	Cannot register new actions like WATCH_VIDEO, ENTER_LIVESTREAM, SEND_GIFT without modifying source
Platform.running() validates actions via ActionType(action)	Any unregistered action value raises ValueError
RecsysType is also fixed (4 types) with hardcoded if/elif dispatch	Custom TikTok recommendation algorithm can't plug in natively
DB schema is fixed (16 tables via create_db())	New tables (video, livestream, order) need schema extension

The core issue: LLM agents select actions via tool calling using ActionType names. If we map CREATE_POST → "upload video", the agent sees create_post in its tool list — not upload_video. This semantic mismatch degrades agent behavior quality, which is the foundation of simulation accuracy.

Revised Approach: Fork OASIS

Instead of a custom Platform subclass, I now recommend forking camel-oasis with targeted extensions:

• typing.py: Add ~14 new ActionType members (e.g. UPLOAD_VIDEO, WATCH_VIDEO, ENTER_LIVESTREAM, SEND_GIFT) + RecsysType.TIKTOK + DefaultPlatformType.TIKTOK
• platform.py: Add TikTok action handler methods (leveraging existing getattr(self, action.value) dispatch — no architecture change)
• recsys.py: Add rec_sys_tiktok_traffic_pool() following the same function signature pattern as existing recsys functions
• schema/: Add 4 SQL files (video.sql, livestream.sql, livestream_viewer.sql, order.sql)
• agents_generator.py: Add generate_tiktok_agent_graph()

Total OASIS fork changes: ~740 new lines + ~77 modified lines across 9 files. All changes are additive — no modifications to existing Twitter/Reddit functionality.

Why This Is Better

1. Agent semantic accuracy: LLM sees upload_video / watch_video / enter_livestream instead of repurposed create_post / like_post / follow
2. Clean integration: Uses OASIS's own extension patterns (add enum members + add handler methods)
3. Upstream contribution path: The fork changes can be submitted as a PR to camel-ai/oasis — a TikTok platform would be valuable for the OASIS community and paper citations
4. MiroFish changes stay minimal: Only profile generation, config, and runner script — same as originally proposed

Questions

Does this revised approach affect your assessment? I'm happy to:

1. Submit the OASIS fork changes to camel-ai/oasis first, then integrate into MiroFish
2. Or keep the fork as a MiroFish dependency until OASIS merges it

The feature scope (3 phases: Feed → Livestream → E-commerce) remains unchanged.

[666ghj]

I think its a good idea.

[akz142857]

Awesome! I’ll submit the PR for oasis first, then follow up with the MiroFish adaptation.