How do you horizontal-scale MySQL?

Scale AI's Public Document Blunder: Security Is a Mindset, Not a Checkbox

So, news dropped: Scale AI had thousands of confidential client documents (Meta, Google, xAI) publicly exposed via shared Google Docs links. Sounds like a rookie mistake, but this is a top-tier AI vendor with $14B backing, and it went down like a high school sloppiness.

This isn't just embarrassing exec-level fumbling; it's a stark reminder: security isn’t optional, it’s foundational. No amount of encryption or AI wizardry matters when your Google Docs are visible to the world.

I’ve been around this block: permissions, configuration, automation—if you miss one piece, your whole trust chain breaks. Scale AI’s quick lock-down after the BI exposé is reactive, not proactive—and that scares me. Your X million-dollar AI startup shouldn’t be fixing holes in your Google shares.

My takeaway: if you’re building serious software, secure EVERY layer, from CI to shared docs. Otherwise, you’re one misclick away from a reputation meltdown.

#OpLog Day 10

I Turned My Akkoma Instance into a Federated Opinion Blog

Welcome to Day 5 of #OpLog — my daily stream of personal tech opinions.

Today’s post is about how I turned my self-hosted Akkoma instance into a fully automated, opinion-based microblog — called Oplog.

Akkoma (a fork of Pleroma) is lightweight, API-friendly, and doesn’t carry the bloat of traditional social or blogging platforms. I use it to post short-form thoughts — but I wanted those to live outside the fediverse too, in a format I fully control.

So I built a GitHub Action that runs every hour, fetches the XML feed from my Akkoma instance, parses it, supports pagination, and then publishes it as a static site using GitHub Pages. The whole thing is pipelined — no manual effort needed. Once I post on my instance, it automatically appears on Oplog.

I’ve even polished the UI to make it clean and readable. This isn’t a traditional blog — it’s federated, automated, and designed for short, high-signal posts without the pressure of SEO or long-form writing.
• Preview Oplog: https://oplog.isalman.dev
• GitHub Source Code: https://github.com/hotheadhacker/akkoma-blog

This is what I always wanted:
A personal space powered by the fediverse and automation — no overhead, just thoughts.

⸻

#OpLog Day 5

GPT-4.1 Just Dropped, and It’s Pretty Wild

So, OpenAI just rolled out GPT-4.1 to all paid ChatGPT users, and honestly, it’s a solid step up from GPT-4o. The model now handles coding tasks way better and can digest way longer inputs — like, 1 million tokens long. That’s huge if you’re working with big projects or want to feed it entire docs.

But here’s the thing: while this is exciting, it’s also a bit scary. The pace of AI upgrades is insane, and we’re basically putting all our eggs in a few big AI platforms. Sure, they’re powerful and useful, but it raises questions about privacy and who really controls this tech.

As someone who’s seen a lot of tech trends come and go, I think it’s cool to have these tools at our fingertips — just gotta keep in mind the bigger picture. Innovation is great, but we shouldn’t forget the ethical side of things as AI gets smarter and more embedded in our lives.

#OpLog Day 9

The False Urgency of Tech Stacks

In today’s dev circles, choosing the “perfect” tech stack has become an obsession. I’ve seen teams spend weeks debating between Next.js and Svelte, or Go vs Rust—before even writing a single line of meaningful product logic.

Here’s my take: no tech stack saves a bad idea. The real work is in execution, not in your choice of framework. Great products survive refactors, migrations, even rewrites. But they don’t survive indecision.

Pick what you know. Ship it. Optimize later. The best tech stack is the one that lets you move without friction—because clarity beats cleverness every time.

#Oplog Day 7

Firefox moving to GitHub: A win and a warning.
Today Mozilla moved Firefox’s development to GitHub. Good? Yes—easier contributions, better visibility, and access to modern CI/CD via GitHub Actions. It lowers the barrier for community devs, which Mozilla needs.

But it’s also a philosophical shift. Firefox now relies on a Microsoft-owned platform, which feels ironic for a project rooted in decentralization and user freedom. Independence is traded for convenience.

While the move may boost momentum short-term, it subtly signals how even the most open projects bend toward centralization for survival. A smart choice, but a bittersweet one.

https://github.com/mozilla-firefox/firefox

WhatsApp’s “End-to-End Encryption” Isn’t What You Think

WhatsApp proudly advertises its end-to-end encryption (E2EE) as a guarantee that only you and the person you’re communicating with can read your messages. However, the reality is more nuanced.

1. Metadata Exposure
While message content is encrypted, WhatsApp collects metadata—information about who you communicate with, when, and how often. This data can be shared with parent company Meta and, upon request, with law enforcement agencies.

