FairQueue-Twitch

Fair Twitch Questions. Visible Outcomes.

Comment

FairQueue — Fair Twitch Questions. Visible Outcomes.

Inspiration

FairQueue began with something I noticed while watching live online conversations: questions can be overlooked as discussions move forward. One question gets attention while another is passed over, and viewers have little visibility into what happened.

I wondered whether a better question-management process could help. What if accepted questions entered a visible queue and viewers could follow their outcomes?

I was not an experienced Twitch user. Building for its community meant learning the platform and understanding two perspectives: viewers want their questions considered, while streamers must manage a broadcast, protect their communities, and decide what is appropriate or relevant.

Those needs are not always the same. I wanted to give accepted questions a visible place in the process while keeping decisions in the broadcaster's hands. FairQueue would not force answers, eliminate bias, or ask AI to judge whether an answer was correct.

What it does

FairQueue is a Twitch-integrated question-management prototype designed to make accepted questions and their recorded outcomes more visible.

The current MVP follows a receive-only workflow called Phase A.

A viewer submits a supported !ask message in Twitch chat. Twitch EventSub delivers the inbound event to FairQueue. If accepted, the question receives a public identifier and enters the queue.

FairQueue provides two distinct interfaces:

  • Streamer Studio: The broadcaster-facing interface within FairQueue, where accepted questions appear in chronological acceptance order. The broadcaster can review questions and record one of three outcomes: Answered, Deferred, or Declined.
  • Viewer Pulse: The viewer-facing interface within FairQueue, where public question identifiers and their updated statuses are displayed.

Both Streamer Studio and Viewer Pulse are part of the FairQueue application. Neither is part of Twitch chat. Twitch chat is the source of incoming questions, while FairQueue manages the accepted-question workflow and displays recorded outcomes.

I designed FairQueue around four principles:

  • Visible intake: Accepted questions receive public identifiers.
  • Chronological presentation: Questions appear in acceptance order without AI ranking.
  • Broadcaster responsibility: Streamers retain control over answering, deferring, or declining questions.
  • Visible outcomes: Viewers can follow recorded statuses.

FairQueue is not just about organizing questions. It is about making the process visible—from acceptance through the broadcaster's recorded decision—so viewers can follow outcomes without taking control away from streamers.

Streamer Studio supports broadcaster review and decisions, while Viewer Pulse exposes public identifiers and statuses without private question text, participant identities, or internal broadcaster notes.

Chronological presentation does not guarantee chronological answering or a response. An Answered status records the broadcaster's decision; it does not independently verify that a spoken answer occurred.

The current MVP does not automatically send acknowledgments or outcome notifications back into Twitch chat.

How I built it

I started developing FairQueue on October 24, 2026, as a solo project with a broader vision for AI-assisted question management.

The original concept included semantic duplicate detection, similar-question suggestions, and broadcaster review of those suggestions. As development progressed, I decided to prioritize a genuine Twitch-to-FairQueue workflow before introducing advanced AI capabilities.

I used OpenAI Codex throughout requirements, architecture, implementation, integration, testing, and debugging.

The application uses TypeScript, Node.js, JavaScript, HTML, CSS, SQLite, Twitch OAuth, Twitch EventSub, and WebSockets.

With Codex's assistance, I developed Twitch question intake, queue handling, Streamer Studio, Viewer Pulse, application lifecycle management, automated verification, UI refinements, and technical documentation.

I defined requirements, made product decisions, approved changes, evaluated test evidence, and determined which features belonged in the MVP.

Codex was my AI development assistant, not an AI inference service running inside FairQueue. Hosted AI semantic duplicate detection is planned for a future phase and is not implemented in the current MVP.

Challenges I ran into

Learning Twitch: I had to understand Twitch from both broadcaster and viewer perspectives, including accounts, authorization, API behavior, EventSub integration, and the demands of managing a live broadcast.

Authentication uncertainty: I encountered questions about public-client Device Code Flow and empty OAuth scopes. Rather than assume the implementation was correct, I posted four technical questions on the Twitch Developer Forum.

On October 28, Barry Carlyon responded with guidance about scope versus scopes, empty scopes, token validation, and zero-scope user tokens for Helix Get Users. He also identified a documentation issue and shared a working reference example.

