Devlog #2: @reminder.ping's Refinement, Solving Deployment, and More!

Welcome to part 2 of my journey in developing @reminder.ping, the !RemindMe bot for Hive Blockchain! This Devlog covers the stages I’ve gone through since the first Devlog. If you haven’t yet read the announcement post, check it out here!.

Since the last Devlog, I’ve worked through some big challenges. Mainly regarding deployment error handling, and getting the bot to run smoothly across different environments.

---

---

Stage 1: Improving the Databse - Adding MongoDB

After getting the basics down, I realized the bot needed more structure. I used .csv files for data before. After looking at more than a few options, I introduced MongoDB to store data like reminder times and reply templates. This allowed the bot to work more reliably by fetching stored templates and generating more dynamic, varied replies.

One interesting idea I decided to implement is leaving as little text hardcoded into the code as possible. I created a 'reply_text' collection in MongoDB that holds types of reminders and footers.

When replying, the bot now randomly selects from these, giving it more personality! (More variety to be added.) If MongoDB isn’t available, the bot falls back on default texts stored in the code, keeping the service smooth.

Storing Upcoming Reminders

MongoDB is now central to storing both the reminder details and the templates for replies. I had to refine how the bot interacts with the database—making sure it’s efficient and doesn’t cause delays.

The bot now checks for reminders stored in MongoDB and formats them correctly before sending them as replies to Hive comments. Using this database also allows me to add new features without needing to restructure a csv file.

---

Stage 2: Handling Timestamps

A key improvement was how the bot handles timestamps and compares times for reminders. I tweaked the logic to better capture the time a comment was made and compare it with the current time. It'll know better if the reminder should be sent.

Before, the bot relied on rough comparisons, which wasn’t accurate enough for a reminder service.

---

Stage 3: Solving Deployment – The GitHub Actions Saga

Getting the bot deployed was a big hurdle!

Initially, I considered Heroku, but soon, (after it declined my Debit Card,) I shifted focus to deploying the bot using GitHub Actions, which took a bit of trial and error.

The first roadblock? The bot relied on the RIPEMD160 hashing algorithm, which wasn’t supported by default in my chosen Ubuntu runner for GitHub Actions. This led to frustrating errors about unsupported hash types. I tried several ways to fix this:

1. Manually adding crypto libraries: I tried installing additional libraries through the GitHub workflow, but this didn’t work well. The RIPEMD160 error persisted. I tried for many hours, but all of it failed.

2. Switching system environments: Ultimately, I switched the runner environment from Ubuntu to Windows, which magically solved the problem. This was the breakthrough I needed, as the Windows environment had better support for the required cryptographic methods.

---

---

Stage 4: Improving Failure Handling

After deploying, I wanted to make sure the bot handled errors as they come. If a reminder fails, the bot now attempts the reply up to three times. If all attempts fail, the bot logs the failure for future review. I'm proud of this part, actually, as it ensures the bot's reliability.

---

---

Stage 5: Making the Bot Rage Quit

One issue with my early deployment setup was that the bot would continue running all the time, even when no new blocks were available. It wasn't a problem when I run it on my machine, but it's not good to let a deployed code run for longer than necessary.

I added logic that makes the bot quit when it reaches the last processed block, storing the block number for the next run. This small addition had a big impact, especially for reducing unnecessary resource usage.

---

Stage 6: Automation & Scheduling

Since the bot runs on GitHub Actions now, I needed it to automatically check for new reminders every 10 minutes. To achieve this, I set up a cron job in the GitHub workflow, making the bot run on a schedule. This means I no longer need to worry about manually starting or stopping the bot—it just works in the background, pinging users as scheduled.

---

What’s Next?

The bot has come a long way, it's already running well. All the main features are complete now! However, there are still many ideas I keep contemplating for newer versions.

If there will be a new version, (إن شاء الله.) Here’s a glimpse of what’s coming:

1. Smarter Time Parsing: I want the bot to handle more diverse time inputs. Right now, it should understand most relative and specific time formats, but in the future, it will be able to parse even more casual phrases like "this weekend" or "tomorrow at noon."

2. Adding Context to Reminders: Soon, users will be able to specify what the reminder is for. Instead of just getting a reminder ping, the bot will tell you exactly why you asked for it. This will make the reminders more useful and personalized.

3. User Blacklisting: For users who prefer not to be pinged by the bot, I’ll add a way to blacklist themselves from all or specific replies. This is important for respecting users' preferences and making sure the bot doesn’t become a nuisance.

4. Paid Features: In the future, I plan to introduce a subscription service with premium features:

   • Tagging Other Users: Subscribers will be able to tag other users in reminders (behind a paywall to avoid spam).
   • Listing Upcoming Reminders: Paid users will have the ability to view all of their upcoming reminders stored in the database.
   • Reminders via HIVE Transactions: Instead of receiving reminder pings in comments, users will have the option to get reminders via HIVE transactions, which will be a paid feature due to the 0.001 HIVE transaction fee.

5. Challenging Features: There are some advanced features I’m considering, though they’ll be tricky to implement:

   • AI-Generated Replies: It would be awesome for the bot to vary its reminder responses using AI, making them more dynamic and personalized.
   • Editing and Deleting Reminders: Giving users the ability to modify or delete their reminders would be a huge upgrade, though it’s a challenge to implement this functionality properly.

These improvements will make @reminder.ping even more robust and user-friendly, offering more flexibility and personalization options for the Hive community. Stay tuned as I continue refining and expanding the bot!

If you have any other suggestions, comment them below. I'd love to hear them!!

Thanks for Reading

Thanks for following along on this development journey! I’m excited about what’s to come. Stay tuned for more updates!

---

^{This article was co-written with ChatGPT. The post's image was generated with Ideogram!}

Posted Using InLeo Alpha