|
12432
|
SlackyssaLiu - Slack Bot by @AidenHammy | Stardanc SlackyssaLiu - Slack Bot by @AidenHammy | Stardance...
|
AidenHammy
|
1
|
7.39
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-08T12:42:18Z", "hours": 4.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "Started as a standard “first Slack bot” with catfacts, jokes, quotes, the usual starter-project stuff. It was redesigned into something actually worth using. A space-themed bot that tracks the ISS in real time, counts down to the next rocket launch, posts NASA’s daily astronomy photo (with zero effort on your part) and pulls random Mars rover photos on demand. It also remembers things now. SQLite-backed mission logs per channel and custom callsigns per user and shows up uninvited with scheduled posts instead of only responding when poked. Built with Node.js + Slack Bolt (Socket Mode, no public URL needed), SQLite for persistence, node-cron for scheduling and free APIs (Open Notify, NASA, Launch Library 2) for the live data. Deployed and running 24/7 on Hack Club Nest.", "repo": "https://github.com/AidenHammy/SlackyssaLiu", "demo": "https://hackclub.enterprise.slack.com/archives/C0P5NE354"}]...
|
[{"post_id": 67226, "ts": "202 [{"post_id": 67226, "ts": "2026-09-13T08:58:32Z", "hours": 3.3922, "text": "Devlog 3: Three Hours of My Life I’m Never Getting Back (And Slack’s Media Renderer Can Thank Me For It) The false confidence I thought the bot was done. I really did. The commands worked, the database was syncing, the cron jobs were firing. It was a fully functional space bot. I sat down to do what I thought would be a 15-min final polish before shipping. Three hours later, I was found questioning my reality and whether I should just delete the folder and take up farming. What started as a quick polish turned into a full-blown war against dead community APIs, Slack’s deeply picky Block Kit renderer and the absolute garbage fire that is Node.js DNS resolution on free hosting platforms. The dead API saga First, /skl-mars completely died. Not a graceful failure. Not a friendly JSON error. It just silently redirected to a GitHub Pages 404 HTML page. Axios, bless its optimistic little heart, tried to parse that HTML as JSON, choked and took the whole bot down with it. I made the executive decision to ditch that entirely. The rover is probably tired of taking photos anyway. I swapped it out for NASA’s EPIC API, which takes photos of Earth from the DSCOVR satellite. But EPIC had its own trap. If you just ask for the “most recent” photos, it returns a tiny array of about 13 photos from the last active day. The bot kept spamming the exact same image of Earth. I had to rewrite the endpoint to fetch the archive of all available dates, shuffle the entire history of the satellite and pull a random day from the past just to get some variety. Then, the Open Notify API (used for ISS location and crew data) went offline too. Same GitHub 404 redirect. I had to write nested try/catch fallbacks with 5-second timeouts to route requests to wheretheiss.at just to keep the telemetry commands alive. It was a war of attrition against community-run infrastructure. Slack Block Kit & the APOD nightmare Getting the APOD (/skl-apod) to actually render in the chat was an absolute nightmare. Originally, the bot just dropped a raw URL into the chat. Slack looked at it and said “Cool link, not displaying it” so I rebuilt the command using Slack’s Block Kit image block. That fixed images. But.. a video? Because of course, if you pass an .mp4 URL into an image block, Slack silently drops the message entirely. I had to write logic to check the media_type: if it was a YouTube link, I parsed the URL and rendered it using Slack’s native video block. If it was a raw .mp4, I had to stream the video file directly into Slack using filesUploadV2 so it would embed and play right in the chat. And to prevent the bot from OOM-crashing the server on large videos, I had to use responseType: \"stream\" so it chunked the download instead of loading a 50MB video into RAM all at once. The Nest hosting quirk Right when I thought I was victorious, APOD and Earth started failing with getaddrinfo ENOTFOUND api.nasa.gov . After staring at my screen wondering if I had forgotten how URLs work, I learned that Node.js 17+ defaults to IPv6 for DNS resolution and the hosting platform (Nest) doesn’t fully support IPv6 routing. The server literally couldn’t find NASA. Adding dns.setDefaultResultOrder('ipv4first') to the top of the service file fixed it instantly. Extremely normal behavior, I love computers. The actual architecture shift Amidst all the API firefighting, I also ripped out the hardcoded .env channel routing. Making someone edit a .env file just to move a bot to a new channel is a crime. I moved the scheduled announcements to a SQLite-backed system with /skl-setup and /skl-unset commands so the bot could support multiple servers dynamically without touching environment variables. What started as a simple script turned into a much more reliable bot with backup APIs, saved data, scheduled posts and the ability to handle images and videos directly in Slack. It was hella exhausting, my brain is completely fried but atleast it’s done."}, {"post_id": 64173, "ts": "2026-09-08T12:10:49Z", "hours": 2.9514, "text": "Devlog: SlackyssaLiu Went to Space (and I Forgot to Write Any of This Down) The itch SlackyssaLiu started as a pretty standard first Slack bot. Slash commands, a few API wrappers, the usual suspects: catfacts, jokes, quotes, echo, ping, some sneeze/wave filler commands for personality. It worked fine. It also looked exactly like every other “my first slackbot” project out there because it basically followed the same recipe everyone does. Integrate a joke API, integrate a weather-adjacent API, call it done. I wanted to know how to make it stand out so I asked around for ideas. The answer was pretty obvious in hindsight. Stop building the demo everyone builds and build something around an actual theme with actual state instead of a stateless command list wrapped around whatever free API came up first. I bounced between a few themes.. figure skating (RIP, no usable free API), medieval history (also no API, just Wikipedia scraping, hard pass) and space. Space won because it had exactly what I needed. Solid free APIs with no bureaucracy (Open Notify needs zero auth, NASA’s API just needs a free key) and enough surface area to build something that actually feels alive instead of just answering when poked. What actually changed This ended up being a full redesign not a patch job. Rough shape of it (RIP to /skl-achoo, you were doing your best). Killed the old command set! No more catfact/joke/quote/echo/achoo/wave. None of it fit the new direction and it was the generic stuff I was trying to get away from in the first place. A moment of silence for the bot that could sneeze but not tell you when a rocket was launching. New space-themed commands: /skl-iss and /skl-crew (Open Notify, no key needed), /skl-launch (Launch Library 2, with an actual countdown for maximum dramatic tension), /skl-apod and /skl-mars (NASA’s API, APOD + random Curiosity rover photos the rover did not consent to being featured but also cannot complain). Added actual persistence. SQLite via better-sqlite3. This was the real shift. The old bot had the memory of a goldfish with amnesia. It never remembered anything between requests. Now it tracks mission logs per channel, user callsigns and which launches it’s already announced (so it doesn’t spam the same countdown twice like an overeager intern). Added scheduled behavior. node-cron jobs that post NASA’s picture of the day every morning and ping the channel when a launch is within the hour. This is the part I think actually makes it feel like a running thing instead of a command list. It does stuff without being asked which is more initiative than I show most mornings. I gave it an actual personality module! pulled every joke/flavor line out of the command handlers and centralized them in personality.js. Went through two tone passes because apparently I couldn’t decide if the bot should sound like a stoic AI from a space movie or like it’s been on Twitter since 2019. It landed somewhere in between and honestly that’s a personality a lot of people have. Having it centralized meant the whole voice-swap was a single-file change instead of hunting through every command like a raccoon going through someone’s trash. Fixed real bugs from the original file along the way, typos that would’ve crashed the bot. cool, cool, very cool, glad I caught that before it caught me. Why I forgot to log any of this Short version, I was moving fast across a lot of files at once. db setup, service wrappers, command rewiring, personality, scheduler and treated it like “just get it working” instead of “document as I go”. I was working on a lot of projects at the same time and this was something I did just after finding about Stardance so I barely remembered to ship it. But I’m doing so now, several weeks late, riding in on a horse made of retroactive commit messages. I barely had any brainpower left for side projects at 1am because of my “awesome” uni."}, {"post_id": 5868, "ts": "2026-06-09T20:22:36Z", "hours": 1.3881, "text": "Devlog 1 — Building SlackyssaLiu (Slack Bot) What I set out to build: Create a simple Slack bot that can respond to slash commands in real time and make interactions inside a workspace more dynamic and useful. How I approached it: I started by following Stardance’s mission guide to understand how Slack apps connect to a backend and handle real-time events. After setting up the base bot with Socket Mode and environment variables, I focused on implementing slash commands and structuring them in a clean and scalable way. What I built: A deployed Slack bot running 24/7 with real-time command handling A working Slack bot using Node.js and the Bolt framework Multiple slash commands such as: /skl-ping for latency checking /skl-echo for message reflection /skl-time and /skl-date for utility /skl-help for command discovery API integrations: Cat facts using an external API Random jokes Inspirational quotes Basic error handling for API failures A consistent command-response structure using async functions Deployment: The bot is deployed and runs continuously 24/7, allowing it to respond to Slack commands in real time without requiring a local environment. This helped me understand how to keep services running beyond development and make the bot usable in a live workspace. What I learned: How Slack’s Bolt framework handles commands and events The importance of ack() in Slack interactions How to structure asynchronous command handlers How to integrate external APIs into a Node.js application How to handle failures gracefully using try-catch Challenges I faced: Understanding how Slack’s command lifecycle works Managing async responses correctly without breaking Slack’s timing requirements Debugging API responses and ensuring consistent formatting What I improved beyond the mission guide: While the initial setup followed Stardance’s mission guide, I expanded the bot by adding multiple custom commands and integrating external APIs to make it more interactive and useful. Future improvements: Add command history or logging Introduce smarter responses or context awareness Improve response formatting for better readability Expand the command set with more utility features Final thoughts: This project helped me understand how real-time systems work and how to build something that interacts with users in a live environment. It started with guided steps and evolved into a customizable and extendable Slack bot."}]...
|
Title: SlackyssaLiu - Slack Bot by @AidenHammy | S Title: SlackyssaLiu - Slack Bot by @AidenHammy | Stardance
Devlogs:
Devlog 1 — Building SlackyssaLiu (Slack Bot) What I set out to build: Create a simple Slack bot that can respond to slash commands in real time and make interactions inside a workspace more dynamic and useful. How I approached it: I started by following Stardance’s mission guide to understand how Slack apps connect to a backend and handle real-time events. After setting up the base bot with Socket Mode and environment variables, I focused on implementing slash commands and structuring them in a clean and scalable way. What I built: A deployed Slack bot running 24/7 with real-time command handling A working Slack bot using Node.js and the Bolt framework Multiple slash commands such as: /skl-ping for latency checking /skl-echo for message reflection /skl-time and /skl-date for utility /skl-help for command discovery API integrations: Cat facts using an external API Random jokes Inspirational quotes Basic error handling for API failures A consistent command-response structure using async functions Deployment: The bot is deployed and runs continuously 24/7, allowing it to respond to Slack commands in real time without requiring a local environment. This helped me understand how to keep services running beyond development and make the bot usable in a live workspace. What I learned: How Slack’s Bolt framework handles commands and events The importance of ack() in Slack interactions How to structure asynchronous command handlers How to integrate external APIs into a Node.js application How to handle failures gracefully using try-catch Challenges I faced: Understanding how Slack’s command lifecycle works Managing async responses correctly without breaking Slack’s timing requirements Debugging API responses and ensuring consistent formatting What I improved beyond the mission guide: While the initial setup followed Stardance’s mission guide, I expanded the bot by adding multiple custom commands and integrating external APIs to make it more interactive and useful. Future improvements: Add command history or logging Introduce smarter responses or context awareness Improve response formatting for better readability Expand the command set with more utility features Final thoughts: This project helped me understand how real-time systems work and how to build something that interacts with users in a live environment. It started with guided steps and evolved into a customizable and extendable Slack bot.
Devlog: SlackyssaLiu Went to Space (and I Forgot to Write Any of This Down) The itch SlackyssaLiu started as a pretty standard first Slack bot. Slash commands, a few API wrappers, the usual suspects: catfacts, jokes, quotes, echo, ping, some sneeze/wave filler commands for personality. It worked fine. It also looked exactly like every other “my first slackbot” project out there because it basically followed the same recipe everyone does. Integrate a joke API, integrate a weather-adjacent API, call it done. I wanted to know how to make it stand out so I asked around for ideas. The answer was pretty obvious in hindsight. Stop building the demo everyone builds and build something around an actual theme with actual state instead of a stateless command list wrapped around whatever free API came up first. I bounced between a few themes.. figure skating (RIP, no usable free API), medieval history (also no API, just Wikipedia scraping, hard pass) and space. Space won because it had exactly what I needed. Solid free APIs with no bureaucracy (Open Notify needs zero auth, NASA’s API just needs a free key) and enough surface area to build something that actually feels alive instead of just answering when poked. What actually changed This ended up being a full redesign not a patch job. Rough shape of it (RIP to /skl-achoo, you were doing your best). Killed the old command set! No more catfact/joke/quote/echo/achoo/wave. None of it fit the new direction and it was the generic stuff I was trying to get away from in the first place. A moment of silence for the bot that could sneeze but not tell you when a rocket was launching. New space-themed commands: /skl-iss and /skl-crew (Open Notify, no key needed), /skl-launch (Launch Library 2, with an actual countdown for maximum dramatic tension), /skl-apod and /skl-mars (NASA’s API, APOD + random Curiosity rover photos the rover did not consent to being featured but also cannot complain). Added actual persistence. SQLite via better-sqlite3. This was the real shift. The old bot had the memory of a goldfish with amnesia. It never remembered anything between requests. Now it tracks mission logs per channel, user callsigns and which launches it’s already announced (so it doesn’t spam the same countdown twice like an overeager intern). Added scheduled behavior. node-cron jobs that post NASA’s picture of the day every morning and ping the channel when a launch is within the hour. This is the part I think actually makes it feel like a running thing instead of a command list. It does stuff without being asked which is more initiative than I show most mornings. I gave it an actual personality module! pulled every joke/flavor line out of the command handlers and centralized them in personality.js. Went through two tone passes because apparently I couldn’t decide if the bot should sound like a stoic AI from a space movie or like it’s been on Twitter since 2019. It landed somewhere in between and honestly that’s a personality a lot of people have. Having it centralized meant the whole voice-swap was a single-file change instead of hunting through every command like a raccoon going through someone’s trash. Fixed real bugs from the original file along the way, typos that would’ve crashed the bot. cool, cool, very cool, glad I caught that before it caught me. Why I forgot to log any of this Short version, I was moving fast across a lot of files at once. db setup, service wrappers, command rewiring, personality, scheduler and treated it like “just get it working” instead of “document as I go”. I was working on a lot of projects at the same time and this was something I did just after finding about Stardance so I barely remembered to ship it. But I’m doing so now, several weeks late, riding in on a horse made of retroactive commit messages. I barely had any brainpower left for side projects at 1am because of my “awesome” uni.
Devlog 3: Three Hours of My Life I’m Never Getting Back (And Slack’s Media Renderer Can Thank Me For It) The false confidence I thought the bot was done. I really did. The commands worked, the database was syncing, the cron jobs were firing. It was a fully functional space bot. I sat down to do what I thought would be a 15-min final polish before shipping. Three hours later, I was found questioning my reality and whether I should just delete the folder and take up farming. What started as a quick polish turned into a full-blown war against dead community APIs, Slack’s deeply picky Block Kit renderer and the absolute garbage fire that is Node.js DNS resolution on free hosting platforms. The dead API saga First, /skl-mars completely died. Not a graceful failure. Not a friendly JSON error. It just silently redirected to a GitHub Pages 404 HTML page. Axios, bless its optimistic little heart, tried to parse that HTML as JSON, choked and took the whole bot down with it. I made the executive decision to ditch that entirely. The rover is probably tired of taking photos anyway. I swapped it out for NASA’s EPIC API, which takes photos of Earth from the DSCOVR satellite. But EPIC had its own trap. If you just ask for the “most recent” photos, it returns a tiny array of about 13 photos from the last active day. The bot kept spamming the exact same image of Earth. I had to rewrite the endpoint to fetch the archive of all available dates, shuffle the entire history of the satellite and pull a random day from the past just to get some variety. Then, the Open Notify API (used for ISS location and crew data) went offline too. Same GitHub 404 redirect. I had to write nested try/catch fallbacks with 5-second timeouts to route requests to wheretheiss.at just to keep the telemetry commands alive. It was a war of attrition against community-run infrastructure. Slack Block Kit & the APOD nightmare Getting the APOD (/skl-apod) to actually render in the chat was an absolute nightmare. Originally, the bot just dropped a raw URL into the chat. Slack looked at it and said “Cool link, not displaying it” so I rebuilt the command using Slack’s Block Kit image block. That fixed images. But.. a video? Because of course, if you pass an .mp4 URL into an image block, Slack silently drops the message entirely. I had to write logic to check the media_type: if it was a YouTube link, I parsed the URL and rendered it using Slack’s native video block. If it was a raw .mp4, I had to stream the video file directly into Slack using filesUploadV2 so it would embed and play right in the chat. And to prevent the bot from OOM-crashing the server on large videos, I had to use responseType: "stream" so it chunked the download instead of loading a 50MB video into RAM all at once. The Nest hosting quirk Right when I thought I was victorious, APOD and Earth started failing with getaddrinfo ENOTFOUND api.nasa.gov . After staring at my screen wondering if I had forgotten how URLs work, I learned that Node.js 17+ defaults to IPv6 for DNS resolution and the hosting platform (Nest) doesn’t fully support IPv6 routing. The server literally couldn’t find NASA. Adding dns.setDefaultResultOrder('ipv4first') to the top of the service file fixed it instantly. Extremely normal behavior, I love computers. The actual architecture shift Amidst all the API firefighting, I also ripped out the hardcoded .env channel routing. Making someone edit a .env file just to move a bot to a new channel is a crime. I moved the scheduled announcements to a SQLite-backed system with /skl-setup and /skl-unset commands so the bot could support multiple servers dynamically without touching environment variables. What started as a simple script turned into a much more reliable bot with backup APIs, saved data, scheduled posts and the ability to handle images and videos directly in Slack. It was hella exhausting, my brain is completely fried but atleast it’s done.
Ships:
Started as a standard “first Slack bot” with catfacts, jokes, quotes, the usual starter-project stuff. It was redesigned into something actually worth using. A space-themed bot that tracks the ISS in real time, counts down to the next rocket launch, posts NASA’s daily astronomy photo (with zero effort on your part) and pulls random Mars rover photos on demand. It also remembers things now. SQLite-backed mission logs per channel and custom callsigns per user and shows up uninvited with scheduled posts instead of only responding when poked. Built with Node.js + Slack Bolt (Socket Mode, no public URL needed), SQLite for persistence, node-cron for scheduling and free APIs (Open Notify, NASA, Launch Library 2) for the live data. Deployed and running 24/7 on Hack Club Nest....
|
1793339398.8512018
|
1793425798.8512018
|