I heard something similar on a radio show once. Couldn’t tell you which one. But it stuck.

That’s kind of the problem I’m writing about, actually. Things stick but don’t finish forming. I consume a lot, articles, books, podcasts, specs. The Signal double ratchet spec at 2am, Meditations in the afternoon, some random Hacker News thread in between. The input is constant. The output is mostly silence.

Not because I have nothing to say. I think I do. It’s more that the gap between having a thought and being able to write it down cleanly is wider than I expected. The thought exists. Getting it out is the part that requires something I don’t always have.

I’m aware I care too much about what people think. It comes up even when I know it’s irrational. There’s a half-decent evolutionary argument for why, if the group rejected you as a caveman you were actually dead, but knowing the origin doesn’t make the feeling go away. It just makes you slightly more annoyed at yourself for having it.

That anxiety shows up in writing specifically. Every sentence feels like a position I’ll have to defend. So I think longer instead of writing sooner, waiting for the thought to feel airtight. But thinking alone doesn’t close the loop. It just keeps the thought in that comfortable vague state where it’s still potentially brilliant and hasn’t been tested by actually existing yet.

The mental math thing is the right analogy. You don’t expect to do long multiplication in your head. Nobody calls that a failure. But we expect real opinions to arrive fully formed, silently, before we’re allowed to say anything. As if writing is just transcription, you think it, then you write it down. That’s not how it works. Writing is how you find out what you think. It’s the paper you reach for when the problem gets complex enough to need it.

Most of what I’ve figured out that actually feels solid on ORMs, on cryptography, on how I want to build things, came from trying to explain it to someone or write it down. The understanding didn’t precede the writing. The writing produced the understanding.

The stuff still sitting in my head half-formed? I’m not sure it’s actually there the way I think it is. It might just be familiarity mistaken for knowledge. I’ve read enough to recognize ideas when I see them. That’s not the same as having worked them through.

Aurelius wrote: soon you will have forgotten all things, and all things will have forgotten you. He didn’t mean it as doom. He meant it as permission. If the scoreboard resets anyway, the draft that embarrasses you today costs nothing. The thought you never wrote down costs everything because you never actually finished thinking it.

Everything else is still mental math on a problem that’s too big for my head.

Rome

In his Meditations, Aurelius does something specific with mortality that most people miss. He doesn’t just say you’re going to die. He turns it into a question: what exactly are you afraid of losing?

That’s where the work is. Because most of what people are afraid of losing, reputation, money, status, the approval of people who won’t remember their name in fifty years, collapses under even gentle scrutiny. Aurelius wrote: soon you will have forgotten all things, and all things will have forgotten you. Your fortune won’t grieve you. To anchor your life to these things is to tie yourself to smoke.

Child’s play

If nothing lasts, why do anything at all?

I remember watching a video on Atman and Brahman that put it in a way that stuck with me. It said: think of a small child playing cricket. They know, on some level, that this game won’t matter. And yet they give everything. They appeal every decision. They argue over wides. For that moment they are fully in it. Then the game ends, they get sad or happy depending on how it went, pack their stuff, and go home.

That’s it. That’s the whole thing. The game was always temporary. The giving everything was always the point. A life practically meant to have no meaning gets its meaning exactly from playing it like it does. Nothing mattering cosmically doesn’t mean all choices are the same in the time you have. It just means you get to choose the game.

Artha

Growing up in India, Dharma, Artha, Kama, Moksha weren’t concepts I discovered in a book. They were just in the air, at home, in school, in how people talked about what a life should look like. Chanakya especially stuck with me. Not because he was the most spiritual, but because he was the most honest about how the world actually works. His idea that without material strength even truth has no protection made sense in a way that pure renunciation never did. You still have to live a life. You can’t move to the mountains and take sanyasa every time you’re looking for meaning.

Bhishma spends a significant portion of the Mahabharata advising Yudhishthira on how to actually rule not just how to be good, but how to function. His point isn’t that wealth is the goal. It’s that dharma needs a foundation, and that foundation is material. You can’t protect what’s right if you have nothing to stand on. Chanakya says the same thing in the Arthashastra. The ancients weren’t telling you to escape the world. They were telling you to be strong enough to operate in it without losing yourself.