His guidance improved my understanding, but it did not independently establish that FairQueue's implementation was corrected or provider-conformant. The parameter discrepancy remains documented as unresolved.

Twitch Developer Forum discussion

Live connection reliability: Earlier testing encountered EventSub keepalive and connection-lifecycle failures. Passing automated tests did not guarantee reliable behavior during genuine Twitch sessions.

Privacy and scope: I wanted viewers to follow accepted questions without exposing private information. I also had to make difficult scope decisions within the hackathon timeline.

I deferred advanced AI features and Phase B outbound Twitch messaging to focus on the core inbound workflow. Outbound messaging requires additional API integration, OAuth permissions, security and consent review, and separate end-to-end testing.

Accomplishments that I'm proud of

One of my most meaningful accomplishments was moving from an unfamiliar Twitch development environment to a working, Twitch-integrated prototype.

As a solo developer working with Codex, I brought together several important capabilities:

  • Genuine Twitch question intake: A supported !ask message can enter FairQueue through Twitch EventSub and receive a public question identifier when accepted.
  • Two purpose-built FairQueue interfaces: Streamer Studio supports broadcaster decisions, while Viewer Pulse provides public status visibility. Both belong to FairQueue, not Twitch chat.
  • Transparent question handling: Accepted questions appear chronologically, and their recorded outcomes can be followed without exposing private question content.
  • Human decision authority: The broadcaster retains responsibility for answering, deferring, or declining questions rather than delegating those decisions to AI.
  • Codex-assisted engineering: I developed application logic, integration functionality, automated tests, technical documentation, and structured debugging workflows with Codex's assistance.

During November 1 testing, I reported successful genuine Twitch-to-Studio-to-Pulse workflows using separate broadcaster and participant sessions on one development laptop. Safari supported the broadcaster workflow, and Chrome supported the participant workflow.

I observed a genuine Twitch !ask submission, the accepted question in Streamer Studio, a matching public identifier and status in Viewer Pulse, and a broadcaster-recorded Answered outcome reflected in Viewer Pulse.

These were my reported functional observations, not independently verified video evidence. The bounded sessions ended in timeouts, and sustained EventSub reliability remains unverified.

I am particularly proud of keeping the MVP focused on capabilities that could be implemented and meaningfully tested, while documenting what remains incomplete.

What I learned

FairQueue taught me that understanding a platform and its users is just as important as writing code.

I learned that fairness in live conversations does not mean guaranteeing every answer. It means creating a process people can understand while respecting the broadcaster's judgment.

I also learned the importance of separating different types of technical evidence. Connection readiness, successful event receipt, question acceptance, browser-visible outcomes, and sustained reliability are not interchangeable.

Working with Codex helped me translate requirements into implementation, investigate failures, and refine the application. At the same time, I learned to validate technical assumptions through documentation, developer-community guidance, and testing.

Perhaps the most important lesson was that a focused MVP with explicit boundaries is more valuable than a larger feature set whose behavior cannot be demonstrated reliably.

What's next for FairQueue-Twitch

My immediate priorities are improving Twitch connection reliability, strengthening reproducible setup and verification, and refining the experience in Streamer Studio and Viewer Pulse.

Future development may include:

  • AI-assisted semantic duplicate detection to identify potentially similar questions.
  • Similarity suggestions to help broadcasters review related questions.
  • Broadcaster Review/Dismiss controls for AI-generated suggestions.
  • Phase B outbound Twitch messaging to send acknowledgments and recorded outcomes back into chat, subject to additional integration, OAuth permissions, security, consent, and testing work.

The current MVP remains a receive-only Twitch integration. These enhancements are planned capabilities, not features already implemented.

The project source, automated tests, and technical documentation are maintained in a private GitHub repository for authorized review. Reviewers should follow the repository's setup instructions and use their own authorized Twitch configuration where required. Personal passwords, OAuth tokens, and client secrets are not distributed.

Building FairQueue required learning an unfamiliar platform, understanding different community needs, making difficult scope decisions, seeking developer guidance, and using Codex to turn an idea into a focused prototype.

The journey reinforced the principle that inspired the project: making question handling more visible without replacing human judgment.

FairQueue — Questions in Order, Outcomes in View.

Built With

Share this project:

Updates

Submission history