photo #9014122

STREAMING EXPLANATION Hi all - just an FYI, we have streaming active but please understand, the new apps where the total streaming fix is present won't be active until approved by Apple and Google Play (7 - 14 days). This is why you'll sometimes see comments lagging behind or like tonight, not showing at all. The new app updates with new code will fix this. Obviously, they work on the web version, seamlessly. Thanks for bearing with us. I'm going to breakdown why it is incredibly difficult to have it flawless, below: Getting live video + “instant” comments to feel smooth is one of the hardest things you can build on a social platform, because you’re trying to make *two different real-time systems* behave like one seamless experience:Video wants stability, buffering, and adaptive bitrate to avoid freezing.Comments want ultra-low latency, strict ordering, spam control, and massive fan-out to thousands of viewers instantly.When you combine them inside iOS/Android apps, across spotty mobile networks, at unpredictable traffic spikes, and with “free speech platform” abuse patterns… the difficulty jumps.Here’s why it’s so hard, in practical terms.---## 1) “Live” doesn’t mean one thing: latency is a spectrum with tradeoffsMost platforms choose between two worlds:### A) HLS/DASH (most common, most stable)* Video is chopped into segments (often 2–6 seconds each).* Players buffer multiple segments for smoothness.* End-to-end latency is commonly 10–30 seconds, even when it looks live.* You can push it lower (LL-HLS / LL-DASH), but complexity rises and it still isn’t truly “instant.”Pros: Works everywhere, scales well via CDNs, fewer failures.Cons: Viewers are “behind,” so comments feel “ahead” or “out of sync” unless you delay comments too.### B) WebRTC (true low-latency, like FaceTime)* Can be <1 second glass-to-glass.* But scaling beyond small groups is hard: you need SFUs, TURN, bandwidth, complex routing.* Mobile networks + NAT types + carrier restrictions cause random failures.Pros: Feels truly live.Cons: Much harder at scale, much more expensive (a 60 minute show with 1,000 views would cost us $100), more moving parts.The core problem: If your stream is 12 seconds behind, but comments arrive in 200ms, your instant comments are reacting to something the viewer hasn’t even seen yet. To fix that, you either:* artificially delay comments, or* reduce video latency (hard), or* accept that it will feel “off.”---## 2) Live video isn’t “upload then play” — it’s a pipeline with many failure pointsFor a single live stream, you’re juggling:1. Ingest (RTMP/SRT/WebRTC) from broadcaster → your endpoint/provider2. Transcoding (multiple renditions: 1080p/720p/480p…)3. Packaging into segments (HLS/DASH)4. Origin storage/caching5. CDN distribution to viewers globally6. Player logic choosing bitrate, recovering from stalls, drifting timestamps, etc.Any weak link creates:* black screens* long spinny wheels* audio/video desync* “works on Wi-Fi, dies on LTE”* “works for some viewers, not others”And on mobile, you add:* backgrounding/foregrounding quirks* battery/thermal throttling* OS network stack changes mid-stream* device decoder differences (some phones struggle with certain encodes)So even before comments, live video alone is hard.---## 3) “Instant comments” is a real-time distributed systems problem (not just a database write)Comments at scale require you to solve multiple competing requirements:### Real-time delivery (milliseconds)* WebSockets / MQTT / server-sent events / push channels* Connection stability across mobile networks (frequent drops, reconnect storms)### Fan-out at scale (one comment → thousands of viewers)If a stream has 1,000 viewers, one comment becomes 1,000 deliveries immediately.That is a throughput and infrastructure problem, not a “code” problem.### Ordering and consistency (the underrated killer)Users expect:* comments appear in order* no duplicates* no missing messages* “I posted it, I see it instantly”* “everyone else sees it too”But real systems have:* race conditions (multiple servers)* partitions (network splits)* retries (duplicates)* clock skew (timestamps lie)* backpressure (queues fill)* reconnects (client may replay)So you need message IDs, dedupe, ordering rules, and reconciliation logic that works even when the network is chaotic.---## 4) Combining them makes sync problems inevitable unless you engineer around itEven if you nail both systems independently, the *combined experience* breaks because:* Video is buffered and can drift (player might suddenly jump, rebuffer, or change bitrate).* Comments are real-time and reflect “now.”* Different viewers have different delays (someone on fiber is 5s behind, someone on LTE is 18s behind).So when a viewer types “OMG did you see that??”:* half the audience hasn’t seen “that” yet* some already did 10 seconds ago* and your streamer is actually *ahead of everyone*To make it feel coherent, platforms do tricks like:* anchoring chat to video timestamps* allowing “live edge” sync* delaying chat to match typical video latency* showing “you are 12s behind live”* using stream-time offsets per viewerAll of that is non-trivial.---## 5) Traffic on social platforms is spiky and hostile by defaultWimkin isn’t Netflix with predictable demand. Social live is:* sudden raids* sudden influencer spikes* unpredictable concurrency* comment storms during “moments”* coordinated spam / bot floodsThat means the system must withstand:* 10× load increases in minutes* abusive traffic patterns (many new connections, rapid posting)* moderation actions in real-time (delete/ban must propagate fast)Real-time systems hate chaos. Social platforms produce chaos.---## 6) Moderation and “free speech” positioning adds real-time complexityIf you allow broad speech, you get more:* spam* brigading* doxxing attempts* harassment bursts* illegal content attemptsFor live comments, moderation isn’t “review later.” You need:* rate limits per user/device/IP* spam scoring* link/domain reputation* shadowbans (often)* fast delete propagation* audit trails (for legal disputes)* tools that work *while the stream is live*Every one of those layers adds latency, complexity, and failure modes.---## 7) Mobile realities make “instant” fragileEven if your backend is perfect, mobile ruins the illusion:* Switching Wi-Fi ↔ LTE drops sockets.* Some carriers aggressively NAT and kill idle connections.* Android OEM variations break background networking.* iOS can suspend network activity when the app is backgrounded.* Power-saving modes throttle timers and sockets.So you must implement reconnect logic that:* resumes chat without duplicating messages* catches up missed comments* keeps the UI stable* doesn’t DDoS your own servers during reconnect stormsThat is a lot of engineering.---## 8) Cost constraints force compromises that users feelThe “easy” way to make things stable is:* higher video latency (more buffering)* aggressive CDNs* overprovisioned real-time infra* managed chat services* paid observability/monitoring everywhere* global edge presenceBut when you’re cost-sensitive (and most independent platforms are), you end up trading:* ultra-low latency for stability* perfect chat ordering for scale* instant propagation for moderation checks* “always-on sockets” for battery/network practicalityUsers experience those compromises as:* “why is chat delayed?”* “why are comments missing?”* “why is video behind?”* “why does it work sometimes and not others?”---## 9) Debugging is brutal because the bugs are emergent (not obvious)The hardest part operationally: you rarely get a clean error.You get:* “stream froze for me but not my friend”* “comments stopped after 2 minutes”* “Android is fine, iPhone isn’t”* “only happens on T-Mobile”* “works until there’s a spike”To fix it, you need deep instrumentation across:* ingest stats* transcoder health* origin/CDN cache behavior* player metrics (rebuffer events, live edge distance)* websocket connection churn* queue depth and fan-out metrics* per-region latencies* per-device player behaviorWithout that visibility, teams end up “guess fixing” instead of engineering.---## The simplest way to summarize why this is so hardYou’re trying to deliver:* a huge continuous data stream (video)** that must not stall, while simultaneously delivering* tiny real-time messages (comments) that must feel instant,* to thousands of devices on unreliable networks,* under unpredictable spikes and adversarial behavior,* with moderation requirements,* while keeping costs survivable,* and making it all feel like one synchronized “live” moment.That’s why even big companies screw it up—and why it’s a monster for an independent platform.Our new apps should wipe out all of the aforementioned issues. Once again, THANK YOU for understanding and for your patience! I will push app stores for rapid, expedited approval.