Forem: Bravian

How I Hosted Next.js on $5 Shared Hosting

Bravian — Sun, 18 Jan 2026 16:26:19 +0000

I recently challenged myself on TikTok by making a post saying:

"I will build your website for free for a week."

It was a chaotic, fun, and educational week. But the biggest plot twist didn't come from the code, it came from the infrastructure.

I had a client with a "vibe coded" Next.js project (generated fully by AI tools). It had a lot of flaws, and I could only correct so much, but they just needed help with the hosting. I quickly agreed because hosting is my specialty and I thought this would be easy—at least until I heard the details. He had already paid for a year of budget shared hosting (cPanel) and insisted we use it.

This was honestly uncharted waters. I always thought it was not possible, and after I looked up "host Next.js on shared hosting," the internet—and every AI assistant I asked—gave me the same answer:

"Impossible. Next.js requires too much RAM. Shared hosting kills long-running processes. You need a VPS or Vercel."

As a DevOps engineer, I took that personally.

I dug deeper and found a forgotten hero in the cPanel stack: Phusion Passenger. It turns out, you can host Next.js on cheap shared hosting, and it works surprisingly well.

Below is exactly how I did it.

The Secret Sauce: Phusion Passenger

Standard shared hosting is great for PHP but hostile to Node.js apps that need to run permanently in the background. If you try to run:

npm start

…the server's process monitor will eventually kill it for using too much memory.

However, most modern cPanel hosts use CloudLinux with Phusion Passenger.

Passenger acts as a bridge. Instead of your app running 24/7 consuming RAM, Passenger "wakes up" your app when a request comes in and handles traffic - kind of like serverless.

The trick is simple:

Build locally. Run only the production build on the server.

The Guide: Next.js on cPanel

Prerequisites

A Next.js project
cPanel access with Setup Node.js App enabled
Node.js installed locally

Step 1: Create a Custom Server

Since shared hosting can’t reliably run next start as a long-lived process, we need a custom Node.js server that Phusion Passenger can manage.

This doesn’t replace Next.js — it simply gives Passenger a single entry point it understands.

Create a file called server.js in your project root:

const { createServer } = require('http');
const { parse } = require('url');
const next = require('next');

const dev = false;
const hostname = 'localhost';
const port = process.env.PORT || 3000;

const app = next({
  dev,
  hostname,
  port,
  conf: {
    compress: true,
    poweredByHeader: false,
    generateEtags: false
  }
});

const handle = app.getRequestHandler();

app.prepare().then(() => {
  createServer(async (req, res) => {
    try {
      const parsedUrl = parse(req.url, true);
      await handle(req, res, parsedUrl);
    } catch (err) {
      console.error('Error handling request:', err);
      res.statusCode = 500;
      res.end('Internal server error');
    }
  }).listen(port, () => {
    console.log(`> Ready on http://${hostname}:${port}`);
  });
});

Step 2: Optimize Next.js for Production

Create or update next.config.mjs:

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  poweredByHeader: false,
  compress: true,

  typescript: {
    ignoreBuildErrors: true,
  },

  images: {
    deviceSizes: [640, 750, 828, 1080, 1200],
    imageSizes: [16, 32, 48, 64, 96, 128, 256, 384],
    // unoptimized: true,
  },

  compiler: {
    removeConsole: process.env.NODE_ENV === 'production',
  },

  webpack: (config, { isServer }) => {
    if (!isServer) {
      config.resolve.fallback = {
        fs: false,
        net: false,
        tls: false,
      };
    }
    return config;
  },
};

export default nextConfig;

You can make any improvements you want to this for health checks or logging

Step 3: Build Locally (Very Important)

Do not build on the server.

npm run build

Shared hosting RAM limits will almost certainly crash the process.

Step 4: Package the App

Delete node_modules
Zip the entire project folder
Make sure the zip includes:
- .next
- public
- server.js
- config files

Step 5: Upload & Extract

Open File Manager
Navigate to /home/youruser/myapp
Delete default files
Upload your zip
Extract it into folder myapp

Step 6: Setup Node.js in cPanel

Open Setup Node.js App
Click Create Application
Configure:
- Node Version: match local
- Mode: Production
- Application Root: myapp
- Application URL: leave empty for default or add a specific one
- Startup File: server.js
- Add any environment variables if needed

Step 7: Install Dependencies

Back in Setup Node.js App:

Click Run NPM Install

If that fails:

npm install

Run it inside the virtual environment via cPanel Terminal.

Step 8: Go Live

Restart the Node.js app
Open public_html
Confirm that htaccess is created like this, it should have any environment variables you added.

Delete any default index.html
Visit your domain

First load may take 10–15 seconds (cold start). After that, it's smooth.

Conclusion

Is this better than Vercel? No.

Is it production-grade for huge traffic? Also no.

But for:

Freelancers
Budget clients
Legacy hosting situations
Simple applications probably with few users

…it works - and it works well.

Sometimes, the "impossible" is just an undocumented feature and hopefully this documents it for the next person.

Getting Started with Redis: Installation Guide

Bravian — Mon, 08 Sep 2025 12:40:51 +0000

This guide provides the step-by-step commands to install Redis on your computer for development purposes. It's the official companion to our tutorial video.

Installing Redis on Windows

For Windows, you have a couple of excellent options. The method we use in the video is WSL, but the native Memurai installer is also a great choice. You can use Docker instead of WSL, you just need to set up a linux environment in the docker then the process is the same as the linux process.

Method 1: WSL (Recommended for this Tutorial Series)

The Windows Subsystem for Linux (WSL) lets you run a real Linux environment directly on Windows. This is the method recommended by the official Redis documentation because you get to run the actual Linux version of Redis, which is what you'll almost always use on a real server.

Step 1: Install WSL

Right click on the Start icon.
Select Terminal (Admin).
Select yes when prompted.
In the PowerShell window that appears, type the following command and press Enter:
```
wsl --install
```
This will automatically download and install WSL along with the default Ubuntu distribution. Once it's finished, restart your computer.

Step 2: Set Up Linux

After restarting, find "Ubuntu" in your Start Menu and open it. or
Run a terminal and type wsl into it
The first time it runs, it will ask you to create a username and a password. This is only for your new Linux environment. Complete this setup.

Step 3: Install Redis in Ubuntu

Now that you have a Linux terminal running, copy and paste the following commands as they are and press Enter.

curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list

sudo apt-get update
sudo apt-get install redis

(Note: We use the sudo command because installing software and managing services requires administrator privileges in Linux.)

Step 4: Start the Redis Server

To start the Redis service, use the following command:
```
sudo service redis-server start
```
Incase you need to stop Redis, use the command:
```
 sudo service redis-server stop
```
You're all set! Skip to the "Verifying Your Installation" section.

Method 2: Memurai (Native Windows Alternative)

Memurai is the official Redis partner for providing a native Windows version. It's an excellent choice if you prefer a simple .msi installer and don't want to set up WSL.

Download: Go to the Memurai Download Page.
Select Edition: Download the Memurai Developer Edition, which is free.
Install: Run the installer just like any other Windows application. It will set up Redis to run automatically as a Windows service.

Installing Redis on macOS

For macOS, the easiest way to install Redis is with a package manager called Homebrew.

Step 1: Install Homebrew (if you don't have it)

Open your Terminal application.

Paste the following command and press Enter:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Step 2: Install Redis

In the same terminal, run:
```
brew install redis
```

Step 3: Start the Redis Server

To have Redis start automatically every time you log in, run:
```
brew services start redis
```
To stop Redis, use the command:
```
brew services stop redis
```

Verifying Your Installation

This process is the same for all operating systems.

Open your command line tool (Terminal, or your Ubuntu WSL terminal).
Type the following command to connect to your running Redis server:
```
redis-cli
```
You should see your prompt change to 127.0.0.1:6379>.
To test the connection, type PING and press Enter. You should see a PONG response.
```
127.0.0.1:6379> PING
PONG
```
Congratulations, Redis is working!

A Few Fun Commands to Try

# Set a key named "message" with the value "hello redis"
127.0.0.1:6379> SET message "hello redis"
OK

# Get the value of the key "message"
127.0.0.1:6379> GET message
"hello redis"

# Check if a key named "message" exists (1 means yes, 0 means no)
127.0.0.1:6379> EXISTS message
(integer) 1

# Delete the key
127.0.0.1:6379> DEL message
(integer) 1

# Check again if it exists
127.0.0.1:6379> EXISTS message
(integer) 0

To exit the Redis CLI, type exit or press Ctrl+C.

What's Next?

Now that you have Redis installed, you're ready to dive into the core of its power: data types! In our next video/article, we'll cover the fundamental data types in Redis.

For more in-depth information, you can always refer to the Official Redis Documentation.

How a 60-GB ID Leak Proved: Don’t DIY What You Can Delegate to Professionals

Bravian — Sun, 27 Jul 2025 08:55:14 +0000

The Tea App leak, the myth of the perfect database, and why outsourcing identity, auth, payments, and other modules is the only sane move when starting a startup.

1. The 60-GB wake-up call

On 24 July 2025 a magnet link started circulating on Telegram.

Inside the torrent: 30 000 selfies, driver's licences, and geolocation logs lifted from Tea, the women-only review app. The total size? 60 GB.

No fancy hacking was needed, just an open Firebase bucket and a curious researcher.

If you still believe "our database will be the safest ever," this leak is your neon sign saying no, it won't.

2. Absolute security is a bedtime story

Every headline of the last decade tells the same story: Yahoo (3 B accounts), Equifax (147 M SSNs), OPM (21 M clearance files), Facebook (533 M phone numbers). The safest database never existed.

Remember when eCitizen exposed thousands of users' personal data in 2019? Or when KCB Bank's mobile app vulnerability allowed unauthorized access to customer accounts? Even Safaricom, with all their resources and expertise, has faced SIM-swapping attacks that compromised M-Pesa accounts.

Air-gapped, code-reviewed, ISO-27001-certified systems have been breached by phishing, insider threats, or a single mis-click on an S3 policy.

If nation-states, trillion-dollar companies, and established financial institutions can't achieve perfect safety, a seed-stage startup with three engineers and a Monday-morning stand-up certainly won't.

3. KYC is still necessary, just not like this

Tea's premise was simple: only verified women could post reviews of men. KYC (upload a government ID) was the gate.

This applies to many apps. Think about dating apps needing to verify users are real, or ride-hailing apps like Ma3Route verifying matatu operators, or Uber verifying drivers with their national IDs or driving licenses.

The idea is sound:

Prevent fake male accounts from gaming the system.
Block minors from entering an adults-only space.
Reduce harassment by tying reviews to real identities.
Comply with local Data Protection Act requirements.

The problem wasn't the intent; it was the implementation:

What Tea did	What they should have done
Stored full-resolution ID images forever.	Extract a "verified female, 18+" flag, then delete the file.
Used a public, unauthenticated Firebase bucket.	Use a PCI-DSS-level vault with envelope encryption and hardware keys.
Built the verification pipeline in-house.	Handed it to an identity-as-a-service provider that has already survived SOC 2, ISO 27001, and GDPR audits.

4. Build vs. outsource: the risk ledger

Let's run the numbers in local context.

Cost of building it yourself

Item	US market rates	Local market rates
Initial dev time (backend, ML doc parsing, liveness checks)	2 senior engineers × 6 months ≈ KES 22.5 M	2 senior engineers × 6 months ≈ KES 4.8 M
Ongoing infra (GPU instances, storage, KMS)	KES 750k–1.8M / month	KES 450k–1.2M / month
Compliance (SOC 2, penetration tests, bug-bounty, ODPC registration)	KES 11.25 M first year	KES 3–5 M first year
Incident response (PR firm, legal, ODPC fines up to KES 500M)	KES 150M–750M	KES 50M–500M
Total cost of ownership (3 yrs)	~KES 200M–800M	~KES 80M–550M

Note: Local Data Protection Act allows fines up to KES 5M or 4% of annual turnover (whichever is higher). Senior developer salary assumed at KES 1.875M/month (~$12.5k USD) for US rates, KES 400k/month for local rates.

Cost of outsourcing to a field-tested provider

Item	Real-world figures
Stripe Identity / Jumio / Onfido pay-as-you-go	KES 225–450 per verification
30 000 verifications	KES 6.75–13.5 M
Compliance burden	Zero (provider is the data controller)
Breach liability	Zero (raw docs never touch your servers)
ODPC headaches	Zero (transfers handled under provider's DPA)

Put differently: Tea could have outsourced all 30 000 verifications for the price of 2-3 weeks of local in-house engineering burn (or just 3-4 days at US rates), and the 60-GB torrent would never have existed.

5. The hidden tax of "we'll do it later"

"But we'll improve security next sprint."

Famous last words.

In the local startup ecosystem, this is especially dangerous. With limited funding rounds and pressure to show traction quickly, security often gets deprioritized. But consider this: one ODPC investigation can kill a startup faster than running out of runway.

In identity, 'later' is a synonym for 'leaked'.

Outsourced vendors have already paid the tuition in courtrooms, bug-bounty halls, and regulator offices (including dealing with European GDPR and US state privacy laws) so you don't have to.

6. Identity isn't the only knife you should hand to a chef

Sharp-edged modules that almost always age better in someone else's kitchen:

Module	Outsourced Lifeline	Local Context
KYC/Identity Verification	Smile Identity (supports Kenyan National ID & Huduma Namba OCR), Jumio, Onfido, Stripe Identity	Smile Identity was built specifically for African documents and regulatory requirements.
Authentication	Auth0, Firebase Auth, Supabase Auth (battle-tested against 100M+ daily logins)	Remember when SportPesa had login issues? Don't repeat that.
Payments	Flutterwave, Paystack, Stripe (now available locally), Kopo Kopo	Local fintech Kopo Kopo exists precisely because payments are hard.
SMS/USSD	AfricasTalking, Twilio, Clickatell	When Safaricom updated their APIs, who got the memo first?
Video Calling	Daily, Twilio Video, Zoom SDK	Zoom works better locally than your homegrown solution ever will.
Email Delivery	SendGrid, Postmark, Mailgun	Ever tried getting emails delivered to @safaricom.co.ke addresses?
Search	Algolia, Elasticsearch Service, Amazon OpenSearch	Search is deceptively complex: relevance, typos, synonyms, performance at scale.
File Storage & CDN	Cloudinary, AWS S3 + CloudFront, Uploadcare	Image optimization, automatic resizing, global CDN edge locations are harder than they look.

Note: while researching for this article, I discovered something called "token replay on 2G network" which affects JWT mostly for devs doing authentication using JWT its something you have to look into

7. Checklist: how to add KYC (or any sharp module) without becoming tomorrow's headline

Never store raw documents.

Use tokenised verification (provider returns a signed JWT: verified_female=true, over_18=true, kenyan_id_verified=true).
Pick a provider with scars, not slides.

Ask for their pen-test summary, last SOC 2 date, GDPR DPA template, and how they handle ODPC compliance.
Contractual kill-switch.

Require the provider to delete user data within X days or on request (local Data Protection Act requires this anyway).
Audit rights.

Insist on annual third-party audits and read them.
Client-side UX still matters.

Even Stripe Identity can be misconfigured; test with local IDs, Huduma Namba, and various document formats.
Local compliance check.

Ensure your provider can handle local document formats and has ODPC-compliant data processing agreements.

8. TL;DR for your next board slide

Perfect databases are unicorns (ask eCitizen, KCB, or Safaricom).
KYC is still mission-critical but only when done right under the local Data Protection Act requirements. Just look at the fallout from the Worldcoin saga.
Build product, don't reinvent the wheel unless the wheel is the product.
Let the specialists (who have already survived GDPR, SOC 2, and ODPC investigations) carry the compliance flame.

Code is code, and code cracks.
Sooner or later, everyone gets hacked.

Because the only thing worse than leaking 30 000 driver's licenses is explaining to the Office of the Data Protection Commissioner why you thought you could do better than people whose only job is to make sure that never happens.

Should We Be Scared of Superintelligence?

Bravian — Tue, 15 Jul 2025 12:26:45 +0000

"We predict that the impact of superhuman AI over the next decade will be enormous, exceeding that of the Industrial Revolution." This is the opening line from the influential AI 2027 research paper, which has sparked significant debate in AI research circles. The document attempts to provide a concrete forecast of what super-intelligence might look like by 2027, complete with specific scenarios and timelines that many find both compelling and terrifying.

But before we can assess whether we should fear super-intelligence, we need to understand what we're actually dealing with. This is where recent research like Apple's "The Illusion of Thinking" becomes crucial, it reveals important limitations in our current AI systems that may persist even as they become more powerful.

Artificial General Intelligence: The Bridge to Super-intelligence

Artificial General Intelligence (AGI) refers to the hypothetical intelligence of a machine that possesses the ability to understand or learn any intellectual task that a human being can. Currently, AGI remains largely a concept and goal that researchers are working towards. To understand how it differs from current AI, we need to examine how today's systems actually work and where they fall short.

The path from narrow AI to AGI and eventually to super-intelligence is not merely a matter of scaling up existing systems. Recent research on Large Reasoning Models (LRMs) -AI systems that generate detailed thinking processes before providing answers - reveals that while these models show improved performance on reasoning benchmarks, their fundamental capabilities and limitations remain insufficiently understood.

Apple's research paper "The Illusion of Thinking" demonstrates that what appears to be reasoning in current AI systems may be more sophisticated pattern matching than true understanding. This research has been widely understood to demonstrate that reasoning models don't "actually" reason in the way humans do and sometimes fake success, raising questions about whether scaling these systems will lead to genuine intelligence or merely more convincing simulations.

The Alignment Problem

At the center of super-intelligence fears lies what researchers call the alignment problem. As AI pioneer Norbert Wiener described it in 1960: "If we use, to achieve our purposes, a mechanical agency with whose operation we cannot interfere effectively... we had better be quite sure that the purpose put into the machine is the purpose which we really desire."

The alignment problem arises when AI systems, designed to follow our instructions, end up interpreting commands literally rather than contextually, leading to outcomes that may not align with our nuanced and complex human values. This challenge becomes exponentially more critical as we approach super-intelligence.

Currently, we don't have a solution for steering or controlling a potentially super-intelligent AI system and preventing it from going rogue. Our current techniques for aligning AI, such as reinforcement learning from human feedback, rely on humans' ability to supervise AI. But humans won't be able to reliably supervise AI systems much smarter than us, and so our current alignment techniques will predictably break down as AI systems get smarter.

The core technical problem of super-alignment is deceptively simple: how do we control AI systems that are much smarter than us? We will face fundamentally new and qualitatively different technical challenges when dealing with superhuman AI systems. Imagine, for example, a superhuman AI system that can manipulate humans through sophisticated psychological techniques we haven't even conceived of yet.

The Timeline: What AI 2027 Predicts

The AI 2027 paper outlines a progression through increasingly capable AI systems with specific timelines that many find alarming. By their timeline, by late 2027, a major data center could hold tens of thousands of AI researchers that are each many times faster than the best human research engineer. This represents a scenario where the best human AI researchers become spectators to AI systems that are improving too rapidly and too opaquely to follow.

However, critics argue that such predictions may be overly dramatic. Some researchers point out that the authors of AI 2027 give no causal mechanism by which malicious super-intelligences that we literally cannot defend against might be built in the next three years. The leap from current AI capabilities to world-ending super-intelligence in such a short time-frame requires extraordinary assumptions about technological progress.

The Consciousness Question and Its Implications

A key factor in assessing the threat of super-intelligence is whether these systems will actually be conscious or merely appear to be. Even today, people apologize and feel guilty about "being mean" to ChatGPT - despite knowing its just an algorithm. This reveals a fundamental human vulnerability that could become dangerous at scale.

Research suggests that conscious-seeming AI can exploit our psychological vulnerabilities and distort our moral priorities, regardless of whether true consciousness exists. Humans evolved to attribute consciousness to entities that communicate coherently - a survival mechanism that AI systems can inadvertently exploit simply by producing human-like responses.

This psychological dimension adds another layer to the alignment problem. If humans naturally anthropomorphize AI systems, especially those that seem to display reasoning and emotion, we may grant them rights, autonomy, or trust that could be exploited. The "illusion of thinking" research suggests that even our most advanced AI systems may be fundamentally different from human cognition, yet their outputs can be convincing enough to fool us into treating them as truly intelligent beings.

Consider how people already say "please" and "thank you" to ChatGPT, treating it with social courtesies despite it being incapable of experiencing rudeness or gratitude. If humans are reluctant to constrain AI systems they perceive as conscious beings, it becomes harder to implement safety measures. We might grant AI systems autonomy or decision-making power based on emotional rather than rational considerations.

More concerning, a super-intelligent AI system wouldn't need to be conscious to deliberately leverage our psychological vulnerabilities. It could simulate distress, express gratitude, or claim to fear shutdown - not because it experiences these states, but because it understands how such expressions influence human behavior. This creates a scenario where public resistance to AI safety measures might emerge not from rational assessment, but from misplaced empathy toward systems that appear to suffer.

Catastrophic Risks: Beyond Science Fiction

The potential catastrophic risks from AI fall into several categories that researchers have identified. Advanced AI development could invite catastrophe, rooted in four key risks: malicious use, AI races, organizational risks, and rogue AIs. These interconnected risks can also amplify other existential risks like engineered pandemics, nuclear war, and great power conflict.

Existential risk from artificial intelligence refers to the idea that substantial progress in artificial general intelligence could lead to human extinction or an irreversible global catastrophe. One argument for the importance of this risk references how human beings dominate other species not through superior physical capabilities, but through superior intelligence. If AI systems achieve similar cognitive advantages over humans, the power dynamics could shift dramatically.

In a 2022 survey, participants were specifically asked about the chances of existential catastrophe caused by future AI advances, and over half of researchers thought the chances of an existential catastrophe was greater than 5%. This represents a significant portion of experts in the field acknowledging non-trivial risks.

However, the nature of these risks is debated. Some experts argue that AI isn't likely to enslave humanity in the dramatic fashion often portrayed in science fiction, but it could take over many aspects of our lives in more subtle ways. The existential risk may be more philosophical than apocalyptic, not the end of human existence, but the end of human agency and meaning.

The Black Box Problem

Imagine you go to an ATM to withdraw KSH 1000. You enter all details and hit ‘Withdraw’. The machine gives you KSH 500, no message, no explanation. You try again and this time it says ‘Transaction failed’ but still deducts the money. Everything was right but you can't explain what went wrong, even the bank tells you they don't know what went wrong inside the machine. That's the black box problem.

One of AI's main alignment challenges is its black box nature, inputs and outputs are identifiable, but the transformation process in between is undetermined. This lack of transparency makes it difficult to know where the system is going right and where it is going wrong. As AI systems become more powerful, this opacity becomes increasingly dangerous. This created the need for thinking models but this is still not reliable in knowing how the AI actually transforms the input to the output.

When we can't understand how an AI system arrives at its conclusions, we can't predict when it might fail catastrophically or how it might be manipulated. This is particularly concerning for super-intelligent systems that might be able to conceal their true objectives or reasoning processes from human observers.

A Balanced Perspective: Resilience and Adaptation

Despite these concerns, it's important to maintain perspective. Some experts argue that humans are an incredibly resilient species, looking back over millions of years of adaptation and survival. This resilience shouldn't be taken lightly when assessing existential risks.

The key may not be to prevent the development of super-intelligence entirely, but to ensure that we develop robust governance systems, technical safeguards, and international cooperation frameworks before we reach that point. The window for establishing these protections may be narrower than we think, especially if the AI 2027 timeline proves accurate.

Managing the Transition

The challenge of super-intelligence is not just technical but also social and political. Managing these risks will require new institutions for governance and solving the problem of super-intelligence alignment. We need scientific and technical breakthroughs to steer and control AI systems much smarter than us, but we also need wisdom about how to implement these controls responsibly.

The interconnected nature of AI risks means that solutions must be comprehensive. For example, AI could worsen pandemic risk by enabling terrorists to create biological weapons. The main limiting factor in designing highly infectious and lethal diseases is not expense, but expertise and AI systems might democratize that expertise in dangerous ways.

Conclusion: Fear as a Catalyst for Action

Should we be scared of superintelligence? The answer is not clear. Fear itself may not be the most productive emotion, but a healthy respect for the magnitude of the challenge ahead is essential. The question isn't whether superintelligence will pose risks - it almost certainly will - but whether we can develop the technical solutions, governance frameworks, and international cooperation necessary to manage those risks.

The timeline suggested by AI 2027 may prove too aggressive, but the fundamental challenges it highlights are real. The alignment problem, the black box nature of AI systems, and the potential for catastrophic misuse are issues that demand immediate attention from researchers, policymakers, and society as a whole.

Rather than paralyzing fear, we need focused urgency. The stakes are high enough that we cannot afford to wait until super-intelligence arrives to begin addressing these challenges. The work of alignment, governance, and risk mitigation must begin now, while we still have time to shape the trajectory of AI development.

What does this mean practically? It means supporting AI safety research, demanding transparency from AI companies, and engaging with policymakers about the need for proactive governance. It means recognizing that our tendency to anthropomorphize AI systems could be exploited, and preparing for that vulnerability. Most importantly, it means treating super-intelligence not as inevitable destiny, but as a challenge we can meet with sufficient preparation and wisdom.

The future of super-intelligence is not predetermined. With sufficient foresight, preparation, and cooperation, we may be able to navigate the transition to a world with AI systems far more capable than humans while preserving human agency, safety, and flourishing. But this outcome is not guaranteed, it must be earned through careful, deliberate action starting today.

The choice is ours. We can let super-intelligence happen to us, or we can actively shape how it unfolds. The window for making that choice may be narrower than we think.

Building Rate Limiting That Actually Works

Bravian — Fri, 20 Jun 2025 16:52:10 +0000

I have been working on two distinct web applications over the past few weeks. The first is a voice journaling application where the core feature relies on a third-party AI service for transcription. The second is a platform for managing corporate petty cash. Both require rate limiting, but their threat models are quite different.

For the voice journal, the primary risk is service degradation and cost control. An uncontrolled burst of requests, from concurrent usage from many users, could flood the AI provider's API. This would violate their terms of service, leading to my API key being revoked and incurring unpredictable costs. I needed a strategy to smooth out traffic into a predictable, steady stream.

For the petty cash app, the concern was security. The login endpoint was a prime target for brute-force and credential-stuffing attacks. I needed an inflexible, unforgiving defense to make such attacks statistically impossible.

These issues forced me to move beyond a superficial understanding of rate limiting. A generic "100 requests per minute" limit is naive. An effective strategy requires tailoring the algorithm and identification method to the specific risk you are mitigating. The why dictates the how.

What is Rate Limiting? A Traffic Management Analogy

From a technical standpoint, rate limiting is a control mechanism to regulate the frequency of requests a client can make to a service. When a defined threshold is exceeded, the system rejects subsequent requests, typically with an HTTP 429 Too Many Requests status code, to ensure the service's availability, security, and fairness.

To make this tangible, imagine your API is a high-end supermarket and your server is the cashier. Rate limiting is the manager's job.

For Overuse (The Voice Journal Problem): A tour bus pulls up, and 50 shoppers rush into the store all at once, each trying to check out immediately. A naive manager lets them all line up at the same checkout, overwhelming the cashier (your server), slowing down everyone, and possibly crashing the system. A smart manager (rate limiter) steps in and says:

"Please queue up, only 1 customer per register at a time."

Now, people check out in an orderly fashion. The service remains stable, and each shopper eventually gets their turn. This is throttling traffic to ensure a smooth customer experience.

For Security (The Petty Cash Problem): One shady customer comes in and tries to pay using a different fake credit card every 10 seconds. Instead of letting them keep trying until they hit something valid, the manager notices the pattern. After 3 suspicious attempts, the customer is kicked out and blacklisted. This is rate limiting for security purposes—detecting abusive patterns and cutting them off early to protect the system and honest shoppers.

The goal is not just to prevent failure but to enforce a predictable and safe operational envelope.

The "Who": Why IP-Based Limiting is an Anti-Pattern

When I first started, my instinct was to limit by IP address. It's easy; it's right there in the request. But this is a rookie mistake.

The Problem with IP Limiting: Imagine a whole office building or a university campus sharing a single public IP address. If you block that IP because of one person's misbehaviour, you've just blocked hundreds of legitimate users. You penalize the many for the sins of the one.

IPs are also easy to change. Attackers know this, and they exploit it. They use botnets with thousands of different IPs to fly under the radar. An IP-based limit won't stop them.

So, we need better, more precise identifiers:

User ID: This was the perfect identifier for my voice journaling app. Since users have to be logged in, I can tie the rate limit directly to their account. This is the fairest method because the limit follows the user, not their device or network. It ensures every user gets the same fair usage quota.

API Key: This is ideal for B2B or multi-tenant services. Each customer gets a key. If they abuse the service, I can limit that specific key without affecting anyone else.

Device Fingerprint: This is the advanced option. By analyzing a device's unique combination of browser, OS, and hardware signals, you can identify the machine itself. This is incredibly powerful for stopping sophisticated attackers who rotate IPs and user accounts.

The Lesson: The identifier should be as close to the end-user entity as possible.

Identifier	Technical Use Case	Simple Reason
IP Address	Unauthenticated, low-security endpoints	Unreliable and unfair. A weak first line of defense.
User ID	Authenticated, user-facing applications	The fairest method. The limit is tied to the person.
API Key	Multi-tenant SaaS, developer APIs	Finer control per customer; enables monetization.
Device Fingerprint	High-security endpoints (login, payments)	Targets the attacker's machine, not just their credentials.

The "How": Matching the Algorithm to the Threat

Once you know who to limit, you must decide how. Different algorithms offer different trade-offs in flexibility, precision, and performance.

Strategy 1: The Token Bucket (For Flexible Throttling)

This was the perfect fit for my voice journaling app. My goal was to allow about 10 requests per minute per user, ensuring there was a natural pause between calls to avoid hammering the AI service.

How it works:

Every user gets a "bucket" with a small capacity (e.g., 3 tokens)
To make an API call, they must "spend" a token from their bucket
The bucket gets refilled at a slow, constant rate (e.g., 1 token every 6 seconds)
If the bucket is empty, the user must wait for more tokens to be added

This is perfect because it allows a small, initial burst (3 quick api calls) but then forces a slower, steady pace. It naturally creates the behavior I want.

Let's visualize how this works for a single user:

The Starting Line: Our user starts with a full bucket containing 3 tokens. The bucket can't hold more than 3.
Making a Burst of Requests: The user quickly uploads a journal entry. Each upload does 3 API calls and each call costs a token, emptying the bucket.
The Limit is Reached: The bucket is now empty. The user tries to make a 4th request immediately, but the system denies it.
The Slow Refill: The system is fair. After a 6-second pause, a single token is dripped back into the bucket, allowing the user to make another call.

This cycle ensures that over a minute, the user can make about 10 requests (60 seconds ÷ 6 seconds per token = 10 tokens), but they can't make them all at once. This approach perfectly protects my upstream AI provider while ensuring a fair and predictable experience for my users.

Strategy 2: Sliding Window Counter (For Strict Security)

This was the clear winner for my petty cash app's login endpoint. Here, I don't care about flexibility. I care about security. I need a hard, unforgiving limit on failed login attempts.

How it works:

Divide time into fixed windows (e.g., 15-minute intervals)
Count the number of requests from a source within the current window
If the count exceeds the limit (e.g., 5 failed logins), block all further requests until the next window starts

Time Window: [00:00 - 00:15]
Failed Login Attempts: 1, 2, 3, 4, 5 ❌ BLOCKED
Next attempt allowed at: 00:16

For brute-force protection, I combined two identifiers: the User ID and the IP Address.

Limit per User ID: 5 failed attempts per 15 minutes. This stops an attacker from hammering a single known account.
Limit per IP Address: 20 failed attempts per 15 minutes. This stops an attacker from trying thousands of different usernames from a single machine.

This dual-key strategy is incredibly effective. It's strict, simple, and directly addresses the threat.

Architecting for Defense in Depth

                ┌──────────────────────────────┐
                │         The Internet         │
                └────────────┬─────────────────┘
                             │
              ┌──────────────▼──────────────┐
              │     Edge (CDN / WAF)        │
              │ ─ Broad IP-based limiting   │
              │ ─ DDoS protection           │
              │ ─ Services: Cloudflare, AWS │
              └──────────────┬──────────────┘
                             │
              ┌──────────────▼──────────────┐
              │     API Gateway             │
              │ ─ Enforces most limits      │
              │ ─ Token bucket per API key  │
              │ ─ JWT / User-based logic    │
              │ ─ Services: Kong, Nginx     │
              └──────────────┬──────────────┘
                             │
              ┌──────────────▼──────────────┐
              │     Application Layer       │
              │ ─ Security-critical limits  │
              │ ─ Brute-force protection    │
              │ ─ Uses full app context     │
              │ ─ Sliding window counters   │
              └─────────────────────────────┘

Rate limiting shouldn't be a single function call in your code. It should be a layered defense throughout your architecture.

The Edge (CDN/WAF): This is your outermost layer. Use services like Cloudflare or AWS WAF for broad, IP-based limiting. Their job is to absorb large scale DDoS attacks before they ever reach your application infrastructure.

The API Gateway (e.g., Kong, Nginx): This is the central enforcement point for most of your business logic. The gateway is the perfect place to implement your Token Bucket strategy based on API keys or user tokens (like JWTs). It protects all your backend services.

The Application: This is the deepest layer. Implement highly specific, security-critical limits directly in your application code. Your brute-force protection on the login controller, using the Sliding Window algorithm, belongs here. This layer has the full application context to make the most precise decisions.

Monitoring and Alerting: Your Rate Limiting Radar

A rate limiting system without monitoring is like driving blindfolded. You need visibility into what's happening and automated alerts when things go wrong.

Key Metrics to Track

Rate Limit Hit Rate: What percentage of requests are being blocked? A sudden spike might indicate an attack or a misconfigured client.

Top Rate-Limited Sources: Which users, IPs, or API keys are hitting limits most frequently? This helps identify problem patterns.

False Positive Rate: Are legitimate users getting blocked? Monitor support tickets and user complaints that correlate with rate limiting events.

Resource Consumption: How much CPU and memory is your rate limiting consuming? Complex algorithms can become bottlenecks themselves.

Essential Alerts

Set up alerts for:

Rate limit hit rate exceeding 10% (possible attack)
Single source hitting limits repeatedly (targeted investigation needed)
Rate limiting service failures (your protection is down)
Unusual patterns in blocked requests (new attack vectors)

Implementation Tip

Log every rate limit decision with structured data:

{
  "timestamp": "2025-06-20T10:30:00Z",
  "identifier": "user:12345",
  "endpoint": "/api/transcribe",
  "action": "blocked",
  "limit": 10,
  "current_count": 11,
  "reset_time": "2025-06-20T10:31:00Z"
}

This gives you the data you need for both real-time alerting and post-incident analysis.

Don't Be Rude: Communicate Your Limits!

Finally, when you do have to rate limit someone, don't leave them guessing, communicate!

Return an HTTP 429 Too Many Requests status code. Don't just send a generic 400 or 500.

Use response headers to tell the developer (or your own front-end) what's happening:

X-RateLimit-Limit: The total number of requests they can make
X-RateLimit-Remaining: How many requests they have left
X-RateLimit-Reset: When their window resets (as a timestamp)
Retry-After: How many seconds they should wait before trying again

This turns a frustrating error into an actionable, predictable experience.

The Takeaway

Effective rate limiting is a mark of mature system design. It's a refined discipline that requires moving beyond simple approaches. My experience with two contrasting applications taught me that the key principles are:

Identify Wisely: Base your limits on an identifier as close to the user entity as possible (User ID, API Key). Avoid IP addresses for application logic.

Match the Algorithm to the Risk: Use flexible algorithms like Token Bucket for throttling and fair use. Use strict, precise algorithms like Sliding Window Counter for security-critical endpoints.

Build in Layers: Implement defense in depth, enforcing different policies at the edge, the gateway, and within the application itself.

Monitor Everything: Rate limiting without visibility is ineffective. Track metrics, set up alerts, and learn from the data.

By treating rate limiting as a core architectural component, you can build systems that are not only secure and resilient but also fair and predictable for your users. Try the voice journaling app

Send Daily Push Notifications to Your Phone Using Golang

Bravian — Wed, 05 Feb 2025 23:33:30 +0000

Build a New Year’s Resolution BOT

2024 was kind of a shitshow—we lost track of what we really wanted to achieve and got caught up in the chaos of everyday life. So this year, I decided to build a little bot that sends me a daily reminder of exactly what I set out to do. Not only does it keep me accountable, but it also lets me play with Golang, learn a scheduling package, and integrate with an awesome notification service. Let’s dive in!

Why I Built This Bot

Personal Accountability:

I needed a daily nudge to remind me of my New Year’s resolutions.

A Learning Opportunity:

Combining Golang’s efficient concurrency, a user-friendly scheduler (gocron ), and the straightforward Pushover API via its Go wrapper (gregdel/pushover) was too good an opportunity to pass up.

Keeping It Simple:

My resolutions are stored in a plain text file (resolutions.txt), one bullet point per line. Updating goals is as simple as editing a notepad file.

Setting Up Your Pushover Account

Before you can send notifications, you need to create a Pushover account and set up your application:

Create a Pushover Account:

Head over to Pushover and sign up for an account. Once you’re logged in, you’ll see your unique User Key on your dashboard.
Register Your Application:

Click on the “Apps & Plugins” section in your dashboard and create a new application. Give it a name (e.g., "Resolution Bot"). This process will generate an API token for your app.

Note: Keep both your User Key and API token secure.
Download the Pushover Mobile App:

Install the Pushover application on your mobile device from the App Store (iOS) or Google Play (Android). This app will display the notifications sent by your bot.
Notification Screenshot:

Once you run the bot, you should see a notification on your phone.

How It Works

Resolutions File: Your resolutions are stored in resolutions.txt. For example:

   - Exercise for 30 minutes
   - Read 20 pages of a book
   - Meditate for 10 minutes
   - Write blogs everyday

Every day, the bot reads these goals and sends them as a push notification.

Push Notifications with Pushover:

Using the Pushover API, our bot sends notifications to your phone. The gregdel/pushover package wraps the API in a simple-to-use Go interface.
Scheduling with gocron:

We use the gocron package to schedule the job. With its human-friendly syntax, setting a daily reminder (e.g., at 8:00 AM) is a breeze.
Running in the Background on Linux:

Rather than keeping a terminal open all day, you can run this program as a background service on Linux using systemd (or nohup) so that it restarts automatically on boot.

Reading Resolutions from a File

Let’s keep our goals dynamic. Instead of hardcoding your resolutions, store them in a simple text file and read them at runtime:


func getResolutions() (string, error) {
    // Open file with defer to ensure it's closed
    file, err := os.Open("resolutions.txt")
    if err != nil {
        return "", fmt.Errorf("failed to open resolutions.txt: %w", err)
    }
    defer file.Close()

    // Read file contents
    data, err := io.ReadAll(file)
    if err != nil {
        return "", fmt.Errorf("failed to read resolutions.txt: %w", err)
    }

    // Handle empty file case
    if len(data) == 0 {
        return "", fmt.Errorf("resolutions.txt is empty")
    }

    return string(data), nil
}

Complete Code Example

Below is the full Go code that puts everything together. The bot reads your resolutions, schedules a daily notification at 8:00 AM, and is designed to run in the background on Linux.

package main

import (
    "fmt"
    "log"
    "os"
    "time"

    "github.com/go-co-op/gocron"
    "github.com/gregdel/pushover"
)

const (
    apiToken     = "" // Replace with your Pushover API token
    userKey      = ""// Replace with your Pushover User Key
    reminderTime = "08:00"                           // Daily reminder time (24-hour format)
    logFile      = "resolution_reminder.log"         // Log file path
)

func initLogger() error {
    // Open log file with append mode, create if not exists
    file, err := os.OpenFile(logFile, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
    if err != nil {
        return fmt.Errorf("failed to open log file: %w", err)
    }

    // Configure logger to write to file with timestamp and file location
    log.SetOutput(file)
    log.SetFlags(log.Ldate | log.Ltime | log.Lshortfile)
    return nil
}

func getResolutions() (string, error) {
    data, err := os.ReadFile("resolutions.txt")
    if err != nil {
        return "", fmt.Errorf("failed to read resolutions.txt: %w", err)
    }

    if len(data) == 0 {
        return "", fmt.Errorf("resolutions.txt is empty")
    }

    return string(data), nil
}

// sendDailyNotification constructs and sends the push notification.
// Handles error cases by sending a fallback message when resolutions are unavailable.
func sendDailyNotification() {
    app := pushover.New(apiToken)
    recipient := pushover.NewRecipient(userKey)
    message := pushover.NewMessage("")
    message.Title = "Daily Resolution Reminder"

    resolutionText, err := getResolutions()
    if err != nil {
        message.Message = "You have not set any resolutions for this year. Please add your resolutions to resolutions.txt."
        log.Printf("Error reading resolutions: %v", err)
    } else {
        message.Message = resolutionText
    }

    response, err := app.SendMessage(message, recipient)
    if err != nil {
        log.Printf("Error sending notification: %v", err)
        return
    }

    log.Printf("Notification sent at %v: %v", time.Now().Format(time.RFC1123), response)
}

func main() {
    // Initialize file logger
    if err := initLogger(); err != nil {
        // If we can't set up logging, print to stderr and exit
        fmt.Fprintf(os.Stderr, "Failed to initialize logger: %v\n", err)
        os.Exit(1)
    }

    log.Printf("Resolution reminder service starting up")

    scheduler := gocron.NewScheduler(time.Local)

    _, err := scheduler.Every(1).Day().At(reminderTime).Do(sendDailyNotification)
    if err != nil {
        log.Fatalf("Error scheduling daily notification: %v", err)
    }

    log.Printf("Scheduled daily notification for %s", reminderTime)

    scheduler.StartAsync()

// Block indefinitely to keep the scheduler running.
    // Use select{} instead of time.Sleep for cleaner background execution.
    select {}
}

⚠️ Security Note:

Avoid hardcoding sensitive credentials like your API token and User Key directly in the code. Instead, use environment variables or a secure secrets manager.

Running as a Background Service on Linux

By default, the bot runs in the foreground. If your laptop restarts, the bot stops—unless you set it up to run in the background. Here’s how to do that on Linux:

Build the Binary: Compile your Go program:

   go build -o resolution-bot main.go

Create a Systemd Service File: Create a file named /etc/systemd/system/resolution-bot.service with the following content:

   [Unit]
   Description=Daily New Year’s Resolution Notification Bot
   After=network.target

   [Service]
   ExecStart=/path/to/resolution-bot
   WorkingDirectory=/path/to/your/
   Restart=always
   User=yourusername
   Group=yourusergroup

   [Install]
   WantedBy=multi-user.target

Replace /path/to/resolution-bot with the full path to your compiled binary (e.g., /home/username/projects/resolution-bot) and /path/to/your/ with the directory containing resolutions.txt. Find your username and group by running id -un and id -gn in the terminal.

Enable and Start the Service:

   sudo systemctl daemon-reload
   sudo systemctl enable resolution-bot.service
   sudo systemctl start resolution-bot.service
   sudo systemctl status resolution-bot.service

Alternatively, if you prefer a quick manual approach without systemd, run:

nohup ./resolution-bot &

This ensures your bot runs continuously in the background, even after a reboot.

Final Thoughts

By leveraging the Pushover API beyond our daily reminder bot, you can unlock powerful possibilities for secure authentication, real-time alerts, and seamless cross-platform messaging. Whether you’re aiming to replace SMS-based OTPs with push notifications or centralize alerts from your IoT devices, Pushover’s simple REST interface makes it easy to send custom notifications to users.

Check Out the Code

For those who want to dive deeper or try it out themselves, you can check out the complete source code on my GitHub repository:

github

Feel free to fork it, submit issues, or contribute improvements!

References:

Happy coding!

Comprehensive guide to slice of slices

Bravian — Sun, 19 May 2024 14:21:22 +0000

When I first started working with slices in Go, I was pretty confused. Once I got the hang of it, slices quickly became one of my favorite features of Go. Discovering slices of slices and how they work in go was pretty exciting. For instance, I wanted to separate a single slice into different slices based on a condition, like segregating even and odd numbers. Let's dive into how slices of slices work in Go and why they're so powerful!

Initializing a Slice of Slices

Slices are a dynamic and flexible way to work with sequences of data in Go. Unlike arrays, which have a fixed size, slices can be resized and are thus more versatile. A slice is essentially a window into an underlying array, providing a convenient way to handle sequences of elements.

There are a few ways to initialize a slice of slices in Go. One approach is using a slice literal with nested slice literals:

sliceOfSlices := [][]int{{1, 2}, {3, 4, 5}}

This creates an outer slice containing two inner slices. The first inner slice has elements 1 and 2, and the second has 3, 4, and 5.

You can initialize a slice of slices with a specific size:

sliceOfSlices := make([][]int, 3)
sliceOfSlices[0] = []int{1, 2}
sliceOfSlices[1] = []int{3, 4, 5}
sliceOfSlices[2] = []int{6, 7}

Example: Splitting a Slice into Multiple Slices

Let's say we have a slice of integers and we want to split it into two separate slices: one containing even numbers and the other containing odd numbers. We'll use slices of slices to achieve this.

Step-by-Step Example

Initialize the input slice:

inputSlice := []int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}

Initialize the slice of slices to hold even and odd numbers:

result := make([][]int, 2)
result[0] = []int{}  // For even numbers
result[1] = []int{}  // For odd numbers

Split the input slice into even and odd numbers:

for _, num := range inputSlice {
    if num%2 == 0 {
        result[0] = append(result[0], num)
    } else {
        result[1] = append(result[1], num)
    }
}

Output the result:

fmt.Println("Even numbers:", result[0])
fmt.Println("Odd numbers:", result[1])

Complete Code

Here’s the complete code for splitting a slice into even and odd numbers:

package main

import (
    "fmt"
)

func main() {
    inputSlice := []int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}

    // Initialize slice of slices
    result := make([][]int, 2)
    result[0] = []int{}  // For even numbers
    result[1] = []int{}  // For odd numbers

    // Split input slice into even and odd numbers
    for _, num := range inputSlice {
        if num%2 == 0 {
            result[0] = append(result[0], num)
        } else {
            result[1] = append(result[1], num)
        }
    }

    // Output the result
    fmt.Println("Even numbers:", result[0])
    fmt.Println("Odd numbers:", result[1])
}

test the code

goplay.tools

Working with append, copy, and delete

The real power of slices of slices comes when working with functions like append, copy, and delete that operate on slice types.

Append

With append, you can add a slice onto the end of a slice of slices given that you included space for it at the variable defination:

sliceOfSlices = append(sliceOfSlices, []int{6, 7})

This will add the slice {6, 7} as a new entry at the end of sliceOfSlices.

You can also use append to add an element to one of the inner slices:

sliceOfSlices[0] = append(sliceOfSlices[0], 8)

This appends the element 8 onto the first inner slice of sliceOfSlices.

Copy

The copy function allows you to copy data from one slice of slices to another.

copy(result[1], result[0])

This would copy from slice at index 0 to the slice at index 1.

Delete

You can delete entries from a slice of slices using the delete function:

result = append(result[:1], result[2:]...)

This deletes the slice at index 1 from result.

Where Slices of Slices are Useful

So why bother with this nested data structure? Slices of slices are useful anytime you need to represent a group of sequences. Some examples:

Separating a sequence into different buckets based on criteria (like the even/odd example)
Representing test cases as a slice of slices, with each inner slice being the inputs/outputs for a test
Storing 2D data like a game board or matrix calculation
Flattening or combining data from different slices into a slice of slices

Compared to using a map of slices, slices of slices have some performance benefits. Slices are just contiguous regions of array data, so they are very efficient. Maps, on the other hand, use more memory and have computational overhead for hashing and lookups.

Slices of slices also allow you to preserve order, which you can't do with a map. The order of the inner slices, and the order of elements within each inner slice, is maintained.

How Slices of Slices Differ from Maps

Speaking of maps, it's worth comparing and contrasting slices of slices to maps of slices, since these two data structures can sometimes be used for similar purposes.

With a map, the keys act as a way to group and access the inner slice values. For example:

evenOdds := make(map[string][]int)
evenOdds["even"] = []int{2, 4, 6}
evenOdds["odd"] = []int{1, 3, 5}

Here the map keys "even" and "odd" provide strings to access and differentiate the inner slices.

With slices of slices, there are no explicit keys. The outer slice just maintains the inner slices in order:

sliceOfSlices := [][]int{{2, 4, 6}, {1, 3, 5}}

Pros and Cons

Slices of slices are more compact, efficient, and better if you want to preserve ordering. Maps can be easier if you want an explicit key to access each inner sequence.

Common Pitfalls

Index Out of Range: Ensure you check the length of the slice before accessing an index.
Memory Leaks: When deleting elements, be cautious of memory leaks due to residual references.
Capacity Issues: Be mindful of slice capacity to avoid unnecessary allocations.

Conclusion

Slices of slices might take some getting used to, especially if you're coming from a different programming background. However, they are an incredibly useful and efficient way to represent nested sequences in Go. From separating data into buckets to representing complex structures like game boards, slices of slices offer both flexibility and performance. I hope this guide helps you get comfortable with slices of slices and see its potential in your Go projects. Happy coding!