Aurelius ruled an empire. Seneca was one of the richest men in Rome. Virtue doesn’t mean poverty. It means power under control. The enemy was never ambition. The enemy was letting ambition own you instead of the other way around.

Rafa

Once you accept the scoreboard resets, something changes about how you play.

There’s a documentary where Nadal talks about winning. Victory feels good, he says, but it’s momentary. What stayed with him was the desire to keep fighting. The satisfaction of doing something hard. He took something from the suffering itself, not just the result.

Before the 2008 Wimbledon final, Federer’s surface, 5 back to back titles on for a 6th, everyone expected Federer to win, Nadal said something that’s stayed with me. He knew Roger was probably the better player on grass at a pure skill level. His thought going in was: I am willing to suffer more than him. Winning is an event. Competing is an identity. And the only way you can sustain that, the only way suffering becomes something you choose rather than something that breaks you, is if the scoreboard isn’t carrying the full weight of meaning.

There’s a version of this where you just tell yourself victory is coming, it’ll all be worth it eventually. That works until you realize winning isn’t guaranteed. Then it falls apart. The more durable version is simpler: the scoreboard resets anyway, so having a shot is the thing. Not whether you win or lose it.

I won’t pretend this is easy to live by. It’s easier to say than to implement. But it works when you need it most, when the outcome is out of your hands and the only thing left is whether you kept going.

So what should fill that blank Aurelius left, what are you actually afraid of losing?

For him the answer was internal. Virtue. The ability to act with courage, with honesty, without flinching. Death only matters if it interrupts that. And if that’s what you’re protecting, the solution is immediate: practice it now, while you still can.

You could leave life right now. Let that determine what you do and say and think.

The whisper in the chariot wasn’t a curse. It was a compass. It pointed away from the things that don’t survive you and toward the one thing that does, who you were while you were here, what you were willing to go through, whether you played it seriously or spent your time protecting yourself from the possibility of losing.

The scoreboard resets. It always does. The child packs their bag and goes home. What mattered was how they played.

People act like using an ORM is some sort of higher-level abstraction that makes life easier. In reality, it hides the actual thing you care about, your SQL and replaces it with a Rube Goldberg machine of struct tags, magic method chaining, and runtime query generation. And then they call it “maintainable.” It’s a trap. A convenient-looking trap.

The “One Model to Rule Them All” Fallacy

On paper, having a single model seems like a good idea. But once you get into any real-world scenario, it becomes a mess. Suddenly, the field that makes sense for the DB (sql.NullString or a custom nullable type) becomes a pain in the API layer. And if you want to omit that field in some response? Tough luck. You’re stuck with a struct that’s trying to do five jobs at once. It’s the god function problem, but with data.

When you split your models, one for DB, one for API, suddenly your logic gets cleaner. You don’t worry about some random tag breaking your DB logic. You can shape your API payloads exactly how they should be, and your DB models can focus on what the database actually wants.

What About SQL Injection?

A common argument in favor of ORMs is that they protect you from SQL injection.

That’s only true if you’re writing raw SQL naively by string-concatenating user input directly into your queries. But nobody doing raw SQL seriously does that.

The actual solution is simple and safe: use prepared statements.

All modern database drivers support them. Whether you’re using Go, Node.js, Python, or Rust, parameterized queries are easy and idiomatic. You pass values as arguments, and the driver handles escaping and query planning safely.

No ORM magic required. No injection risk.

ORMs Make Easy Things Easy and Hard Things Impossible

Yes, ORMs can make the basics easier. User.find(...), .save(), .delete() — fine. But try writing a query that actually touches real business logic: something with joins, aggregates, filters, maybe window functions. Now your nice ORM abstraction becomes a maze of nested includes, prefetches, or custom query builders that fight the underlying database every step of the way.

Ever debugged an n+1 query problem in an ORM? Good luck. Prefetching in ORMs is usually painful and opaque. With raw SQL, you just write the join.

