> 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-08-26.md). # 2026-08-26 — the front door opens, and four platforms move ## Objectives * Merge yesterday's capture work to trunk and ship it. * Build the one thing that has blocked the whole bounty idea for weeks: let a fan actually record and send a MegaChat. * Make the confidence tiers decide something instead of just describing it. * Add three more platforms: YouTube, Rumble, pump.fun. Add X ownership. ## What happened **The fan front door works, and now we can prove it.** The bounty mechanic has a lot of machinery behind it — escrow, watermarking, verification, payouts, refunds — and for weeks the front of it was a wall: no way for a fan to actually record a clip for a streamer who isn't here yet. It turned out the recording screen had quietly been built already. What was missing was any proof it worked end to end. Now there's a test that does what a fan does: opens the page in a real browser, records off the camera, previews, re-records, sets the amount and the expiry, pays, sends — and then checks that the clip genuinely landed, attached to the right pledge, with the pool grown by exactly the amount typed in. It also proves the promise that nobody pays for a take they discard: a thrown-away recording leaves the books completely untouched, because nothing is created until you hit send. Two real bugs fell out of writing that test — the "my bounties" page was dead for anyone who didn't type an optional name, and the refund text on the pay screen said money goes somewhere it doesn't. **The confidence tiers now hold the money, not just label it.** Yesterday's tiers sorted a verification into "pays automatically" or "a person looks." One path leaked: a setting meant to force everything to human review flipped the verdict but let the payment through anyway. Fixed — the tier now actually stops the money — and every automatic payout records which tier allowed it, so it's auditable after the fact. It still never changes the amount: every streamer who passes is paid the same. **Four platforms moved.** * **X** — a streamer can now claim their X handle. This works because our single sign-in (Privy) hands us the real @handle, which I verified by reading the code and proving it in a test rather than assuming. X has no video we can pull, so it verifies on our own recording plus the streamer's OBS. * **YouTube** — the streamer hands us their watch link and we confirm the broadcast against it. The same link is the live stream and the replay, which makes it the cleanest platform after Twitch. * **Rumble** — live status via a URL the creator generates, which doubles as ownership proof. Worth flagging: that URL is transferable in a way a login isn't — whoever holds it "is" the channel until it's regenerated. The video side is built; the response format is from docs and hasn't met a real Rumble stream yet. * **pump.fun** — serves plain public video that our server can pull with no account, and stamps every two seconds of it with a wall-clock time. That timestamp removes the single fiddliest part of Twitch verification: we no longer have to *measure* how far the video lags our clock, because the stream tells us. Proven end to end. ## Problems and how we handled them * **The biggest find had nothing to do with the new platforms.** Real identity verification was broken for *every* streamer who signs in the normal way. The check demanded that the sign-in method exactly equal the platform, and our single sign-in never does — so with real verification switched on, nobody who came through the front door could have claimed a bounty on any platform at all. It was invisible because the tests use an older, simpler sign-in shape. This is the third time in two weeks a green test has been hiding a single unhandled case, which is a pattern in the tests, not bad luck. Fixed, and now tested against the real sign-in shape. * **An auth hole I opened yesterday.** A convenience I added for streamers retrying a claim handed the claim back before checking who was asking — so any signed-in account could have walked into someone else's verified claim. A new test caught it on its first run. Fixed to verify the caller first. * **pump.fun's stream would have cost us gigabytes and never stopped.** Its playlist never forgets, and our recorder re-downloaded the entire history on every poll — 205 downloads in ten seconds in the test. The other platforms hid it because their playlists do forget. Fixed. * **My own test lied to me first.** The pump.fun test faked a video encoder badly, and the timestamp math correctly caught the fake. The math was right; the fake is now honest. * **A test that had been crashing for weeks is gone.** It checked a sign-in screen we deleted in July. Replaced with one that checks the door we actually have, focused on proving forged and junk sign-ins create nothing. ## Outstanding **Owner:** * **Kick is still unproven** and still the cheapest confidence to buy — one real broadcast, needs the stream key and ingest URL from your Kick dashboard. Third day on this list. * **The bounty admin password is still not set on the server.** Must be, before any public switch-on. * **A call on pump.fun and coin-keyed ownership.** The video is solved. The open question is whether we want to pay out to a coin address instead of a person — that's a product decision, not an engineering one. The wallet- signature proof it would need is buildable with no help from pump.fun. **Engineering:** * Self-capture still hasn't run against one real broadcast. Much better tested now, all against simulations — and this week's bugs are exactly what a simulation hides. * No cap on total recording storage across many streams at once. * Rumble's live-status format is unverified against a real stream. ## Outlook **Mid, trending up.** Five things shipped, all tested, and four platforms went from "someday" to "the video works." The front door — the single biggest blocker on the whole idea — is open and proven. That's real. But the honest headline is the same as the last two days: the biggest find was a green test hiding a broken path, and this time it was a bad one — real verification silently didn't work for anyone. Three of those in two weeks says the tests are structurally too kind, and I've been writing every new test this week to assert on *what landed* rather than *what ran*, specifically because of it. The new gates all do that now. What moves this to bullish is unchanged and simple: **one real broadcast**, end to end, from our own recording. Everything built this week is scaffolding around a claim that has still only ever been proven on synthetic video. What moves it down is that broadcast finding a fourth hidden case of the same kind — at which point the right move stops being "build more" and becomes "stop trusting the green." --- # 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-08-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.