Spectralis devlog #3
—Hello again proggers—
Back at it. This round wasn’t visualizer polish or UI cleanup, it was Song Wars/SQ backend stuff and a Discord bot that didn’t exist yesterday. Less “make it pretty,” more “make it not lie to people.”
Cat or dog? AcceptingSubmissions
print(f”I try to make stu{2f} which {actually_closes} {2day}”)
Okay let’s get into it~
—Yap—
Turns out “turn off the fee toggle” and “actually prevent the fee-gated action” are two different things, and I had only been doing the first one. Also built an entire close-queue flow because apparently streamers want to stop taking requests sometimes, which, fair. And then there’s a Discord bot now. That happened too.
scope creep? never heard of her
—The Great Suffering—
1 — The Free Skip Loophole
Turning off “Skip fee” or “Super Skip fee” removed the option from the public request page (sq.html/sq.js) just fine. What it did NOT do was stop the backend from accepting skip/super-skip attempts anyway — submit, upload, promote, all of it. Toggle says no, server says sure why not. Backend now actually rejects those attempts when the toggle’s off, closing the gap where a disabled tier was quietly still free.
the frontend was lying and the backend believed it
Still preserved: turning a toggle ON with a $0 amount is a real, intentional free tier. That distinction stays.
2 — Close Queue Didn’t Exist
There was a “Queue enabled” toggle, but no way to just… stop taking requests without digging into settings. Added a real AcceptingSubmissions flag, separate from that, plus a one-click “Close Queue”/“Reopen Queue” button right next to “Copy Submit URL” in the header. No settings menu detour required.
When closed, the public page still shows now-playing and queue count, just hides the request/skip/super-skip forms behind a “requests are closed” banner. Streamer can keep browsing and playing from the existing queue the whole time, since the app’s queue view was never gated on “enabled” to begin with.
3 — Now Playing Was Just Empty This Whole Time
Found this one by accident while wiring Close Queue: the public page’s “Now Playing” section never actually populated for anyone who wasn’t the owner, because the backend just wasn’t sending track info to non-owner viewers. Fixed alongside everything else.
4 — A Discord Bot Shows Up
New discord-bot/ folder, Node.js + TypeScript, discord.js, with a full PLANNING.md for the design: PIN-based pairing so the streamer generates a short-lived PIN in-app and runs /link-queue in Discord with no secrets ever touching chat, a scoped bot-token concept kept separate from the full owner token, and a (guildId, channelId) → room mapping so one bot instance can serve many servers.
/queue, /request, /skip, /superskip are fully wired against the existing public SQ API and build clean. /link-queue, /close-queue, /open-queue are stubbed with TODOs since they need backend PIN/token endpoints that don’t exist yet, which is now the next backend work item.
Everything typechecks and builds clean across the board — Rust release build, Spectralis.App, and the bot’s tsc.
—FAQ (no one asked these but they are here)—
Q: Why does Spectralis need a Discord bot?
A: Because apparently the request queue living only on a web page wasn’t enough surface area. Now it can also live in your server.
Q: What’s PIN-based pairing?
A: Streamer gets a short-lived PIN in-app, runs one Discord command with it, done. No tokens or secrets ever posted in chat.
Q: Anything left over from last devlog?
A: Chat template drift is still an EDITH problem, not a Spectralis one. Wrong repo, wrong devlog.
—This is the end*—
*end for now, PIN endpoints permitting
PIZZA!!!