Runtime Queries: Performance Red Flag

Most ORMs build and compile your queries at runtime, based on struct tags and method chaining. That means every query is dynamically assembled when the code runs. You don’t get to see the final query easily. You don’t know what exactly is sent to the database unless you enable logging and reverse-engineer it.

Why?

You’re using a straightforward language like SQL, but then instead of writing that directly, you wrap it in a JavaScript-style query builder or some DSL. And now you have to trust that it’s doing the right thing.

Someone might argue: But manually writing SQL and mapping table fields to code wastes time, what about type inference, syncing column names, etc.?

Fair. That would be painful if you had to do it all by hand.

But you don’t. That’s where tools like sqlc shine.

You write your SQL. It parses it and auto-generates type-safe Go code from it. No need to manually map types. It’s fast, ergonomic, and works with lightweight drivers. You get static analysis and full compiler support—with zero runtime reflection or dynamic DSLs.

Bottom Line

If you care about:

• Performance
• Debuggability
• Query clarity
• Explicitness
• Clean separation of concerns

then you shouldn’t be using an ORM.

Use a tool like sqlc that gives you the best of both worlds: real SQL + generated types. It’s fast, safe, and transparent. And most importantly, it respects your database instead of pretending it’s a Java object store.

Inspired by Jeff Atwood

And then came Vercel.

At first, it looked like a natural evolution, Vercel backing Next.js brought with it resources, momentum, polished DX, and incredible iteration speed. What most people didn’t fully realize at the time was that Vercel wasn’t just supporting Next.js. They were transforming it.

Today, Next.js isn’t just a framework anymore.
It’s a gateway to an entire platform experience, arguably one of the smartest product-led growth plays we’ve seen in the devtools space.

Every New “Feature” is an Infra Feature

And that’s where the magic really kicks in.

Look at the last few years of Next.js evolution: App Router, Middleware, ISR, Image Optimization, Edge Functions; every single one of these is more than just a code-level feature. These are infrastructure-powered capabilities wrapped in a developer-friendly API.

They look and feel like framework features, but underneath, they’re tightly coupled with execution models, caching layers, and distributed systems that Vercel already built for you.

Try to use them outside of Vercel, and it becomes clear: you’re not just dealing with functions and files anymore, you’re dealing with behaviors, caching semantics, invalidation logic, and routing models that were designed to shine on their infra. Self-hosting these features is possible, sure, but it comes with an operational tax. And that’s the brilliance: the deeper you go into Next.js, the more sense Vercel’s platform makes.

You’re Not Just Building with Next.js, You’re Buying Into a System

What Vercel pulled off is impressive.

They didn’t just build a hosting provider. They built an entire deployment-native framework, one where the best parts come alive only when used together with their infra stack.

Middleware? That’s not just a simple code hook, that’s an edge-native function runtime optimized for Vercel’s network.
ISR? That’s not just a static regeneration trick, that’s backed by intelligent caching, revalidation orchestration, and routing behavior baked into their platform.
Image optimization? That’s not just a utility, it’s directly tied to their CDN and storage layer.

You’re not just writing a Next.js app. You’re building for the Vercel runtime, whether you realize it or not. And that’s kind of genius, because it means the more you use the framework, the better the platform feels.

And Yes, You Pay for That

Of course, there’s a cost, but it’s not just a cost, it’s a business model.

On Vercel, you don’t pay for servers. You pay for outcomes:

• Edge function executions
• CDN bandwidth
• Image transformations
• Region-aware cold starts
• Caching, routing, invalidation, orchestration

You’re not renting a box. You’re paying for the execution of every micro-primitive that enables your app to scale instantly across the globe.

And as your app grows, the platform grows with you, and yes, the bill grows too. That’s the tradeoff: frictionless scaling in exchange for platform-native architecture. For startups it feels magical. For enterprises, it’s predictable. For Vercel, it’s recurring revenue, and it’s brilliant.

Can You Leave? Technically, Yes.

But that’s the kicker, by the time you consider moving away, you’ve already adopted half a dozen features that weren’t just framework-level decisions.

