GloveBot Part 1. Under the Hood.
A complete tour of a Solana Telegram Bot's System Architecture
Hi! I’m honored you found this. But it’s not quite ready yet. Maybe check back at the end of the week?
Context
Starting in July of 2023, I took on what was easily my most ambitious task to date.
Like a lot of other people, I was waiting out the bear market by trying my hand at picking the next up-and-coming meme coins, at first on Ethereum and later through Solana. I realized quickly that doing transactions through my PC and checking my portfolio through Metamask, Zerion, or whatever I happened to have downloaded on my phone at the time was NOT going to do. With OHM it was cool, but these tokens were another story. Narratives would get spun up at 10 pm and be completely gone by 5 am the next day. Execution speed seemed to be by far the most important thing.
Hanging out on Twitter, I found people having all sorts of success sniping token launches using Telegram trading bots like Unibot and BananaGun.
My friends gave me the full tour, how to set gas limits, how to find the good TG groups and eventually how to bribe my way onto pink-sale lists, the whole nine yards.
I like to think of myself as about average as a trader, caught some 10x’ers but also paid my dues with some projects rugging and leaving me going from $100 → $0.003 in a single candle of pure heartbreak. But unlike previous times in the “trenches,” I found much more fun on this run-through. Mainly because of these awesome Telegram bots! All I need is to text it a contract address, and it buys it all for me? What!
As I looked closer into the tech & people behind these strange and convenient Telegram trading bots, I heard about BonkBot: A company providing the exact same Telegram service on Solana. This company also happened to burn the Bonk meme token, leveraging the entire community for insane marketing power, and was created over the span of a short hackathon! I got super curious. I’ve always been pretty early to trends, and I thought that creating a competitor to BonkBot would not only be super feasible but fun! If they could do it, surely I could too!
So I got working.
Here’s what happened.
This will be my attempt to log the entire process of building a Telegram trading bot.
*This entry tells the story from the beginning (July 2023, to Feb 2024)
There are updates after this point found in other articles tagged “GloveBot”
PHASE 1. THE MVP
This is always my favorite part.
The MVP stages are generally the same for my projects.
I just have to meet two simple goals.
Do people ACTUALLY want this?
This is deceptively simple, but people always miss this. We’re trying to convert people from a “Yeah, that would be nice to have” to “I use this every day/I always reach for this when I’m in XYZ situation”
The MVP doesn’t have to reach that level; it should show that the concept COULD trend in a direction where that would be possible.
Can we get this working? Like…at all.
Sometimes, problems are so ludicrously out of scope for my skill set that I have to abandon the project altogether. Don’t get me wrong, I’m not one to shy away from a challenge. But once in a while, I’ll do some initial scoping of the MVP and realize that it needs some insane Computational Power, Private/Hard to Scrape Data, or Knowledge that is just so far out of bounds and interest that it forces me to look for greener pastures.
This seemed like a manageable challenge.
So, on July 23, 2023, I decided to make the best Telegram Trading Bot on the market.
Back in July, I had decided on the name “Thunderbot” because it sounded sick.
I later found out there are about 10 million separate applications named Thunderbot (and it also autocorrects to “ThunderBolt”), both of which are TERRIBLE for SEO, so at some point, I changed the name. I also decided to get the bot working for Ethereum first, as I assumed there was more documentation and support for ETH applications over Solana.
Here is a screenshot from the very first document of GloveBot:
I had a basic vision, broke it into daily goals, and kept track of what goals I set out for that day. At the end of each day, I logged whether I accomplished them or not, and if I didn’t complete them, I logged what stopped me to give hints to my future self.
My first big accomplishment was getting a Flask server set up on AWS. This was weirdly difficult, as I was mainly used to AWS systems being *somewhat* in place wherever I happened to work, and I just had to hop in to tweak some settings. AWS is a pain. But after a bit of research, I came to the realization that most other developers do: integration with all other AWS services, and the incredibly small possibility that this becomes a real app with serious traffic was worthy of wrestling with possibly the worst user experience on the planet.
Okay, now we’ve finally got the server working. How do we interface with Telegram?
It’s a bit more nuanced than I thought, and it took me a few days to fully understand.
For those of you who don’t know the ins and outs of how messages are handled, a message never ACTUALLY goes straight to your phone. Messages sit on Telegram’s servers and Telegram manages user delivery.
This is super useful. Imagine situations where your phone is off, has a spotty connection, or even if it’s in some super aggressive Do Not Disturb mode. Telegram can just sit on the message. Then, when the app decides it’s a good time to send it to the user, it just delivers it. It also manages delivery confirmation, read receipts, and other headaches your average developer would rather not be involved with. When the user responds, Telegram ALSO figures out Username → Internal User ID mapping, graphic content checks, and I’m sure a trillion other edge cases we don’t have to worry about. The only thing we care about is that Telegram decides if/when/how to alert our services of a user’s message to our bot.
This was slightly different from how I thought it worked. I assumed that when chatting with a “Bot,” the User’s phone directly dumped raw data into the Bot’s servers. The developer’s servers and external services they chose to call were responsible for managing message history, coming up with responses, and eventually responding to the user.
It’s a subtle difference but a SUPER important one. I was getting continually frustrated because I was looking for solutions for how to “store messages” or “connect to users’ phones” via Telegram. With the wrong mental model, my searches were leading nowhere, and I couldn’t exactly understand what a “Bot” was. Much less how to build even the most basic Hello World bot.
I stumbled upon the Python Telegram Bot (PTB) codebase, which had some wonderful examples, but even going through all the basic examples, this solution wasn’t exactly clear to me.
PTB showed that it was possible to get Hello World running on a bot via a CLI and basic app. However, until we hit the advanced tutorials where they used Starlette (an async web server library in Python), the actual “Server” was frustratingly hidden. I had NO CLUE where my requests were going or how they were coming back, but it was technically my first Telegram Hello World!
The Starlette Tutorial opened my eyes to the truth.
The biggest issue facing this was the way that Telegram’s servers were called. Now that they weren’t being abstracted away, they became pedantic and demanding. They needed my little “Hello World” calls to be cloaked in the secure garden of HTTPS, and my Flask EC2 was the opposite of secure.
The solution to this was kind of involved, but I ended up being grateful for the complexity, as it made things easier later.
We set up AWS ROUTE 53™
We set up NGROK™
Again, this is much easier said than done. I don’t remember my exact issues with this; I might have blacked out. But it did end after multiple arguments with ChatGPT, strange config files, and a folder deep in Unix that I was afraid ever to touch again.
Lucky for us, kicking and screaming, we were able to spin up Ngrok and our Flask server. What do you know? We’re in business.
The next step was modifying the Flask app from a thing that sits on the server shouting “HELLO WORLD!” to an app that can send something to the user via a web-hook (which I now learned Telegram uses to keep external servers in the loop, this is the basis of all “Bot” like entities on Telegram, and I suspect most other platforms as well)
After we reached this point, it became pretty normal software development for a bit,
Next, we need to make the app do what we promised the users.
Let’s have it trade crypto!
But wait…
Before we even get to that… This one server is doing a lot of stuff. Isn’t it?
Even at this MVP phase, it’s going to be responsible for:
Managing User’s Sign Ups
Talking to a Database (DB)
Handling Private Keys
(Talking to a…more secure DB?)
Checking Balance
(Calling the blockchain)
Displaying the Menu
Calling some sort of Cache, so we DON’T have to talk to the blockchain every time someone does /menu
Handling Buys/Sells
(Calling the blockchain, waiting, confirming, returning result)
This seems like a lot.
I have big dreams. Milliseconds matter in trading, and what if 100,000 people try to trade at once? The server was going down; I just knew it.
There were a few options to consider. It didn’t technically matter right now, as I was my only user, and this was STILL MVP phase, but this seemed like the type of thing to decide early, as it sort of decides the direction and informs a lot of the technical decisions down the line.
We had a few directions we could go.
Get a bigger server. Duh.
This would have been the easiest option for sure. But I couldn’t really think of any companies that handled significant loads that did this. After some research, all the large examples that had “Monolithic” style architectures (Early Amazon, Netflix before streaming, Shopify) eventually moved to Microservices or such complex solutions within a Monolith that it might as well be a Microservice (Looking at you, Shopify)
Serverless?
Can I just shove Lambdas or GCloud functions everywhere? Maybe. It seemed like Coca-Cola was having a wonderful time with it. And that kind of makes sense. At a company where they just need tech to “Work,” why not outsource all DevOps to the big guys?
But they seemed super expensive? I’m not Coca-Cola. And without being able to model exactly what “Load” could look like for my app, I couldn’t even begin to estimate the cost of what it would be. A traditional server would at least have more transparent costs. And in all honesty, I’m not exactly building a mission-critical system. I’d rather it crash than get stuck with an eye-watering bill.
What about MicroServices?
It’s the “Hot” tech right now. But it seemed like it was for a good reason.
Certain parts of your apps are going to get hit more often than others. Certain parts of your app have more expensive functions to run and completely different jobs touching vastly different external services. If a server breaks down in a properly designed system, we may just be able to spin up another one before anybody notices or maintain core functionality if a new feature breaks!
I wasn’t too well versed in Microservices.
I had worked on individual systems at companies that I vaguely knew talked to other systems, but deciding what talked to what was someone else’s job. As long as I stayed to the correct function signatures, nobody got hurt.
Even though I was essentially sentencing myself to what I assumed was DevOps hell, my use case seemed like it deserved a fair shot at it. After all, this is pretty much exactly the sort of situation Microservices were meant for.
Luckily, for the price of $42.71, I can become an expert.
Phase 2. The Hive.
This post is not finished. Here’s the memes I’m planning to use for the future sections.
