> 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-25.md). # 2026-08-25 — capture hardening, and a platform we wrongly wrote off ## Objectives * Make our own recording of a stream trustworthy enough to be the main way we prove a streamer played a MegaChat. * Add a second, independent signal that the overlay was actually on screen. * Decide, once, whether pump.fun can work. ## What happened **Our own recording had never actually worked, and we did not know.** The headline result from last week was that verification no longer needs the platform to keep a replay — we record the stream ourselves. That was true in the sense that the recording was being made correctly. It was not true in the sense that anything could be *read back* out of it. Four separate faults, each enough on its own, meant that any stream with more than one MegaChat in it came back as "we could not check this" every single time. The reason nobody caught it is uncomfortable and worth writing down: our test only asked whether the check *ran*, not whether it *found anything*. It ran. It found nothing, forever, and reported that as a platform problem rather than ours. All four are fixed. The test now plays three MegaChats through three separate broadcasts and confirms all three are found and paid. **A second opinion on whether the overlay was really on screen.** If a streamer has connected their broadcasting software to us, we can now ask it directly, every few seconds while a MegaChat is playing: is our overlay actually visible right now? Hidden, in the wrong scene, shrunk to nothing, dragged off-screen — we can tell the difference, and we say so *while they are still live and can fix it*, instead of at payout. Two things about this that are deliberate and should stay that way: * **It cannot cost anyone money.** It decides whether a human takes a look. It never decides whether someone is paid. Everyone who passes is paid the same. * **Nobody is penalised for not having it.** Most streamers will paste our overlay link in by hand and never connect anything. Our test specifically checks that such a streamer is paid exactly the same as one who did connect — same amount, no review, no friction. If that ever stops being true, this feature has quietly become a requirement, and the test will fail. **pump.fun: we were wrong, and it is the easiest platform we have looked at.** Yesterday's assessment said pump.fun was undocumented, used a technology we cannot record from, and should stay parked. That was written from reading their documentation and a community write-up. Today we opened eight of their live streams and recorded exactly what the video player asked for. It asks for an ordinary video stream at a plain public web address — the same kind Twitch and Kick serve. Our server can fetch it with no account, no login, no key. It is higher quality than what Kick gives us (1080p at 60fps), and it carries a timestamp on every chunk that would remove the single fiddliest part of the Twitch work. The thing standing between us and pump.fun is not video at all. It is that their streams are attached to a coin, not to a person we can verify the identity of — and we pay verified people. That is a real problem, but it is a completely different problem from the one we thought we had. ## Problems and how we handled them * **Our test was measuring the wrong thing.** It asked "did verification run" when it should have asked "did verification find the MegaChat". Fixed, and the new test asks the second question in three separate ways. * **A signal we added turned out to be useless, so we removed it.** We started recording whether the overlay page thought it was visible. It reports "hidden" in perfectly normal situations — including in our own test rig — so it flagged *every* broadcast for human review, including the flawless ones. A warning that fires on the good case is not a warning, it is a tax on honest streamers. We still record it; it no longer sends anyone to review. * **pump.fun would have cost us gigabytes on the first try.** Their stream listing works differently from Twitch's and Kick's: it never forgets, so a 100-minute broadcast lists three thousand chunks. Our recorder would have dutifully downloaded the entire backlog before catching up to live. Fixed — we now always start at the live edge, on every platform. * **Still unresolved: none of this has been tested on a real broadcast.** The three broadcasts in our test are simulated, faithfully but simulated. The four faults we found today are precisely the kind a simulation hides. This is the same item that was outstanding yesterday and it has not moved. * **Found in passing: one of our older automated checks has been broken for weeks.** It tests a sign-in screen we deliberately deleted when we moved to one login. It crashes rather than fails, which is why it went unnoticed. It needs retargeting or deleting — a check nobody can run is the same as no check. ## Outstanding **Owner:** * **Kick is still unproven** and needs one real broadcast. We need the stream key and ingest address from your Kick creator dashboard. This has been outstanding for two days and is the single cheapest thing that would move confidence. * **A Twitch re-run would now be worth more than it used to be** — the same broadcast would test our own recording end to end for the first time. * **The admin password for the bounty system is still not set on the server.** It must be, before any of this is switched on publicly. * **A call on pump.fun**: the video side is solved, the identity side is not. Worth deciding whether "streams attached to a coin, not a person" is something we want to design around at all. **Engineering:** * No cap on total recording storage across many simultaneous broadcasts. * The stale sign-in check above. * pump.fun's "who is live" listing is unofficial and could change without notice — fine for investigating, not something to put payouts behind. ## Outlook **Mid, and more honestly held than yesterday's.** Yesterday's mid rested partly on "recording our own stream works." It did not. That is now genuinely fixed and much better tested, which is real progress — but the correction is a reminder that the gap between "built" and "proven" has bitten this project twice in three days, both times because a test asked an easier question than reality will. What is genuinely better: the money path is now checked three ways instead of one, everything that passes still pays the same, and a whole platform moved from "no" to "yes, pending a different question." What would move this to bullish: **one real broadcast**. Not a longer test suite — a real stream, on Kick or Twitch, verified end to end from our own recording. Everything else on the list is smaller than that one thing. What would move it bearish: that real broadcast finding a fifth fault of the same kind. Two rounds of "it was built but did not work" is a pattern; three would say our tests are structurally too kind, and the fix would be slower and less fun than any of today's work. --- # 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-25.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.