> 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-09-05.md). # 2026-09-05 — Guest list ## Objectives * Let a streamer name people who can join their stream free, any time. * Prove they are genuinely never charged, and that nobody else can copy the trick. ## What happened Streamers can now keep a guest list. Add someone by their MegaChat name and they walk into any of your rooms without paying, without waiting for a seat, and without ever seeing a payment screen. It is one list per streamer, not per room, so a co-host is added once and works everywhere you go live. There is a master switch to turn the whole thing off for a while without losing anyone, and a limit of 20 guests so it cannot quietly become a free room. Two decisions worth knowing about. A guest gets an **extra** seat rather than one of the paid ones, so they never wait and never push out someone who paid. And taking someone off the list never interrupts them mid-stream: their current session finishes and the change applies the next time they join. It is proven rather than believed. A test suite drives the real website the way a person would, on a real server, and checks 53 separate things — including watching every single request the server makes to the payment network and confirming that not one of them moves money. That check was itself wrong at first and passed for a bad reason; it was fixed and now measures nine real requests and confirms none of them are payments. **This is on a branch and is not live.** Nothing on megachat.fun changed today. ## Problems and how we handled them * **The money check was lying.** The first version of the "nobody was charged" test watched the wrong address, so it saw zero payment traffic simply because it was looking at nothing. Found and fixed before it could be trusted; it now proves the point instead of assuming it. * **A separate test appeared to pass and shouldn't have.** While checking for damage to existing features, one of the older test scripts passed on the current code and failed on the new work. It turned out neither result was real: that script waits 2.5 seconds for the site to start, and on this machine the site takes over two minutes. Its earlier "pass" came from an abandoned copy of the site left running from a previous session. Roughly seventeen older test scripts share this flaw. Not caused by today's work, now written down, and the fix is mechanical. * **Most of the older tests therefore could not be run here** to confirm nothing broke. Three that use the newer, reliable startup could, and all three passed. ## Outstanding **Owner** * Decide whether the guest list ships. Nothing is deployed. (Say the word.) * Still open from before: set `AUTH_SECRET` in Railway. Until then the live site signs logins with a value that is published in the public code, which means someone could impersonate an account. **Two minutes**, and it is the highest priority item on this list. **Engineering** * Port the seventeen fragile test scripts onto the reliable startup helper. * If a streamer ever uses a large guest list on a busy stream, the extra seats are a real video-hosting cost; worth a smaller cap on how many guests can be live at once. ## Outlook **Mid, leaning bullish.** The feature is small, self-contained, and better evidenced than most of what is in the repo — the payment-network check is stronger proof than a log line. What holds it at mid is that the older test suite could not be run here, so "nothing else broke" rests on three tests plus reading the code, not on the full set. Porting those scripts would move this to bullish quickly, and the login-secret item outranks all of it. --- # 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-09-05.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.