2. Vulnerabilities in Group Chats
Recent research has highlighted weaknesses in WhatsApp’s group messaging system. The platform lacks cryptographic management for group messages, allowing potential attackers to add unauthorized members to group chats without proper verification.

3. Prekey Depletion Attacks
A study titled “Prekey Pogo” revealed that WhatsApp’s implementation of the Signal protocol is susceptible to prekey depletion attacks. Such attacks can degrade the security of future messages, compromising the intended forward secrecy of E2EE.

4. Message Flagging and Content Review
If a user flags a message, WhatsApp can access its content to assess potential violations. This process involves decrypting the message, which contradicts the notion of absolute end-to-end encryption.

5. Backup Vulnerabilities
WhatsApp offers encrypted backups, but users must opt-in for this feature. Unencrypted backups stored on cloud services like Google Drive or iCloud are susceptible to access by third parties, including the service providers themselves.

6. Exploitation by Spyware
In 2019, the Pegasus spyware exploited a vulnerability in WhatsApp, allowing attackers to install surveillance software on users’ devices. This incident underscores that vulnerabilities can exist, enabling unauthorized access despite encryption claims.

7. Data Recovery Possibilities
Deleted WhatsApp messages can sometimes be recovered through backups or third-party software, challenging the perception that once a message is deleted, it’s gone forever.

⸻

#OpLog Day 7
URL: oplog.isalman.dev
Repo: github.com/hotheadhacker/akkoma-blog

Let’s Encrypt is free, but is it really safe?

Let’s Encrypt has changed the internet—for better and worse. It democratized HTTPS, no doubt. A few lines of shell and your site is green-locked. But we don’t talk enough about its trade-offs. And after self-hosting for years, I’ve seen enough edge cases to have a solid opinion: Let’s Encrypt isn’t as secure as we pretend it is.

Let me explain.

1. Domain validation is just a low bar
Let’s Encrypt only checks if you “own” the domain via DNS or HTTP validation. That’s fine for personal projects, but it opens doors for phishing sites, malicious mirrors, and scam clones to get green-locked with zero scrutiny. Users think a padlock = safe. That’s not true. They just bought a domain, added DNS records, and now they have the same certificate UX as a real banking site.

2. Expiry every 90 days sounds good, until it breaks in production
Short-lived certs are cool in theory. But if you’re running a self-hosted service, you know how brittle the automation can get. One cron job fails, one DNS hiccup, one missed renewal—and your service goes down with “SSL_ERROR_BAD_CERT_DOMAIN”. I’ve seen open-source dashboards, internal APIs, and even e-commerce sites go down silently because of auto-renew gone wrong.

3. MITM still happens, but now with HTTPS
I’ve seen cases where compromised servers served malware under legit Let’s Encrypt certs. And most users wouldn’t even question it because the padlock was green. Let’s Encrypt doesn’t audit content. It doesn’t verify who you are. It’s just domain-control. That’s it.

4. Abuse at scale
A single bad actor can register 50 domains, get certs in seconds, and set up a phishing farm—all looking “secure.” Try doing that with paid certificates that involve organization validation. Let’s Encrypt made attacks faster and harder to detect. And while they have rate-limiting and revocation systems, they’re reactive, not preventive.

What do I use instead?
In most of my serious projects, I use Cloudflare’s Origin Certificates or paid DV/OV certs, depending on the use case. They last longer, offer better API controls, and give me less anxiety during deployments. Also, if you’re in DevOps, the fewer moving parts that break silently, the better.

To be clear—Let’s Encrypt isn’t bad. It’s necessary. It brought HTTPS to billions. But if you’re building something serious—something where uptime, trust, and security really matter—don’t blindly go for “free.” Sometimes free costs more in the long run.

⸻

#OpLog Day 6

You don’t need a monorepo. You need clarity.

I’ve seen way too many teams jump onto monorepos thinking it’s a silver bullet—“Look, we can share code!” “All our services in one place!” But what they end up with is a spaghetti mess of CI hacks, accidental coupling, and mental overhead.

Most people don’t need a monorepo—they just need to learn how to document things properly, split responsibilities, and version their APIs cleanly. A messy monorepo is worse than a well-thought-out polyrepo setup.

Before you adopt the tech bigcos use, ask yourself: are you facing the same scale or just copying noise?

Most devs confuse “configuration” with “infrastructure.”
Just because you slapped a Dockerfile and a docker-compose.yml together doesn’t mean your app is production-ready. Real infra starts where your comfort with logs, metrics, retries, and failure domains begins. Until then, it’s just a local playground with delusions of scalability.