They were infra-coupled by design.

Leaving means rebuilding those pieces yourself:

• Your own ISR cache and invalidation system
• Your own CDN-backed image optimizer
• Your own edge runtime logic and routing layer
• Your own regional cold-start mitigation

At that point, you’re not just migrating. You’re rewriting. And it’s not just effort — it’s architectural debt. Most teams choose to stay, and honestly? That’s what makes it such a masterclass in developer-led growth.

Verdict

Vercel didn’t just build a hosting platform. They built an ecosystem.

They blurred the line between framework and infrastructure so cleanly that most developers didn’t even notice it happening.
They took something as technical as deployment and turned it into a seamless, scalable extension of your codebase.
They gave Next.js a superpower, and in the process, made their own platform indispensable.

Next.js didn’t just evolve. It became the front door to Vercel’s infrastructure.
And if we’re being honest, it might be the most effective vendor strategy the frontend world has ever seen.

A framework disguised as a product disguised as a platform.
That’s not a trap. That’s marketing brilliance.

We blindly entrust our most sensitive data to protocols most of us can’t explain. What is the actual engineering chain that guarantees secrecy when anyone could be listening? When you peek under the hood, the reality is stranger, smarter, and far more elegant than any marketing slogan.

This is a deep dive into that chain. We’ll dissect the engines powering modern secure messaging, from the math that creates a secret in plain sight to the engineering that closes every loophole.

Secret in Public

Two parties, Alice and Bob, require private communication. Their only channel is insecure; an eavesdropper, Eve, sees everything. If Alice encrypts her message, how does she safely deliver the key? This is the canonical problem of cryptography: agree on a secret over a public channel.

The solution lies in one-way functions: operations that are easy to compute but computationally infeasible to reverse. A specific subset you may know are trapdoor functions, which are reversible only with a secret piece of information. The key exchanges we’ll dissect are even more pure, relying on one-way functions with no trapdoor.

The classic paint analogy illustrates this perfectly:

1. Alice and Bob agree on a public color: Yellow.
2. Alice secretly picks Red, mixes it with Yellow to get Orange, and sends it publicly.
3. Bob secretly picks Blue, mixes it with Yellow to get Green, and sends it publicly.
4. Alice mixes Green + her secret Red → Brown. Bob mixes Orange + his secret Blue → Brown.

Eve sees only the public mixes. She cannot deduce the secret components. They’ve established a shared secret in plain sight.

The First Engine: Diffie Hellman

Diffie Hellman was the first algorithm to turn this paint-mixing idea into a machine of numbers.

• The One-Way Function: Modular Exponentiation (Result = base ^ exponent mod prime). Reversing this is the Discrete Logarithm Problem (DLP) computationally intractable for large numbers.

Let’s walk through the math with small numbers.

1. Public Agreement: Alice and Bob agree on a prime p = 23 and a base g = 5. Eve knows these.
2. Secret Keys:
   • Alice secretly chooses a = 4.
   • Bob secretly chooses b = 3.
3. Public Exchange:
   • Alice calculates 5^4 mod 23, which results in a remainder of 4. She sends A = 4 to Bob.
   • Bob calculates 5^3 mod 23, which results in a remainder of 10. He sends B = 10 to Alice.
4. The Shared Secret:
   • Alice computes 10^4 mod 23, which results in a remainder of 18.
   • Bob computes 4^3 mod 23, which also results in a remainder of 18. In real systems, these numbers scale to hundreds of digits, ensuring security. But the computational cost is high.

The Modern Engine: The Dance of Elliptic Curves

The demand for performance led us to Elliptic Curve Diffie-Hellman (ECDH). They offer equivalent security to Diffie-Hellman with drastically smaller keys, making them faster and more efficient.

The one-way function is Scalar Multiplication (k*P). Geometrically, this is visualized as “adding” a point P to itself k times along the curve according to specific rules.

1. To get 2 P:* Draw a line perfectly tangent to the curve at point P. This line will hit the curve at one other spot. Reflect that spot across the horizontal x-axis. That new point is 2P.
2. To get 3*P: Draw a straight line from our original point P through our new point 2P. That line will hit the curve somewhere else. Flip that point across the axis, and you have 3P.

