> 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-26.md). # MegaChat brief — 2026-07-26 ## MegaChat brief — 2026-07-26 ### Objectives today * Prove the money-saving fix actually works against the real video service, not just a local test copy * Harden the bounty system's evidence so a payout can't rest on damaged proof * Answer the leftover question from yesterday: was the connection problem quota, or something worse ### What happened * **The core claim is now proven.** Ran the overlay against the real LiveKit service for ten minutes with nobody in the room, checking from their side rather than ours: zero connections the entire time, twenty-nine checks in a row. Then a guest arrived, it connected, the guest left, it disconnected. This was the last thing in the project that was believed rather than shown. * **Yesterday's worst case didn't happen.** The connections that were half-failing were simply the free plan running out. The paid plan fixed it — twelve rapid attempts and ten spaced attempts all succeeded. Not a deeper problem. * Found and fixed a live bug while checking something else: if a streamer played the same fan clip twice, **the second play earned them nothing**. The system was looking up the first play's record and finding it already finished. Each play now gets its own identity. * Hardened the proof records. The clips' verification codes are what a payout is calculated from, and they could previously be damaged by a crash without anyone noticing — which would quietly *underpay* a streamer. They now can't be altered without the system refusing to run, and a payout is blocked outright if the proof doesn't hold up. * Wrote up the sub-3-second clip question for you to decide. ### Problems and how we handled them * I had rated the proof-records risk as minor yesterday. That was wrong and I said so: I'd treated them as bookkeeping when they're actually evidence. Fixed properly rather than deferred again. * My own test deliveries were being counted against the spending budget. Small now, but it means routine checks could eventually trip the safety cut-off and block real traffic. Test traffic is now recorded but not billed. * The measurement showed a gap between their numbers and ours. Traced it: my measuring script stopped counting during a wait period. Their figures and ours agree once that's accounted for. Not a real discrepancy, and worth saying plainly rather than reporting a scary-looking number. ### Outstanding * **You: paste the webhook address into LiveKit.** Two minutes. Still the one thing blocking automatic spend protection. * **You: decide the sub-3-second clip question.** Fans can pay for clips too short to verify. Right now that money quietly funds other clips — which is the same flaw we already fixed once, happening by accident. My recommendation, with options, is in `docs/decisions/sub3s-residual.md`. Related: there's currently no minimum clip length at all, so a one-second clip is accepted and charged today. * Real streamer sign-in and real video checking still need platform accounts registered and a test stream. * Confirm the hosting service isn't set to sleep when idle, which would drop delivery messages. No evidence it does; the setting is in a dashboard I can't see. ### Outlook: bullish * The expensive bug is fixed, and as of today it's **measured against the real service** rather than believed. That was the main thing keeping this at "mid" yesterday. * Yesterday's bearish scenario is closed — the connection failures were just the free plan, nothing structural. * Two real bugs found by looking rather than by waiting for them to bite: the replay underpayment and the fragile proof records. * What keeps it short of fully bullish: spend protection is built but inert until the webhook address is pasted in, and the money side has never moved real funds. Both are known and small. *** ## Later the same day *Appended after the sections above; nothing earlier was edited.* ### What happened * **The spend protection is now live and proven with real traffic.** I put a real participant into the production video service for about fifteen seconds and watched the whole round trip: the service told us they arrived, told us they left, the session opened and closed cleanly, nothing was left hanging, and the recorded length matched the stopwatch. Most importantly the spending meter is now reading a **real number instead of zero** — that was the entire point of turning this on. Cost of the test: 0.23 minutes against a 10-minute budget. * **Found a bug in the safety check itself.** I was asked to explain any gap between the service's numbers and ours, and the gap turned out to be the comparison, not the data. Our own records survive a restart; the service's records start from scratch every time we deploy. Comparing the two was comparing a full day against a few minutes, so it screamed "mismatch" after *every single deploy* with nothing actually wrong. A monitor that cries wolf after every deploy is worse than no monitor, because you learn to ignore it. It now only compares periods both sides actually saw, and says "not enough data yet" instead of guessing. (Issue L8.) * **Clips that are too short to verify can no longer be sold.** This closes the item you were asked to decide on: there is now a minimum clip length. The number isn't invented — it's *taken from* the length the verifier needs to read a code off a stream, so if that requirement ever changes the minimum follows it automatically instead of drifting apart. A short clip is refused while recording, before any wallet prompt, and refused again on the server **before the payment step**, so nobody is ever charged for one. Rooms can't set themselves below it. * You asked what happens to short clips already in the system. **There are none, and there can't be** — clips only exist in memory between being paid for and being played, and are deleted afterwards. Nothing to clean up. * **Refunds are now one road instead of several paths.** Money can go back for four named reasons — unverifiable clip, handle never claimed, dispute, manual operator action — and a reason that isn't on the list is refused outright. The important part: a contribution can only be refunded **once**, no matter how many reasons arrive for it, so a dispute landing on a clip that already refunded doesn't pay it twice. Every refund records why, who did it, and what it relates to. Still no real money moving. * **Two things you reported mid-day, both fixed and deployed**: your Twitch account is now used by default instead of being buried in advanced settings, and the OBS overlay going black while viewers saw the stream fine. That second one was ours — two overlays open anywhere were kicking each other off. ### Problems and how we handled them * The reconciliation gap could easily have been written off as "close enough" or reported as a scary number with no explanation. It was neither; it was a real defect in the thing meant to catch defects. * One of my own automated checks was still asserting the *old* overlay behaviour from before this morning's black-screen fix, so it failed. That's the check doing its job — I updated it to assert the new rule rather than the old one. * A test room I set up looked like the minimum-length rule was broken when it was really my test room being priced when I meant it to be free. Worth naming because the error message pointed at the wrong thing entirely. ### Outstanding * **You: confirm the hosting service isn't set to sleep when idle.** Unchanged from this morning, still the only thing I can't check myself. * **The biggest remaining hole in the money model: there is no way to reverse a payout.** Refunds can only return money still being held. Once it's released to a streamer, nothing in the system can pull it back — a dispute decided against someone after they've been paid has no mechanism. It needs its own design, not another reason code. Written up in `OPEN-ISSUES.md`. * **New for later: record how many people were watching at each clip play.** Payouts should scale with audience — a clip played to forty people shouldn't be worth the same as one played to forty thousand, and neither should be worth nothing. This has to be built *at the same time* as the real stream checking, because viewer counts can't be looked up after the fact. Any play recorded before then can never be priced this way. (Issue B6.) ### Outlook: bullish, unchanged * Spend protection moved from "built but inert" this morning to **live, tested with real traffic, and reading real numbers**. That was the main caveat on this morning's bullish call and it's now closed. * Two more real defects found by looking rather than waiting — the false-alarm monitor and the black OBS overlay — both in things that were assumed fine. * What still keeps it from being unreserved: no real funds have ever moved, and the no-clawback gap above is a genuine design hole rather than a task. --- # 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-26.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.