> For the complete documentation index, see [llms.txt](https://jordan-7.gitbook.io/jordan-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jordan-7.gitbook.io/jordan-docs/internal/briefs/2026-07-27-evening.md). # MegaChat brief — 2026-07-27 (evening run) ## Objectives * Ship last night's work to production and prove the storage question for good * Build the missing front door: let a fan actually record and fund a MegaChat for a streamer who isn't here yet * Answer the "did our Twitch app survive the domain move" question with evidence, not guesses ## The headline **A fan can now do the thing the bounty program promises.** Pick a streamer, record a MegaChat in the browser, watch it back, re-do it if it's bad, set the money and an expiry, see exactly what the rejection rules are, and pay — in that order, payment last, so nobody ever pays for a take they threw away. The whole journey was driven end to end in a real browser by an automated test: record through a camera, pay, check the status page, claim as the streamer, review the clip, approve it, and watch the fan's status flip to Approved. ## Also built * **One bounty, several doors.** A fan can offer the same bounty to up to three streamers — first to claim takes all of it. The dangerous part isn't the race (that's handled: two simultaneous claims were fired at it and exactly one winner came out, every time) — it's the *display*. A streamer's page now always leads with what's exclusively theirs, and contested money is labelled with how many rivals are racing for it. Nobody claims a pool and finds it half gone without having been told. * **Expiry.** Fans set how long their offer stands (default about a week). Nothing is ever locked forever: lapse means an automatic full refund, and the recording is deleted along with it. * **The streamer is the editor.** Nothing airs without their approval. Their queue sorts the safe stuff first (the same AI review the room clips use now grades bounty clips at upload — never during a live broadcast), and rejecting asks *why*: "not for me" refunds the fan fully with no penalty; "breaks the rules" counts against repeat offenders — second offence refunds half, and the withheld half goes into the streamer's own pool, never to us. * **Claiming is real now (when switched on).** With one setting, claiming a handle requires being signed in with the Twitch account that owns it — proven by Twitch, not typed into a form. Testing this immediately caught a nasty bug: a *failed* claim used to jam the handle so nobody — including the real owner — could claim it afterwards. Fixed. * **Audience size is now captured at the moment it exists.** Every time a clip plays on a claimed Twitch channel, we record how many people were watching. Payouts should scale with audience, and that number is impossible to look up after the broadcast ends. ## The domain question, answered honestly * The address our code sends Twitch is derived from the live site, so the code side literally cannot be stale: it sends `https://megachat.fun/auth/twitch/callback`. * The app's credentials work (proven with a real token grant), and the stream preview embed cannot break from the domain move (proven against a live channel with 55,000 viewers, plus a negative control). * What I could NOT prove from outside: whether the Twitch developer console has the new address registered. Twitch only checks it *after* login — my first probe nearly reported success on evidence that turned out to prove nothing, and a deliberate wrong-address test exposed that. **Your 60-second test: while logged into Twitch, visit megachat.fun/auth/twitch.** If it bounces you back to megachat, the console is fine; if Twitch shows a mismatch error, add the address (it's written out in the audit doc). * Also learned: everyday Twitch *login* goes through Privy's own app now, so even a stale console entry wouldn't have broken sign-in. Kick has no keys yet; nothing was guessed. ## Problems, stated plainly * **Creating a fresh account costs nothing, so the rejection penalty is soft.** Strikes attach to whatever account string a fan types. Someone determined to probe the content filter can just use a new name. The fix is requiring sign-in to pledge (and eventually keying penalties to the payment method) — flagged for a decision rather than quietly half-built. * A pre-existing test for the room-clip moderation pipeline turns out to have been broken on trunk before tonight (proven by re-running without my changes). Filed; the new moderation path has its own working coverage. * Last night's volume question is now closed for good: the boot marker written by one deploy was still there when the next deploy started. Storage survives, proven, not inferred. ## Outstanding * **You: the 60-second Twitch console check above.** * **You: decide whether pledging should require sign-in** (closes the free-probing hole). * The bounty admin/review routes have no login protection yet — fine while the whole feature is switched off, must be locked before any public launch. * No real money moves anywhere; settlement is still the recorded-intent stub, and the payout-reversal design from this morning is still design-only. ## Outlook: bullish * This morning the bounty mechanic had storage and rails but no door. Tonight a fan can walk through it, a streamer can claim with real proof of identity, and every step was exercised end to end in a browser, twice over, with the gates catching three real bugs before any human ever hit them. * What keeps it short of unreserved: the free-probing hole, unprotected admin routes, and no real settlement — all known, all listed, none hidden. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://jordan-7.gitbook.io/jordan-docs/internal/briefs/2026-07-27-evening.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.