Given a starting point P and a final point Q, it’s impossible to deduce k. That’s the Elliptic Curve Discrete Logarithm Problem (ECDLP). But how does a computer actually “draw tangent lines” to compute k*P? Let’s get concrete. The most intuitive implementation is a classic algorithm called Double-and-Add. It translates the scalar k into a series of point doublings and point additions, directly analogous to its binary representation.

For a secret key k = 22 (binary 10110), the computer does the following:

• It scans the bits of k from left to right.
• For every bit, it performs a Point Double.
• Only when the bit is a ‘1’, it also performs a Point Add.

The calculation for 22*P would unroll like this:

This works beautifully. But that simple if bit == '1' check the very heart of the algorithm’s logic is a catastrophic vulnerability. Mathematical elegance often introduces subtle, practical flaws.

Side-Channel Attacks

The mathematics of ECDH are strong, but the hardware it runs on can leak secrets. This is where the physical world brutally intrudes on abstract math. An attacker doesn’t need to break the ECDLP; they just need to listen to your processor.

The Double-and-Add algorithm has a fatal flaw: its execution path depends on the secret data.

• If a bit of your key is 0, the CPU performs one operation (Double).
• If a bit of your key is 1, the CPU performs two operations (Double and Add).

This difference, no matter how small, is a signal. An attacker can measure this signal to extract your key, bit by bit.

• Timing Attacks: A Point Add takes a few hundred extra nanoseconds. By precisely measuring the total time of the scalar multiplication over thousands of attempts, an attacker can statistically determine how many ’1’s are in your key. A more direct attack measures the time per loop: a short loop reveals a ‘0’, a long loop reveals a ‘1’. One microsecond can leak everything.
• Power Analysis: This is even more devastating. Different CPU instructions consume different amounts of power. By attaching an oscilloscope to the device’s power line, an attacker can get a “power trace” of the computation. They can literally see the difference: a small power blip for a Double, and a larger, distinct power blip for a Double followed by an Add. The pattern of blips on their screen is a direct readout of your secret key.

The Hardened Engine: Montgomery Ladder

The solution is not stronger math, but smarter engineering: constant-time algorithms. The algorithm’s operations must be completely independent of the secret data’s value. The gold standard here is the Montgomery Ladder.

• Mechanism: The genius of the Montgomery Ladder is its elimination of the data-dependent if branch. Instead of one running total, it cleverly maintains two points, R0 and R1. In every single loop iteration, it performs exactly one point addition and one point doubling, regardless of whether the secret key bit is a 0 or a 1.

At first glance, this looks like sleight of hand. How does doing a fixed dance of one add and one double per bit still give the right result, k*P? The answer is the ladder’s core invariant.

The Secret of the Montgomery Ladder: The Invariant

The algorithm preserves a single relationship across all iterations:

R1 - R0 = P

In every branch, the invariant survives. That invariant is what ties the operations back to correct scalar multiplication.

Let’s look at its logic:

Initialize:
    R0 = Point at Infinity
    R1 = P
    // Invariant: R1 - R0 = P - O = P

For each bit in the secret key k:
  if bit == 0:
    R1 = R0 + R1  // One Add
    R0 = 2 * R0   // One Double
    // Check invariant:
    // (R0 + R1) - (2*R0) = R1 - R0 = P
  else: // bit == 1
    R0 = R0 + R1  // One Add
    R1 = 2 * R1   // One Double
    // Check invariant:
    // (2*R1) - (R0 + R1) = R1 - R0 = P

How the Invariant Builds Scalar Multiplication

Track R0 as the bits of k are processed from left to right. After i bits, R0 equals kᵢ*P, where kᵢ is the integer represented by those i bits.

Example: k = 22 (binary 10110). Walk through the ladder:

Start: k = (empty), R0 = O = 0*P, R1 = P

Result: After processing all the bits of k, the register R0 holds the final result: 22P.

