> 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/readme.md).

# MegaChat

MegaChat puts a viewer's camera on a streamer's live broadcast, for a price the streamer sets, for as long as the viewer stays. The streamer adds one browser source to OBS; the viewer opens a link, pays per second, and appears in a tile on the stream. When they leave, the tile goes and whatever they did not spend comes back to them. Source: the room config and seat lifecycle in `server.js` (`/api/config`, `/api/join/*`, `removeParticipant`) and the product description in `web/app/layout.tsx`.

There are two ways to be on the stream:

* **A live seat** — your camera, live, metered per second. (`server.js` `/api/join*`)
* **A MegaChat** — a short recorded clip that plays on the stream once. (`letters.js`)

And one way to get a streamer's attention before they have ever heard of you: a **bounty**, money pooled by fans that a streamer can claim by going live with the MegaChat program on. Bounties exist in the tree as a complete state machine over an append-only ledger; **settlement is a stub and no funds move through it.** Source: `bounty-escrow.js`, `bounty-settlement.js` (`StubSettlement`), and Gate H in `_gate-bounty-claim.mjs`.

**On the site the product is called Holler**, since the 2026-10-20 rebrand, and so is a recorded clip; the live seat is *Call in* and watch-to-earn is *Rewards*. Only what users read changed: routes, API paths, data keys and the megachat.fun domain did not, and these pages keep the code's names. The [glossary](/jordan-docs/glossary.md) maps one to the other (`web/components/feature-tag.tsx`, `FEATURE_LABELS`).

{% hint style="warning" %}
**Pre-launch.** MegaChat is deployed but in stealth: there are no users, and every session so far has been a rehearsal or a test gate. Money paths have been verified against fixtures, local infrastructure and a small number of real broadcasts by the project's own operator — not production traffic. Nothing in these pages describes production history. Source: `docs/internal/launch-readiness.md`.
{% endhint %}

## Where to go

| If you want to…                                                       | Read                                                                      |
| --------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| Understand the ideas the product is built on                          | [Concepts](/jordan-docs/concepts/concepts.md)                             |
| See what each feature does, how it works, and what it does **not** do | [Features](/jordan-docs/features/features.md)                             |
| Know how a bounty is verified, and what verification does not prove   | [Verification](/jordan-docs/verification/verification.md) — the hard page |
| Run it, contribute, or audit it                                       | [Technical](/jordan-docs/technical/technical.md)                          |
| Know what is shipped versus specced versus an idea                    | *Internal* — the owner's half, last in the sidebar                        |

## How these pages are written

Every claim about security, money, identity, data or correctness cites the file (and where useful the line) it comes from. Every feature carries exactly one status tag: `SHIPPED`, `SHIPPED-PARTIAL`, `SPECCED`, `IDEA`, `KNOWN-BROKEN`, `ASSUMPTION` or `UNCLEAR`. Tags are read from the repo, never invented; anything ambiguous is `UNCLEAR` and listed on the internal *Needs a status call* page. The rules and the scripts that enforce them are in `CONTRIBUTING-DOCS.md` at the repo root.

The repo is the truth. These pages never assert more than it does.


---

# 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/readme.md?ask=<question>&goal=<user_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.