VOIDBOT

Devlog, Defeating Cloud Runtime Errors, Bypassing Local Constraints, and Achieving 100% Production Status

This is the latest version of VOIDBOT. It began as a local Python script and has now been successfully transformed into a fully operational cloud-based service.

Here’s how we overcame the final deployment issues today:

1. The Local Environment Shift:
   I encountered a conflict when moving my work to my main Windows workstation. Virtual environments (.venv) cannot be transferred across different systems due to OS-specific binaries. I erased the old directory and set up a clean Windows environment, reinstalling ‘slack-bolt’, ‘python-dotenv’, and ‘websocket-client’.

2. Namespace Protection and Anti-Collision:
   To ensure smooth operation within Hack Club’s large workspace, I changed all listener annotations to use a unique prefix (/vt-). Commands like /vt-ping, /vt-about, and /vt-voidtune are now linked to my bot layer without clashing with other active services.

3. Strengthening Repository Security:
   I created a specific .gitignore file to keep the physical .env variables on my local disk, completely removing any risk of exposing cloud credentials on my GitHub repository.

4. Fixing the Hugging Face ‘Runtime Error’ and Network Proxies:
   When moving to Hugging Face Spaces (using a custom Dockerfile), the instance crashed due to failing the cloud infrastructure’s automatic network health checks. Since Socket Mode requires a constant outgoing WebSocket connection, it does not allow an open HTTP port. To fix this:

• I modified main.py to create a secondary asynchronous thread (threading.Thread).
• I built a simple internal health checking system using Python’s native HTTPServer on port 7860.
• This kept the cloud supervisor satisfied while allowing the main Bolt engine to communicate smoothly with Slack in the background.

1. Managing Dynamic Configurations:
   I updated config.py with a check to see if the required variables are already in the cloud system’s environment memory. If they are found, it skips the .env parsing and continues the system execution.

Result: The space is now stable and in a permanent green “Running” state. The bot handles live channel interactions, processes async commands, logs activity timestamps, and operates 24/7 without needing my home PC online.

VOIDBOT is ready. Next stop: WebOS!

Implementing Socket Mode, Git Protections, and 24/7 Cloud Deployment

Today I made a massive leap forward and fully finalized the infrastructure requirements for VOIDBOT, transitioning it into a professional, production-ready environment.

Here is the breakdown of this coding session:

1. Environment Synchronization & Testing: Moved the project over to my main Windows machine. Experienced the non-portability of virtual environments firsthand, which pushed me to wipe the Linux-based .venv and re-architect a native Windows virtual environment from scratch.
2. Local GUI Experiments: Successfully verified Python script execution and keyboard interactivity on my main OS by writing a quick standalone test interface (test_gui.py) using Tkinter.
3. Code Refactoring & Pre-Collision Guard: Refactored the core commands inside main.py to use a custom prefix (/vt-), ensuring my bot runs independently on the Hack Club workspace without command collisions. Added missing callback acknowledgments (ack()) to optimize the runtime.
4. Security Best Practices: Implemented a robust .gitignore file to permanently isolate my .env configuration file locally on my hardware, blocking accidental leaks of sensitive API credentials.
5. 24/7 Cloud Deployment: Generated a modular requirements.txt list and successfully committed the source code repository to GitHub. Configured a continuous deployment pipeline using a free Background Worker on Render. Injected the secure Slack variables (SLACK_BOT_TOKEN, SLACK_SIGNING_SECRET, SLACK_APP_TOKEN) natively into Render’s memory space, keeping the application live 24/7 even when my main rig is powered off.

With all 4 strict submission requirements met, the pipeline is green and I’m ready to ship the project to the peer review stage!

Building a Solid Architecture & Custom Logger for VOIDBOT

Today I spent a solid hour setting up the foundations for VOIDBOT. Since I have no prior experience building Slack bots, I wanted to make sure the project structure was robust right from the start instead of just packing everything into a single file.

Here is what I achieved during this coding session:

1. Setup and modularity: Created a dedicated config.py file to handle environment variables automatically. If the .env file is missing, the script generates a template setup by itself to prevent crashes.
2. Main Engine: Configured main.py using the Slack Bolt framework in Python. Tied it directly with the configuration module to keep the tokens clean and secure.
3. Custom Utility: Coded a custom logging module (logger.py) from scratch. It captures accurate timestamps using Python’s datetime library and appends command usage and user IDs into a local activity.log file whenever a command is triggered.
4. Core Requirements: Fully structured the 3 mandatory slash commands (/ping, /about, and /voidtune) with strict adherence to Slack’s 3-second acknowledgement rule.

Everything is pushed to my GitHub repository, and my Hackatime is running smoothly. Ready to tackle the Slack API portal and credentials next!