The workload is identical in both branches. The only difference is which register receives the result, a detail that is invisible to a power or timing attacker. The “long loop” vs “short loop” signal is gone. The power trace becomes a monotonous, repeating pattern, sealing the leak.

The Special Sauce for X25519

On a generic curve, the point addition R0+R1 and doubling 2*R0 are moderately expensive. Critically, to add two different points (x1, y1) and (x2, y2), you need all four coordinates.

However, on a Montgomery Curve, the specific operations used in the ladder (differential add and double) can be performed using only the x-coordinates of the points. You don’t need the y-coordinates at all during the loop. This makes the calculations drastically faster and simpler, requiring less code and fewer CPU cycles. The curve shape itself is purpose built to make its security algorithm, the Montgomery Ladder, run as fast as humanly possible.

This constant-time ladder is the core of X25519, but the protocol’s hardened design goes even further, making it an opinionated system engineered from the lessons of past failures.

• No Input Validation: Unlike older curves that require slow, error-prone public-key validation, X25519’s math accepts any 32-byte input, neutralizing classical “Invalid Curve Attacks.” It computes a valid shared secret regardless of the input, but sloppy protocol use can still shoot you in the foot.
• Scalar Clamping: Before use, the secret scalar k is passed through a clamping function. This is a crucial, non-optional safety measure. It forces specific bits of the key into a known state (k[0] &= 248; k[31] &= 127; k[31] |= 64). This mitigates a variety of sophisticated attacks, including small subgroup attacks, and ensures the Montgomery Ladder operates on a correctly formatted scalar.

X25519’s design philosophy is to make the secure path the only path.

Beyond Secrecy: The Problem of Integrity

The handshake is done. We have a key. But here’s the catch: the beautiful, heavy mathematics of X25519 are for building bridges, not for moving traffic. They are brilliant for establishing a shared secret but far too slow to encrypt every single message. Imagine running that entire elliptic curve dance for every text you send your phone’s battery would die by lunch.

So, we use a hybrid approach. The heavy math (asymmetric) is run once to derive a lightweight, lightning-fast symmetric key. This key is then used with a symmetric cipher like AES to do the actual work of encrypting data.

This is where a new, more insidious class of attacks emerges. We’ve solved the secrecy problem, but we’ve created an integrity problem. Early encryption methods locked the box but failed to put a seal on it.

Let’s look at a classic, now-deprecated mode called Cipher Block Chaining (CBC). The core problem it tries to solve is that if you encrypt the same block of data twice with the same key, you’ll get the exact same encrypted block. This leaks information. Imagine an image where large areas are the same color; in an unchained mode, those would create visible, repeating patterns in the ciphertext.

CBC’s solution is to chain the encryption of each block to the one before it. It does this using the XOR operation. To encrypt a block of plaintext, you first XOR it with the previous block of ciphertext.

Why XOR? Because it’s a perfect, reversible “scrambler.” XOR is a bitwise operation that acts like a toggle switch. If you XOR a value A with a key K, you get a scrambled result C. If you XOR C with the exact same key K again, you get your original value A back (A ⊕ K ⊕ K = A).

In CBC, the previous ciphertext block acts as that single-use, per-block “key.” It scrambles the plaintext before it even enters the main encryption engine. This ensures that even if you have two identical plaintext blocks, P1 and P2, they will be XORed with two different ciphertext blocks (C0 and C1) before being encrypted. The inputs to the AES engine will be different, so the final outputs (C1 and C2) will also be completely different. It’s a clever way to ensure no patterns are repeated, but as we’ll see, this very mechanism is also its greatest weakness.

This very mechanism creates a fatal flaw, it makes the ciphertext malleable. An attacker can tamper with the encrypted message and produce predictable changes in the decrypted text all without ever knowing the key.

Let’s stage the attack. You are sending an encrypted bank transfer instruction: {"from":"Alice","to":"Eve","amount":"100"}

Eve intercepts the ciphertext. She can’t read it, but she knows the format. She wants to change that “100” to “900”. Here is the precise, devastatingly simple mechanic she uses:

Plaintext_Block[i] = Decrypt(Key, Ciphertext_Block[i]) ⊕ Ciphertext_Block[i-1]

The attacker cannot touch the Decrypt(Key, ...) part, that’s protected by the secret key. But she has complete control over the previous ciphertext block Ciphertext_Block[i-1].

She knows that whatever change she makes to Ciphertext_Block[i-1] will be XORed directly against the output of the decryption, right before it becomes the final plaintext.

So, she crafts a Tampering Mask, she then modifies the ciphertext block that comes just before the block containing the amount: Tampered_Ciphertext_Block[i-1] = Original_Ciphertext_Block[i-1] ⊕ Mask

When the receiver decrypts, this happens:

Final_Plaintext = Decrypt(Key, Ciphertext_Block[i]) ⊕ Tampered_Ciphertext_Block[i-1] Final_Plaintext = Decrypt(...) ⊕ (Original_Ciphertext_Block[i-1] ⊕ Mask) Final_Plaintext = (Decrypt(...) ⊕ Original_Ciphertext_Block[i-1]) ⊕ Mask Final_Plaintext = Original_Plaintext ⊕ Mask

The result? The receiver’s machine decrypts the message perfectly, without any errors. But the plaintext it sees is {"from":"Alice","to":"Eve","amount":"900"}. Integrity has been silently destroyed.

This is why modern systems use Authenticated Encryption with Associated Data (AEAD), with AES-GCM being the gold standard. AEAD provides a non-negotiable two-for-one deal: secrecy and integrity.

Here’s how it neutralizes the attack. An AEAD cipher produces two outputs:

1. The Ciphertext: The encrypted, unreadable data.
2. An Authentication Tag: A small, fixed-size cryptographic checksum. Think of it as an unforgeable, tamper-evident seal.

If an attacker alters even a single bit of the ciphertext, the seal is broken. When the recipient tries to verify the tag against the tampered message, the check will fail, and the software will immediately discard the message. No more silent manipulations.

But how does this tag, this short string of bytes, guarantee the integrity of the entire message, from the first byte to the last?

It does this through cryptographic accumulation. The tag is not just a hash of the last block. It’s the final state of a process that has sequentially mixed in every single block of the ciphertext.

Imagine a mixing bowl:

1. The process starts with a secret value derived from the key, let’s call it the Authentication Key H.
2. The first block of ciphertext is thrown into the bowl and mixed with H. The result is a new, scrambled value.
3. The second block of ciphertext is thrown into the bowl, which still contains the result from previous step. It’s all mixed together again with H.
4. This continues for every block. The state of the mixing bowl at any point is a function of everything that came before it. A change to the first block creates a different result in the next one, which then snowballs, causing every subsequent state to be completely different.

By the end, the value in the mixing bowl is a holistic representation of the entire, ordered sequence of ciphertext blocks. This final value is then encrypted one last time to produce the tag.

When the receiver gets the message, they perform the exact same mixing ritual on the ciphertext they received. If their final tag matches the one the sender sent, it is cryptographic proof that the message is authentic and has not been altered in any way.

With AEAD, the box is not only locked; it has a seal that is intrinsically tied to the exact contents of the box. Break the seal, and everyone knows. This is why modern secure messaging relies on AEAD: it protects both the secret and ensures it hasn’t been messed with along the way.

Forward Secrecy

Our system is secure. But what if a key is compromised years from now, could someone dig up old conversations and read them? That’s exactly the kind of problem the Double Ratchet Algorithm, by Signal, was built to solve. It keeps past messages safe and even lets the system recover after a compromise by rotating keys with every single message.

That’s a rabbit hole for another day I’ll cover it properly in a future post. But if you want to peek under the hood right now, the signal spec is the best place to start.

So when I head of Dodo Payments, I was skeptical. Another payments SDK, I groaned. But I had a project to integrate, so I blocked off my afternoon.

I finished it before my second coffee.

The whole thing boils down to a pattern that feels less like a traditional payment integration and more like implementing “Sign in with Google.” And that’s the point. It’s basically OAuth for money.

The Dance: How it Works

If you’ve done any social auth, you already know this pattern:

1. Your Server -> Dodo: Your server calls its own endpoint to say, “Hey, I need a checkout link for this product.”

2. Dodo -> User: Dodo gives you back a secure, one-time URL. You redirect the user to it.

3. User -> Dodo: The user fills out their payment info on a page hosted by Dodo. Your app never sees a credit card number, so PCI compliance is not your problem.

4. Dodo -> Your Webhook: Dodo pings your server to say, “Hey, that user paid. Or they didn’t. Here’s the result.”

This model keeps the sensitive stuff off your servers and makes the integration shockingly simple.

1: Configure in the Dashboard

First, get your API keys from the Dodo dashboard. While you’re there, create a “Product” and set your webhook URL (e.g., https://yourapp.com/api/webhooks). This is the “few clicks” part no code required.

2: Create a Checkout Endpoint

Add a single API route to your server. The Dodo adapter exposes a Checkout function that you initialize with your API key. This five-line file becomes a complete, secure endpoint that securely communicates with Dodo’s API to generate a one-time checkout URL.

import { Checkout } from "@dodopayments/nextjs";
import { appConfig } from "#/lib/config";

export const POST = Checkout({
  bearerToken: appConfig.dodo.apiKey,
  returnUrl: appConfig.dodo.returnUrl,
  environment: appConfig.dodo.environment,
  type: "session",
});

3: Trigger the Flow

From your frontend, make a request to that endpoint. You can pass custom metadata like your internal orderId or userId. This is the key to connecting the payment back to your application’s state. The adapter handles the redirect automatically.

Here’s the code:

export async function createCheckoutAction(formData: FormData) {
  const productId = formData.get("productId") as string;
  const orderId = `order_${crypto.randomUUID()}`;

  await db.createOrder({ id: orderId, status: 'pending' });

  const response = await fetch(`${process.env.APP_BASE_URL}/api/dodo/checkout`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      product_cart: [{ product_id: process.env.DODO_PRODUCT_ID, quantity: 1 }],
      metadata: {
        internalOrderId: orderId,
        internalProductId: productId,
      },
    }),
  });

  const { checkout_url } = await response.json();
  return { checkout_url };
}

The crucial part is the metadata. I create my own order record in my database before sending the user to Dodo, and I pass my internal orderId along. When Dodo calls my webhook later, it will include this metadata, so I know exactly which order to update.

4: Handle the Webhook

This is where I usually lose my mind. Verifying cryptographic signatures, checking timestamps to prevent replay attacks… it’s a minefield.

I instinctively started writing a function to parse the webhook-signature header, hash the body with my secret key, and do a timing-safe comparison. I spent 20 minutes on it before realizing the adapter does this for me. Again. Sometimes reading the docs first is actually a good idea.

The Dodo adapter does all that for you. You just provide your business logic:

import { Webhooks } from "@dodopayments/nextjs";
import { appConfig } from "#/lib/config";
import { db } from "#/lib/db";

export const POST = async (req) => {
  const handler = Webhooks({
    webhookKey: appConfig.dodo.webhookSecret,

    onPaymentSucceeded: async (payload) => {
      const internalOrderId = payload.data.metadata?.internalOrderId;
      if (internalOrderId) {
        await db.query(
          "UPDATE orders SET status = 'succeeded' WHERE id = $1",
          [internalOrderId]
        );
        console.log(`Order ${internalOrderId} marked as successful.`);
      }
    },

    onPaymentFailed: async (payload) => {
      // ... update DB to 'failed'
    },
  });

  return handler(req);
};

Here’s a simple sketch of that flow:

The model is dead simple: your app never touches card numbers. You redirect the user out, Dodo runs the payment, and they call your webhook with the result. If this smells familiar, it should—it’s basically OAuth but for money. Think of “Log in with Google”: you hit your own server, it redirects to Google, user does the auth, Google calls back your redirect URI, and you finish up. Same pattern here, just applied to payments.

The best part is you can get from zero to working checkout in minutes, not days. Which, if you’ve ever had to do payment integration the “traditional” way, feels like cheating.