its been 9 months so heres some stuff

people

• ive grown alot. like im just a pretty diffrent person than who showed up here 9 months ago
• met so many new people its kind of crazy
• connections mean everything honestly. pretty much every good thing thats happened here came from a person, someone introducing me to someone or inviting me somewhere or just texting back

work

• built alot of stuff. some shipped some was just for fun some will never see the light of day and thats fine
• learned alot technically too mostly by breaking things and then having to fix them
• almost 2 years as a software engineer now so im almost not a junior anymore which is wierd to think about

the house

• i miss my dog. every day. petting other peoples dogs helps a little but not really
• my house plants are my favorite thing. they dont talk back and they dont need walks and when one grows a new leaf i feel like i did something
• get out of the house. this ones mostly a note to myself. the house is nice and the plants are nice but theres a whole state out there

back home

• i still think about home alot. like more than i thought i would
• i think about past decisions too. the big ones and the tiny ones that didnt feel like anything at the time
• and all the diffrent ways my life couldve gone. if i said no to moving here or picked a diffrent job or stayed where i was. theres probably a version of me doing totally fine somewhere else and i think about him sometimes

whats next

• still not sure where im headed. maybe its here maybe its not here. maybe its this job or another job. maybe its work maybe its world travel
• and im trying to be ok with that. 9 months ago i didnt know id be here either

I am a very statistical person. I have always loved numbers since I was a kid. Every school project, many personal projects, and many observations I have resolve around numbers, statistics, and patterns. I was also raised in a household that had several very successful businesses but was also a very religious house. These three things combined created a couple unique interests of mine.

Interest 1: Religious Statistics

I loved reading about religion. Any type, any beliefs, any culture, any location. Seeing the fall of Christianity in Europe and Americas while seeing the rise of it and Islam in Africa. Seeing countries that always integrated religion into government slowly phase it out and become “woke.” These things interested me.

Interest 2: Economic Statistics

Taking religion out of the picture, I was still interested in finances, numbers, and world economics. I think this one is a little less unique. Nonetheless, I was still interested in researching things like Chinas development on capitalistic zones, seeing how the US govt debt is actually used in a beneficial extent. Seeing how money flows in startups and through VC and investment firms, and more recently researching liquidity problems in the stock market.

Observations

One of the observations I noticed first in my life was the decline or stagnation of religion in first world countries and the continued high success of religion in povershed countries.

%% caption: The poorest countries on this list are the most religious.
xychart-beta
    title "Religion important in daily life, 2024-25"
    x-axis [Niger, Bangladesh, Malawi, Uganda, Kenya, Nigeria, Mexico, Portugal, Chile, US, Poland, Germany, UK, Japan, Sweden, Norway]
    y-axis "% of adults" 0 --> 100
    bar [100, 99, 99, 98, 95, 89, 67, 59, 57, 51, 47, 34, 30, 21, 21, 17]

%% caption: Poorer countries stay even or slightly grow compared to significant decreases in first world countries.
xychart-beta
    title "Change in religiosity, 2010s (directional)"
    x-axis [Kenya, Nigeria, Malawi, Ethiopia, US, Australia, Chile, Uruguay]
    y-axis "change in % points" -20 --> 10
    bar [3, 2, 2, 1, -13, -17, -15, -14]

%% caption: We see most first world countries experience a slight movement but are already considerably low compared to their poorer counterparts.
xychart-beta
    title "Religion important in daily life: 2009 vs 2024-25"
    x-axis [Bangladesh, Niger, Senegal, Malawi, US, UK, France, Japan, Sweden]
    y-axis "% of adults" 0 --> 100
    bar [99, 100, 99, 99, 65, 27, 30, 24, 17]
    bar [99, 100, 99, 99, 49, 30, 25, 21, 21]

The second observation came a lot later and I think it is related. Birth rates do the same thing.

%% caption: Same countries in the same order as the first chart. The poorer ones have a lot more kids.
xychart-beta
    title "Total fertility rate, 2023"
    x-axis [Niger, Bangladesh, Malawi, Uganda, Kenya, Nigeria, Mexico, Portugal, Chile, US, Poland, Germany, UK, Japan, Sweden, Norway]
    y-axis "births per woman" 0 --> 7
    bar [6.6, 2.1, 3.8, 4.4, 3.2, 4.8, 1.8, 1.4, 1.2, 1.6, 1.2, 1.4, 1.4, 1.2, 1.4, 1.4]

This is the same list of countries in the same order as the first chart. I did not reorder anything. Niger is the highest on both. Japan is the lowest on both. Once you get to Mexico it flattens out into the same band between one and two kids, which is right around where the religion numbers flatten out too.

It is not perfect. Bangladesh is very religious and is already down to about two children per woman, so the two things can clearly come apart. Nigeria goes the other way. But two out of sixteen does not really change the shape of it.

Correlation is not causation and I am not going to act like it is. Being religious does not make you have kids and having kids does not make you religious. What I think is worth asking is why two totally different behaviors drop off at about the same income level, in the same decade, in close to the same order.

The Connection

I think the connection is that both of them used to be useful.

Religion cost you time and money and a list of things you were not allowed to do. What you got back was a community that showed up when you were sick, a reason to keep going when things were bad, and a set of rules you did not have to figure out yourself. For most of history that was worth it.

Children cost more. What you got back was labor and old age insurance. Somebody to take care of you at sixty, and enough of them that it still worked out if one or two did not make it. That was worth it too.

Neither one of those is worth it in a first world country anymore, at least not in the same way. I do not think that is people getting worse or losing their morals. I think it is people responding to their situation, which is what people always do.

Why This Happens

Take everything religion and children used to provide and look at what a first world country provides instead.

If you get sick you go to a hospital. If you lose your job there is unemployment and there is savings. If you get old there is social security and a 401k, and you do not need a son for any of it. If you are lonely there is a phone with more people in it than any church ever had. If you need rules there is a legal system. If you need something to organize your life around there is a career.

All of it is covered now. Usually worse and usually more expensively, but covered well enough that you never really hit the point where you would go looking for something else.

This is where the title comes from. Nobody prays in a warm house. I do not mean people in warm houses are smarter or that they figured something out. Praying is what you do when the house is cold and you are out of options. Take away the cold and the praying goes with it. Kids are the same. Nobody in Niger loves their kids more than somebody in Norway does. They are dealing with a problem that Norway already solved a different way.

The Dilemma

The part I keep coming back to is that the things a country drops on the way to being comfortable are the same things that got it comfortable.

You do not get to be a first world country without a lot of people having a lot of kids, and without enough shared belief in something to build things that outlast the people building them. Then the country succeeds, and a generation or two later the population looks at both of those and decides, correctly, that it does not need them anymore.

The bill for that shows up later and it shows up as arithmetic.

%% caption: How many working age adults there are for every person over 65. The 2050 numbers are projections but they are mostly already set.
xychart-beta
    title "Workers per retiree, 2025 vs 2050 (projected)"
    x-axis [US, UK, Germany, Italy, Japan, "South Korea"]
    y-axis "adults 20-64 per person 65+" 0 --> 4
    bar [3.1, 2.9, 2.6, 2.2, 1.8, 3.2]
    bar [2.3, 2.2, 1.8, 1.4, 1.3, 1.1]

South Korea is the one I would look at. It has the best ratio on that chart right now and the worst one twenty five years from now. That is not a prediction about how people are going to behave. Everybody who will be working in 2050 has already been born, so the top number is set. The pension system, the healthcare system, and most of the tax base of every country on that chart are running on a number nobody can change at this point.

Trying To Fix It

The obvious answer is that the government should pay people to have kids, and a lot of countries have tried this.

South Korea has spent somewhere over $200 billion on it since 2006. In that same window its fertility rate went from about 1.1 to about 0.7, which is the lowest number ever recorded anywhere. Hungary spends around five percent of GDP on family policy, which is more than it spends on its military, and it got a bump from about 1.2 to about 1.5 before it started sliding back. France has the most generous family policy in Europe and is still under replacement.

So the money does not seem to be the issue. I think you cannot pay somebody back into a behavior that only existed because it was necessary. Needing the subsidy is itself evidence that the necessity is gone.

Religion is the same. Countries have tried putting it back in the schools and back in the constitution and it does not move the numbers much, because what filled the churches was never a law.

What I Think

I am not writing this to say anybody should go back to church or have six kids. I do not think you can talk somebody into either one, and most of this post is my explanation for why.

What I think is that comfort has a cost and the cost is not money. The cost is that the behaviors that built the comfort stop making sense to the people who grow up inside of it. Every generation in the warm house is a little more confused about why anybody bothered building it, and a little worse at building another one.

I do not have a solution and I am pretty suspicious of anyone who says they do, especially since the countries trying the hardest have the worst numbers. What I have is the pattern, and the pattern is very consistent. Income goes up, religion goes down, births go down, and the difference gets covered with immigration and debt for however long that works.

I should also say that I am part of this, which is probably worth admitting after spending five charts pointing at other people.

I still follow religion. I was raised in it and I kept it and I do not really see that changing. But I am not planning on having kids. I have thought about it a decent amount and the honest answer is that none of the old reasons apply to me. I am not going to need them for work, I am not going to need them to take care of me when I am older, and everything else I would want out of it I can get some other way. That is the exact argument I just spent this whole post making. Knowing the argument does not seem to make me any less of an example of it.

So I am sitting somewhere in the middle of my own chart. I kept the cheap one and dropped the expensive one, which is more or less what Bangladesh is doing, just for completely different reasons. I think that is probably where a lot of people end up. Religion is a lot easier to hold onto than kids are because it does not ask for the same thing.

I am not sure if any of this is a problem or if it is just what happens. Probably some of both. But it is the most consistent thing I have found in all the years I have been looking at this stuff, and I have not seen anybody give a good answer for it, including me.

About a hundred commits later, the same repository contained a 1.3 GB play-by-play database, an ML discovery engine with a false-discovery-rate correction, a pre-registered prediction protocol, and a cron job placing real-money orders on Kalshi with my account.

The almanac is still there. But the honest summary of the project is that I built a toy, the toy demanded data, the data demanded a model, and the model demanded to be tested against a market — which promptly taught it some humility. This is the build log, including the parts that didn’t work, because those turned out to be the point.

A newspaper that replays games

Version one shipped with six games, each hand-reconstructed from public play-by-play: the ball through Buckner’s legs in ‘86, Dave Roberts stealing second in the ‘04 ALCS, Gibson off Eckersley, Freese twice down to his final strike, Mazeroski’s walk-off, Fisk waving it fair. You step through a game pitch by pitch, or let it auto-play, while a retro scoreboard tracks the score, inning, outs, and baserunners, and a win-probability chart scrubs along underneath. Drag across the chart and the game follows your cursor.

Two early decisions aged well. First, no charting library — the win-probability chart is hand-drawn SVG, which meant I owned every pixel when the design later got opinionated. Second, the win probability is derived, not fabricated. A small self-contained model combines the classic base-out run expectancy table (RE24) with a run estimate for the innings still to come, and reads the home team’s win probability off a normal approximation of the run differential. It’s an approximation and the site says so, but every swing in the chart traces back to a real change in game state rather than a designer’s sense of drama.

Around the replays grew the almanac furniture: an On This Day page, and the Oddities file — a shelf for unassisted triple plays, immaculate innings, and the hidden-ball trick.

Then Retrosheet happened

Six games is a demo. Baseball has a complete, public, volunteer-maintained record of essentially every game ever played, kept by Retrosheet, and once you know that, a hand-curated archive starts to feel like a placeholder.

So the project grew an ingest pipeline: Retrosheet’s event files, parsed with the Chadwick tools, loaded into SQLite. The game-log archive covers every game since 1901 down to the inning; the play-by-play era adds about 14.7 million plate appearances. The events database alone is 1.3 GB, which is a funny thing to find inside what is nominally a Next.js side project.

The archive turned the site from a museum into an instrument. A Scorigami explorer (every final score that has ever happened, and when it happened first), team pages for every franchise, an era toggle that follows you around the site, and replays rebuilt out-by-out from the real sequence of events — eleven of them now, not six.

The Lab: subtract identity until only the stories are left

With every game since 1901 in a queryable database, the tempting move is to go anomaly fishing: scan everything, surface whatever looks weird, write it up. The problem is that a century of baseball contains an enormous amount of weirdness by pure chance, and a scanner with no discipline becomes a machine for laundering noise into narrative.

The Statball Lab is my attempt to do it with discipline. The core trick is what I’d call identity-free residuals. For each target stat — runs, wins, home runs, strikeouts, walks, errors — a gradient-boosted model absorbs era and context: year, month, day or night, home or road. Then iterative backfitting removes each franchise’s, ballpark’s, and opponent’s long-run character. Team and park are deliberately not features of the model, because a tree ensemble would happily learn year×team interactions — which are exactly the deviations being hunted. Whatever is left in a residual cannot be explained by when the game happened, where it happened, or who was playing. If a residual still shows structure, something actually happened.

On top of those residuals sit thirteen analysis families: interaction subgroups (about twenty thousand of them), head-to-head matchup residuals, parsed line scores, schedule and fatigue effects, season-vector outliers via IsolationForest, year-over-year persistence, streak tests, detrended correlations, regime change-points, and so on. Everything that comes out the other side has passed Benjamini–Hochberg FDR control, batched permutation tests, and bootstrap confidence intervals. The engine writes its findings — with generated articles and chart specs — straight into the site.

The satisfying moments are when the machine rediscovers history blind. The schedule scanner, knowing nothing but dates and times, found the blue-law Sundays when Pennsylvania teams couldn’t play at home, and the decades of missing night games at Wrigley. The outlier family, working purely from the geometry of standardized season vectors, flagged Connie Mack’s fire-sale Athletics as one of the largest one-winter identity shifts in the sport’s history. And the innings family established that “down one run with three outs left” has been worth roughly the same slim chance for a century — a constant, stable across every era it can be measured in.

The Oracle: predicting tonight instead of explaining 1975

Explaining the past is safe. Every claim the Lab makes is checkable but also unfalsifiable in the way that matters: nothing is at stake. So the next step was a prediction system for real games — tonight’s slate, published before first pitch, scored after the last out.

The design constraint I cared most about was that the system couldn’t be allowed to flatter itself. So the protocol is pre-registered and frozen: the model’s coefficients were fit on data before May, the feature set is fixed for the season, and the evaluation code is treated as untouchable — editing it would be rewriting the yardstick mid-experiment. Every pick lands in a public ledger, scored game by game. When a model change looks promising, it goes into a walk-forward research harness, not into the live season.

The $100 experiment

Then came the obvious question: is any of this worth money? Kalshi runs prediction markets on MLB games, which means every night there’s a real price to disagree with.

The test was a $100 experiment replayed at real Kalshi prices over the May-to-early-July window, under the frozen protocol, with a few pre-registered strategies. The headline result was humbling, and it’s the single most important number the project produced: over that window, the Kalshi close was better calibrated than the model. Market Brier score 0.2459, model 0.2619. The market, aggregating everyone’s information, is simply sharper on average than my frozen regression.

But the experiment had a second finding. The only strategy line that made real money was the strong-edge line: bet only when the model disagrees with the price by five or more points, sized at quarter-Kelly. That line turned $100 into $141.85. The looser line that bet every two-point disagreement roughly broke even at $103.99 — and that’s before you get rigorous about fees.

Read together, those two results say something specific: you don’t profit by being smarter than the market on average, because you’re not. If there’s profit at all, it comes from the rare nights when the model and the market disagree a lot, sized fractionally, with costs priced in. Everything else is donating the spread.

Rebuilding the trader around a humbling result

The first live trader I wrote did not follow that lesson, and the design review that fixed it was essentially a list of ways I was quietly lighting money on fire.

The gate was confidence, not price: any pick the model liked at 62%+ got bet, even when Kalshi priced the same team higher than the model — a negative-expected-value trade against a market we had just measured as sharper. There was a 3% “base stake” on edgeless picks, which converted spread plus fees into a guaranteed drip out of the account, because Kelly on a zero edge is zero. And the fee math was missing entirely: Kalshi’s taker fee is 0.07·P·(1−P) per contract, about 1.6 cents at mid prices — roughly 2.5% of stake, which is larger than most of the edges being bet.

The rebuilt trader has one gate: net edge. A signal exists only when the model’s probability beats the ask plus the fee by at least five points — the pre-registered strong line, now net of costs — and only when the book is real (a live bid, a sane ask, a spread of six cents or less; a wide or one-sided book means the ask is stale, not cheap). Stake is quarter-Kelly on fee-adjusted odds, capped at 10% per position and 25% per day. No base bet. Each run cancels any resting order whose game has started or whose edge has evaporated. Model confidence is no longer consulted at all, because a 62% pick priced at 64 cents carries no information the price doesn’t already contain.

Operationally the whole thing is one Docker image on Railway with two jobs: the same container that serves the site becomes the cron trader when a flag is set. The trader defaults to dry-run; real orders require explicit intent. The live account — the Stake — is published on the site, wallet balance and all, because a track record you can edit isn’t a track record.

The graveyard

The part of the project I’m proudest of is the pile of features that don’t exist.

Model improvements go through a walk-forward harness: fit on the past, predict the future, slide the window, repeat across decades of seasons. No peeking. The harness has now rejected, in order: lineup rating channels, bullpen rating channels, platoon structure, park-specific home-field advantage, starter rest days, and a seed-ensemble scheme. Built, tested, flat. Every one of them is a real effect you can find in-sample; none of them survived out-of-sample at game granularity, where a 60/40 edge is enormous and most true signals are already soaked into the base rates the model carries anyway.

Each of those features would have made the model feel smarter. The walk-forward harness is what stands between “feels smarter” and the live account, and its job is to say no. Meanwhile the live system tracks the two leading indicators that actually predict whether this ends well: closing line value — whether the market moves toward our price after we bet — and the slowly accumulating forward sample.

A note on process: the four-day sprint from scaffold to trading engine was pair-work with Claude Code — it did the typing and a lot of the arguing, I made the calls. What kept the speed from becoming recklessness wasn’t either of us being careful in the moment; it was that every model idea, no matter who proposed it, had to survive the same frozen protocol and the same walk-forward gauntlet. Process beats vigilance.

What I actually built

The about page says it in one line: Statball builds baseball models. The models are proprietary; the results are not. The site has grown the full costume of a quant firm — a research page, a published model card, a live trading desk, even a careers page with application questions — and the costume is doing real work, because the firm framing imposes the right obligations. Firms publish track records. Firms eat their fees. Firms don’t retrain the model mid-season because last week felt bad.

Underneath the costume, what I actually built is a discipline machine. The almanac was the fun part. The archive made claims checkable. The Lab added multiple-testing hygiene so the archive couldn’t be strip-mined for fake stories. The frozen protocol made predictions falsifiable. The market priced them, the fees taxed them, and the public ledger made the outcome un-editable. Every stage exists to make it harder for the project to lie to me.

The design document for the trader ends with an honesty clause, and it belongs at the end of this post too: no configuration of this system is guaranteed to print money. The market’s aggregate calibration beats the model’s. Profit, if any, comes from rare large disagreements, sized fractionally, with costs priced in.

The forward ledger is the arbiter. It’s public.

Interactive Play with the protocol in your browser Wake a simulated band up, drag its heart rate, tilt it, and watch the real Bluetooth bytes change. →

I own a WHOOP band. It reads my heart rate about a hundred times a second, tracks how I sleep, and decides every morning whether I’m “recovered.” All of that lives in WHOOP’s app and WHOOP’s cloud, behind a subscription. The data is about my own body and I can barely touch it.

Someone had already fixed this for the older band. John Middleton built my-whoop, an open-source, local-first client that reads a WHOOP 4.0 over Bluetooth and keeps everything on your own hardware: the app, the decoding, the storage, all of it.¹ I have a 5.0. When I pointed his client at it, every channel went dark. Getting it talking again, and getting the biometric stream out, is the story. The 4.0 groundwork is John’s. The 5.0 work below is mine, built on top of his.

This is the technical writeup. If you’d rather poke at the protocol than read about it, I built an interactive playground where you can decode and build real 5.0 frames in the browser, take apart a biometric packet, and watch the checksums update as you type. The full spec lives there too.

A quick Bluetooth primer

Skip this if you’ve written BLE code before. If you haven’t, four words show up constantly below and they all map onto things you already know from the web.

A Bluetooth Low Energy device acts like a tiny server. It has no URLs. What it has instead are characteristics, which are closer to individual fields you can hit. Some you read. Some you write to. A few you can subscribe to, and those are called notify characteristics. Subscribe to one and the device pushes you a fresh value every time it has a new one, no polling involved, which is how a band feeds you a heart rate twice a second without you asking each time. Characteristics that belong together get bundled into a service with its own long UUID. The spec has a name for this whole scheme, GATT, and that’s genuinely the last time you need to think about that acronym.

The word that actually matters here is bond. Before a phone can touch most of a band’s characteristics, the two have to pair and then bond, which is roughly Bluetooth’s version of a TLS handshake with a “remember this device next time” step attached. And pairing has two strengths, which turns out to be the whole story of this post. The weak one is called “just-works”: it brings up an encrypted link without either side proving who it is, the way HTTPS behaves if you switch certificate checking off. Encrypted, but you can’t be sure who’s on the other end. The strong one is authenticated, and it also defends against someone wedged in the middle pretending to be one of the two devices. Every characteristic is tagged with how strong a bond you need before it will answer you, and that tag is the difference between the 4.0 and the 5.0.

The 4.0 was a pushover

WHOOP 4.0 exposes a custom service. You connect, you do one “just-works” write to its command characteristic, and iOS quietly brings up an encrypted link. After that the band streams: live heart rate, R-R intervals (the gaps between consecutive beats, which heart-rate variability is computed from), events, and a fourteen-day backlog of stored biometrics that the recovery and strain and sleep numbers are derived from. No passkey, no pairing dance. The whole “bonding trick” is a single write.

John’s client does all of that already: live heart rate on screen, history backfilling, the whole pipeline from band to local store. Then I pointed it at a 5.0 and every channel went dark.

The 5.0 wall

The 5.0’s custom service looks familiar at first. Same shape as the 4.0: one characteristic you write commands to, several you subscribe to for pushed data, all under a renamed UUID.

fd4b0001-cce1-4033-93ce-002d5875f58a   (custom service)
  fd4b0002   write                → command channel
  fd4b0003   notify               → command responses
  fd4b0004   notify               → events
  fd4b0005   notify               → data / fragmented
  fd4b0007   notify               → new in 5.0

The familiarity ends the moment you touch it. Every attempt to subscribe or write comes straight back as a refusal from the Bluetooth stack itself, before the band’s own software ever sees the request:

subscribe fd4b0003     → Code 15  Encryption is insufficient
subscribe fd4b0004/5/7 → Code 5   Authentication is insufficient
write     fd4b0002     → GATT     Insufficient Authentication

The exact wording matters. “Encryption is insufficient” would mean an ordinary encrypted link is enough. “Authentication is insufficient” is stricter: it wants the authenticated pairing from the primer, the kind that’s protected against a man-in-the-middle, not just-works. The 4.0 handed over biometrics on a just-works link. The 5.0 demands the strong handshake before it will so much as acknowledge a subscription.

I spent a while trying to make a Mac complete that handshake, because a Mac is where my tooling lived. Dead end, and worth saying plainly so nobody else burns the same day on it.² Apple’s Bluetooth API on macOS gives you no way to initiate pairing directly. It will only pair as a side effect of reading an encrypted value, and the 5.0’s custom service has nothing readable to trigger that: the command characteristic is write-only, the rest are push-only, and the plain readable values aren’t encrypted. I even unpaired the band from the phone and tried six times from scratch to rule out the obvious “some other device is holding the only allowed bond” theory. Same refusal every time, and not once did the OS even show a pairing prompt. The band simply won’t do a standard Bluetooth pairing with an arbitrary computer. Its custom service authenticates through WHOOP’s own app and account, not through anything a generic client can drive.

What you get for free

Before going further it’s worth knowing what the 5.0 hands out with no bond at all. Bluetooth defines a handful of standard services that almost every device implements the same way, so any app can read them with no special knowledge and, here, no pairing:

• Heart Rate (service 0x180D, characteristic 0x2A37). A standardized format: a flags byte, then the heart rate, then R-R intervals when the flags say they’re present. I was decoding live heart rate off this within minutes, using the same standard-profile parser John’s client already had for the 4.0.
• Battery (0x180F / 0x2A19). A percentage.
• Device Information (0x180A). Model MG, hardware WS50_r03, firmware 50.38.1.0.

That is a genuinely useful live feed and it costs nothing. But it’s shallow. No motion data, no raw optical heart-rate signal, and none of the stored biometric history the real metrics are built from. Everything with depth sits behind the authenticated bond.

The phone already holds the key

Here is the thing the Mac was missing. The official app, with my consent, during normal setup, already paired the band to my iPhone. iOS holds that bond at the system level. And an app running on that same phone inherits the encrypted transport.

So I stopped fighting the bond and just rode the one that already existed. An app on the bonded phone subscribed to the custom notify characteristics, and the band accepted every one:

FD4B0003 SUBSCRIBED — band accepted standard pairing
FD4B0004 SUBSCRIBED
FD4B0005 SUBSCRIBED
FD4B0007 SUBSCRIBED

No keys forged, no app auth impersonated. The OS bond established by the official app provided the encrypted link, and my app listened on it. Passive capture of traffic between two of my own bonded devices.

And then almost nothing happened.

Silence

Subscribing opens the pipe. It does not make the band talk. Over the next several minutes exactly one frame arrived, on the events channel, and then nothing. The 5.0 behaves like the 4.0 in this respect: it is mute until something commands it to stream. The bond was never the whole problem. The other half is a command protocol I didn’t have, and the 5.0’s is not the 4.0’s.

I had two ways to learn that protocol. Guess it by poking the command characteristic and watching for reactions, which is slow and risks doing something destructive to a device I like. Or observe the official app speaking it once, cleanly, and read the conversation back.

Reading Bluetooth without a sniffer

The obvious move is a Bluetooth sniffer: some radio dongle yanking packets out of the air, followed by a lot of work to decrypt them. I didn’t do that. The whole trick is choosing where you tap.

Inside the phone, the Bluetooth software and the actual radio chip talk over an internal interface called HCI. Encryption gets applied below that line, on the chip, in the last instant before the bits hit the antenna. So whatever you log at HCI is caught before it was ever encrypted on the way out, or after it was already decrypted on the way in. Plaintext in both directions, no keys required.

iOS will just hand you that log. Apple publishes a configuration profile for debugging Bluetooth; you install it, do the thing you want recorded, and then pull a sysdiagnose, which is the giant diagnostic bundle the OS coughs up on demand. Somewhere inside it is a full capture of every Bluetooth message the phone sent and received. The first time you find it sitting there in the clear, it feels like cheating. It’s much closer to reading your own server’s request log than to wiretapping anybody.³

So I opened the WHOOP app, let it sync the band for a few minutes, and captured the whole exchange. One good capture: 8,031 frames on the custom service. That capture is the Rosetta stone for everything below.

The envelope

A parser written against a capture is only worth trusting if it can turn around and reproduce the capture. So the rule I held myself to from the start: decode every frame, re-encode it from the decoded fields, and require the re-encoded bytes to equal the originals. All 8,031 of them. If one frame failed to round-trip, the format was wrong. That constraint is what turned a pile of guesses into a confirmed spec.

The frame envelope that satisfies it, with multi-byte numbers stored low byte first (little-endian, the same convention x86 and ARM use in memory):

[0xAA][0x01][len u16][field u16][crc16 of bytes 0..6][inner …][crc32 of inner]

A few of those fields took real work.

len counts from byte 4 to four bytes before the end, so the total frame is len + 8. Easy once you stop assuming it counts the whole thing.

The checksums were the interesting part. A CRC is a checksum: a number computed from a run of bytes so the receiver can tell if any of them got corrupted in transit. This frame carries two of them, over two different regions, computed with two different algorithms, and you have to match each one exactly or your frames look broken. The trailing four bytes are a standard zlib CRC-32 (the same one in gzip and PNG) over the inner region, which the 4.0 also used, so I recognized it fast. The header check resisted. It’s two bytes covering the first six bytes of the frame, and none of the common CRC-16 variants matched until I ran the whole catalog of them and landed on the one labeled CRC-16/MODBUS. The parameters that define it, if you want to reproduce it, are polynomial 0x8005 reflected, initial value 0xFFFF, input and output reflected, no final XOR. In Swift, which is the version that ships:

/// CRC-16/MODBUS (poly 0x8005 reflected, init 0xFFFF, refin/refout, xorout 0).
static func crc16Modbus(_ bytes: ArraySlice<UInt8>) -> UInt16 {
    var crc: UInt16 = 0xFFFF
    for b in bytes {
        crc ^= UInt16(b)
        for _ in 0..<8 {
            crc = (crc & 1) != 0 ? (crc >> 1) ^ 0xA001 : (crc >> 1)
        }
    }
    return crc
}

The field word at bytes 4 and 5 is a small control value, not covered by either checksum, usually 00 01 on the wire for commands. I still don’t have a complete story for every value it takes, and I’m honest about that in the code.

The inner layout, and a gift from the 4.0

Unwrap the envelope and the inner bytes are [type][seq][cmd][b3][payload]. The pleasant surprise: the 5.0 reuses the 4.0’s command numbers. type 0x23 means COMMAND. The command bytes I’d already seen on the 4.0 were right there: 0x91 GET_HELLO, 0x8d GET_ADVERTISING_NAME, 0x22 GET_DATA_RANGE, 0x78 SET_CONFIG, 0x16 and 0x17 for the historical send-and-ack loop. Whoever built the 5.0 firmware kept the command vocabulary and rebuilt the frame around it.

The one byte that bites you is b3, the fourth inner byte. It is not constant. It varies per command, and the band is picky: send GET_HELLO with the wrong b3 and you get nothing. GET_HELLO, GET_ADVERTISING_NAME, and SET_CONFIG want 0x01. GET_DATA_RANGE and SEND_HISTORICAL want 0x00. Get it wrong and the band just ignores you, which is the worst kind of bug because there’s no error to chase.

Making it stream

The official app’s path from silence to a firehose of biometrics, reconstructed from the capture:

1. GET_HELLO, then GET_ADVERTISING_NAME.
2. Fifteen SET_CONFIG writes, each one a feature flag. This is the step that actually unlocks the data. The payload is a feature name padded to 32 bytes, a one-byte value, then padding. The names read like exactly what they are: enable_r22_packets, enable_r22_v2/v3/v5/v6/v8_packets, make_hrfm_visible, hr_ch_switching, enable_passive_strap_fit_gen5, enable_sig11_during_sleep, and a handful more.
3. GET_DATA_RANGE, then a SEND_HISTORICAL and a continuing ack loop.

Flip those flags and the band opens up the r22 stream: inner type 0x2f, arriving on the data characteristic at a serious clip. About 6,300 frames a minute once it’s going. That is the high-rate biometric channel the whole exercise was after.

Getting from “it works in the capture” to “it works in my app” cost a few debugging cycles that are worth keeping, because every one of them was a silent failure with no error attached.

The band buzzed every time I connected. I had a command in my enable sequence I’d labeled SET_CLOCK, opcode 0x42, because that’s roughly what it does on the 4.0. On the 5.0, 0x42 is SET_ALARM_TIME, and writing it set an alarm that buzzed the band on my wrist on every single connect. Deleting one command made the buzzing stop. Naming things matters even when the things are bytes.

Write-without-response is a no-op. I started with write-without-response for the command writes because it’s cheaper. The band silently ignores them. It only acts on write-with-response. There is no error. The writes just evaporate. Switching to write-with-response is what made the frames finally come fast.

The stream stalls after one chunk unless you ack it. This was the good one. The r22 data starts, delivers one chunk, and stops. The trick is in the metadata frames the band interleaves with the data: every status frame of a particular subtype carries an 8-byte progress cursor buried at offset 13. You have to echo that cursor straight back as a 0x17 command, verbatim, and only then does the band send the next chunk. I confirmed it the satisfying way: in the capture, all 124 acks the app sent were byte-identical to the cursor in the status frame right before each one. Echo the cursor, the offload flows. Don’t, and it dies after one chunk.

// On each status frame carrying a cursor, echo it back as a 0x17 ack
// or the historical offload stalls after the first chunk.
let cursor = Array(frame.inner[13..<21])
sendGen5(cmd: 0x17, b3: 0x01, payload: cursor)

r22 only flows on-wrist. I lost an hour to this one. With everything correct, on-wrist gating means the band won’t emit r22 at all unless it’s actually being worn. Off-wrist you get heartbeat and console frames and nothing else. The fix was to put it on and stop overthinking the code.

Reading the sensor bytes

The r22 frames are mostly a 112-byte variant. The trick to reading an unknown binary payload is to find the bytes that move the way a real quantity should, so you watch them over time and against the physical world. The fields that gave themselves up, counting bytes into the payload:

• Bytes 7 through 10 are a timestamp, the band’s own clock, ticking once per second.
• Byte 14 is heart rate in beats per minute. Byte 29 is a second heart rate, which fits one of the feature flags being named hr_ch_switching. The two stay within a few bpm of each other, sit in a believable physiological range, and drift smoothly across forty minutes of capture, matching the standard heart-rate profile from earlier.
• Bytes 37, 41, and 45 are three ordinary 32-bit floating-point numbers: the accelerometer’s x, y, z, in multiples of gravity. The giveaway that it really is an accelerometer is that at rest the three combined have a length of about one (that’s gravity, one g, pulling straight down), and the direction swings around as you tilt the band. Three unrelated floats would not do that.

I’ll admit to one wrong turn, because it’s a good lesson. I first read a block starting at byte 33 as an orientation quaternion, the four-number form 3D software uses to store which way something is facing. Four floats there had a combined length very close to 1, which is exactly what a valid orientation quaternion looks like, so it seemed like a lock. It was a coincidence. One of those four bytes was a separate value that happened to sit near zero, which dragged the combined length close to 1 for the wrong reason. The real signal was the accelerometer a few bytes further on. A length near 1 was suggestive, not proof. Watching the values respond correctly when I physically rotated the band is what counted as proof.

Where it stands

The 5.0 now connects, bonds through the phone’s existing OS bond, replays the enable handshake, and streams the r22 biometric channel at thousands of frames a minute, with the ack loop keeping the offload alive. Live heart rate, R-R, and battery flow into the same store and the same views John’s client already had for the 4.0, so the 5.0 lights up the existing app instead of needing a new one. The codec round-trips all 8,031 captured frames byte for byte and is unit-tested against them.

I’m equally clear about what isn’t done. Two layers of sensor data are still raw. Fully calibrated motion (knowing which axis is which and in exactly what units) and the raw optical heart-rate waveform (the green-light signal a wrist sensor actually reads, known as PPG) both need labeled captures to finish: recordings where I do something known on cue, like hold still, then move, then cover and uncover the sensor, so the bytes can be lined up against ground truth. That’s the same labeled-capture method earlier work used on the 4.0’s sensors, and it’s the next layer here. And recovery, strain, and sleep stay scores WHOOP computes. I’m reading the inputs to those models, not re-deriving the models themselves. The honest summary: the connection and the protocol are solved and shipped, and the fine sensor calibration is in progress.

The whole point was never the 5.0 specifically. It was that the data my own body produces should be readable by software I run, on hardware I own, without asking anyone’s cloud for permission. Getting there meant defeating an authenticated bond and reversing a frame format just to read a pulse off my own wrist, which is satisfying and a little absurd in equal measure. Both bands now do it.

If you want to actually talk to a 5.0, the whole protocol is written up as an interactive spec and playground: the GATT map, the command set, the enable sequence and r22 field layout, plus live tools to decode and build frames yourself. It runs entirely in your browser.

This WHOOP work is independent and unofficial, not affiliated with, endorsed by, or sponsored by WHOOP, Inc. “WHOOP” is a trademark of its owner, used here only to name the hardware this software interoperates with. It is reverse-engineering for interoperability with a device I own, reading my own data, a protected interest under 17 U.S.C. §1201(f). No proprietary software, firmware, or assets are reproduced, and no access control, DRM, or paywall is circumvented. It is not a medical device, and heart rate, HRV, recovery, and the rest are approximations, not medical advice.

By people I mean records in a system of record — names, contacts, home addresses, current assignments, and other personal details that exist in exactly one place and actually matter. This is the most sensitive data we hold.¹ Staff can search it by typing a request in plain language, such as “find translators in France who speak Spanish,” and getting an answer back.

The model handles the request itself without much trouble. This post is about what happens between the request and the answer.

The setup

First, some background on what the assistant is.

It’s an internal chat tool. A staff member opens it, types a request in plain language, and gets an answer. Under the hood it’s an LLM with a set of tools, which are small functions it’s allowed to call. The model has no direct connection to a database. When it needs data, it calls a tool, and the tool is the only code that touches a real record.

Finding people is one of those tools. When someone types “find translators in France who speak Spanish,” the model reads the request, works out the search criteria, and calls the person-search tool with them. The tool runs the query and returns the matches, and the model presents them.

So the model turns language into criteria, and the tool turns criteria into people. The rest of this post is about the tool: the interface it exposes and how it runs a query.

The model doesn’t get a query language

The obvious way to build this is to give the model a flexible search tool and let it improvise — hand it something query-shaped and let it filter however it likes.

For data like this, that’s a bad idea. The records are read-only to the assistant by construction; it can’t write to them, and the whole feature is gated behind a permission claim.² But read-only access still leaves room to read more than you should. If the model improvises its own queries, it can request data in shapes nobody reviewed beforehand.

So instead of a query language, the model gets a fixed vocabulary. Every criterion it can express is a small declared object with a field, an operator, and a value:

{ "field": "departments", "operator": "current",
  "value": { "departmentId": "…", "isManager": true } }

The model can’t invent a field or an operator. Whatever it sends is validated against a registry of things we marked as searchable, and that validation runs before any record is read. The model still works out which criteria a request needs, but it doesn’t control the shape of the search.

Not everyone sees the same person

There’s a second reason the model doesn’t get a query language, and it matters more than the first.

Not everyone who uses the assistant sees the same data. Permissions here aren’t a single yes-or-no on whether you can search people; they’re more granular. Two people can run the same search and get back different fields on the same person, because each record is authorized field by field against the claims of whoever is asking. Which details you can see depends on who you are.

A free-form query language has no good way to handle that. It lets any caller name any field, then relies on the backend to drop whatever they weren’t cleared for on every query. The model ends up reasoning in a vocabulary that may not be valid for the person it’s working for.

A declared registry handles it in one place. The fields are finite and known, so “what can this caller search?” has a definite answer. You give each user only the fields their claims allow, and the model can’t form a criterion for a field it was never given. Fields a user isn’t cleared for are never offered to the model, so they don’t have to be filtered out of the results afterward.

One definition, five jobs

The old version of this tool had two parallel systems bolted together. There were about sixteen typed parameters for the fast path, plus a stringly-typed JSON blob for everything else, with the filter logic reflected out of attributes at runtime. Adding one searchable field meant editing five files and making sure they stayed consistent. The two halves didn’t even agree on what “searchable” meant.

The rewrite replaces that with a single concept. A search field is defined once, and that one definition does five separate jobs.

SearchField.ObjectCollection<DepartmentAssignment>("departments")
    .Operators(Current, Past, Future, Ever, Never)
    .TemporalRange(d => d.StartDate, d => d.EndDate)
    .Member("departmentId", …)
    .Member("isManager", …)
    .Phase1("departmentIds")              // how it narrows the server query
    .Selects("departments { … }");        // what it fetches back

That one block produces all five things: the description the model reads, the rules its input is validated against, how the criterion gets pushed into the upstream search, what data we fetch back, and how a match is decided. Adding a field means writing one of these blocks, and all five jobs come from it.

The builder produces one object behind a small interface. The interface is those five jobs:

public interface ISearchField
{
    string Name { get; }

    // 1 — what the model is told this field is
    void DescribeForLlm(StringBuilder text);

    // 2 — is a given { operator, value } even legal here?
    //     null means fine; otherwise it's the error handed back to the model
    string? Validate(SearchOperator op, JsonElement value);

    // 3 — push this criterion into the Phase-1 server query, if it can be
    bool TryContributeToPhase1(SearchOperator op, JsonElement value, Phase1Query query);

    // 4 — what to pull back from the full record in Phase 2
    string? GraphQlSelection { get; }

    // 5 — the final, authoritative yes/no for one person
    bool Evaluate(PersonRecord person, SearchOperator op, JsonElement value);
}

Two implementations cover every field we have. A scalar field is a single value on the record, such as a name, a date, or a status. An object-collection field is a list of sub-records, like assignments or languages, each with its own shape. The registry is a dictionary of these, keyed by name. Generating the prompt text, validating input, building the query, choosing what to fetch, and deciding the match are all the same loop over the same objects.

This is useful for sensitive data specifically. Because what’s searchable and what’s fetchable come from the same definition, you can’t accidentally fetch a field you didn’t mean to expose. A mistake in a field definition is contained to that one definition.

Two phases, and a hard limit

The search runs in two phases, because the shape of the data doesn’t allow anything simpler.

There are around 8–10 million person records, and each one has hundreds of fields. You can’t query that in a single shot. The search index, which is the thing that can scan all of those records quickly, only covers some of the fields — the common ones that are worth indexing. The rest of the fields live in the full record, which a fast query can’t see.

The two phases split along that line.

Phase 1 is a query against the upstream service. It narrows on the indexed fields — location, department, team — on the server, across all ten million records at once. Its job is to reduce ten million records to a small candidate set. That work has to happen on the upstream service; you don’t want to pull a large set of sensitive personal records into your own process just to sift through them.

Phase 2 takes the narrowed set, fetches the full records including the un-indexed fields, and evaluates the remaining criteria in memory. Those criteria are the ones the index can’t express, like “currently in this department,” which depends on a start date and an end date.

You can’t merge the two phases. Indexing hundreds of fields across ten million records and keeping it fast isn’t feasible, and neither is loading ten million full records into a process to filter them there. Each phase does the part it can.

There’s one rule between the phases that matters more than speed: a Phase-1 narrowing has to be sound. It’s allowed to return too many records, but it can’t drop a real match. If a criterion can’t be pushed down to Phase 1 without risking a false exclusion, we don’t push it, and Phase 2 evaluates it instead. We would rather return a slow result than a wrong one.

This is why TryContributeToPhase1 returns a bool. The return value doesn’t mean “did this field contribute something.” It means “did it fully express this criterion on the server.” The tool tracks that across every criterion:

var needsPhase2 = false;
foreach (var criterion in criteria)
{
    bool fullyPushed = criterion.Field.TryContributeToPhase1(
        criterion.Operator, criterion.Value, phase1Query);
    needsPhase2 |= !fullyPushed;
}

If every criterion pushes cleanly into the indexed query, needsPhase2 stays false and Phase 2 is skipped. The Phase-1 result is the answer, and nothing gets enriched. If one criterion can’t be fully expressed on the server — a temporal check, an un-indexed field, a compound object match — Phase 2 runs, but only as a verification pass over a candidate set that’s already small. So the expensive path only runs when the criteria actually need it.

There’s also a ceiling. If Phase 1 returns more than 2,000 candidates, the tool doesn’t fetch them; it asks for a narrower search instead.³ If a question is vague enough to match ten thousand people, the right response is to ask for more detail, not to load ten thousand full records into memory.

“Currently”

Temporal scope is a good example of how an ordinary word ends up with a precise meaning here.

“Who’s in the translation department” and “who used to be in it” are different questions, and the difference is two dates on an assignment. So temporal scope is an operator. Every object field with a start and end date gets the same five operators — current, past, future, ever, never — and one function handles all of them:

bool InScope(Assignment a, SearchOperator op, DateOnly today) => op switch
{
    Current => (a.Start is null || a.Start <= today)
            && (a.End   is null || a.End   >= today),
    Past    => a.End   is { } end   && end   <  today,
    Future  => a.Start is { } start && start >  today,
    Ever    => true,
    _       => false,   // Never: every item is in scope, negated after the match
};

The model doesn’t work with dates at all. It picks the word current, and the function defines what current means.

The other half of a match is the value. For an object field, the value isn’t a single scalar; it’s a partial object. Matching works by subset containment: the criterion holds if every member it names matches the item, and members it doesn’t name are ignored.

bool Contains(Assignment item, JsonElement value)
{
    foreach (var member in value.EnumerateObject())
        if (!field.Members[member.Name].Matches(item, member.Value))
            return false;   // a named member disagreed
    return true;            // everything named agreed
}

This is what lets one field cover a range of questions. { departmentId: X } means “in department X, in any role.” Adding isManager: true narrows it to “managing department X.” Choosing the operator current narrows it further, to “managing department X right now.” It’s the same field and the same two functions in each case; the model just names more members or picks a different operator.

Evaluating the field end to end works as you’d expect: take the person’s assignments, keep the ones that are InScope for the operator, and check whether any of them Contains the value. Never runs the same check and negates the result.

Read-only by construction

The safety properties here come from the structure of the tool, not from runtime checks added at the end.

The tool has no write path, so there’s no code path that could change a record. The feature is gated behind a claim, so it isn’t available to people who shouldn’t have it. The model can only name fields from a fixed registry, only use the operators those fields declared, and only receive the data those definitions specify. The candidate pool is capped. Every criterion is validated before any record is read.

Taken together, this means the model only ever receives fields it named explicitly, and it can only name fields from a vocabulary we defined.

Why build it this way

Giving the model a plain search box would have been faster to build, and for most features that tradeoff is fine.

But the data being searched is a record of real people, and I didn’t want “the AI improvised a query” to be a possible explanation for an incident involving that data. The declarative layer isn’t there to be elegant, although it is convenient that adding a field now takes one block instead of edits across five files. It’s there so that the only way to use the tool is also a way we reviewed in advance.

The model is good at turning language into criteria, and that’s the job it has here. What data a query is allowed to touch is decided by the tool and the field definitions, not improvised by the model. Keeping those two responsibilities separate is most of what the design does.

1. The baseline

• Stock net/http, tuned: around 9,000 req/s.
• Keep-alives off: under 3,000.
• The cost is the per-request correctness work. Good for production, in the way for a load generator.

2. The connection

type UnsafeConnection struct {
    conn      net.Conn
    buffer    []byte
    bufferPtr unsafe.Pointer
    isReady   int64
}

• 512 workers share 1,024 persistent TCP connections.
• Nothing reconnects mid-run, so setup time never lands in the numbers.
• Buffers are preallocated and reused, so the GC has almost nothing to do.

3. Zero-copy reads

func safeUnsafeByteSlice(ptr unsafe.Pointer, length int) []byte {
    if ptr == nil || length <= 0 {
        return make([]byte, 0)
    }
    return *(*[]byte)(unsafe.Pointer(&reflect.SliceHeader{
        Data: uintptr(ptr),
        Len:  length,
        Cap:  length,
    }))
}

• Builds a slice straight over raw memory: no copy, no allocation.
• reflect.SliceHeader plus unsafe.Pointer bypasses Go’s memory model. Fast, and actually dangerous.

4. Containing the blast radius

func (worker *UnsafeWorker) safeWorkerLoop(client *UnsafeBenchmarkClient) {
    defer func() {
        if r := recover(); r != nil {
            // Log and keep going
        }
    }()
    // Write request, read response, track success/errors
}

• Every worker’s hot loop runs under recover().
• One bad worker logs and dies. The other 511 keep going.
• Unsafe in the small, stable in the large.

5. Measuring honestly

func RunCrashProofUnsafeBenchmark() {
    for i := 0; i < NUM_BENCHMARKS; i++ {
        // Launch all workers with sync.WaitGroup
        // Sleep for the benchmark duration
        // Collect all request counts
        // Calculate RPS, mean, median, stddev, etc.
    }
}

• 15 full cycles, reporting mean, median, and standard deviation.
• The number that matters is the coefficient of variation (stddev ÷ mean): under 5% is excellent, under 10% good, under 20% moderate, above that poor.

Run 1:   248,210 req/s
Run 2:   249,379 req/s
Run 3:   247,844 req/s
...
Mean:                 248,477 req/s
Median:               248,210 req/s
Std deviation:            637 req/s
Coefficient of var.:     0.26%

• 0.26% CV means the speed is repeatable, not a lucky spike.

Notes

• Don’t ship this. unsafe, a hand-rolled pool, and slices over raw pointers are a recipe for memory corruption in production.
• It’s fine for load generation. You control the tool, and the safety you give up was only ever protecting you.
• Takeaway: Go has far more headroom than net/http gives you. Keep the danger in one small, deliberate place and put a recover() around it.

I recently spent ten days in Orlando visiting Disney World and Universal Orlando. I liked all the parks — they were fun and genuinely enjoyable.

We did every park except one (not counting water parks):

• Disney: Hollywood Studios, Epcot, Animal Kingdom, Magic Kingdom
• Universal: Islands of Adventure, Universal Studios Florida (didn’t make it)

We actually had to end the trip two days early because of a death in the family back home, which is why Universal Studios Florida is the one we missed.

Differences in the parks

On the surface they seem like the same thing — big amusement parks in Florida. But I noticed a lot of differences almost immediately.

One of them was the trash cans.

Disney felt more polished across the board. The staff all seemed trained the same way, the trash cans all matched, and the employee uniforms matched wherever they were stationed. The same went for the general organization of each park and for accessibility — wheelchairs and that kind of thing.

Universal had most of what Disney had, but it just wasn’t as “polished.” There were many different types of trash cans, and some ride themes made no sense at all. The staff weren’t trained as consistently either — and don’t get me wrong, they were good employees, they just didn’t extend their service the way Disney’s did. Uniforms were another tell: at Disney, the employees by the Star Wars rides dressed like Star Wars characters. At Universal, the uniforms only matched the theme about half the time.

Trash cans

Okay — onto what this article is actually about.

Disney

Disney had exactly one type of trash can across the entire park — the one in the photo above. Different paint and theming for different areas, sure, but underneath it was the same can every single time. Occasionally it was paired with a recycling can — still the exact same style, just with a round hole for cans and bottles instead of a swinging flap.

Personally, I loved that design. It’s simple and clean, and everybody instantly knows it’s a trash can.

Universal

Universal had at least four different trash can types: big concrete ones, round metal ones, square metal ones, and some that looked a lot like Disney’s. Most of them were paired with recycling cans too. And those were just the variations I could find afterward — I’m pretty sure there were ten more out in the park.

Why does it even matter?

I found myself struggling to answer that one.

The biggest problem with Universal’s approach is probably guests not being sure whether something is a trash can or a potted plant. But does that really matter? Not really — there are trash cans everywhere, in every park, Disney or Universal.

So in the end, I don’t think it actually matters. But Disney clearly has the edge on feeling finished — and not just with the trash cans. With everything.

GETTR launched as the big new conservative social network — Trump world’s answer to Twitter. So, naturally, the first thing I wanted to know was how it was built.

Long story short: it took me 34 minutes to reverse-engineer GETTR’s internal API, and then to abuse it badly enough to get rate-limited.

It wasn’t hard. What actually surprised me was how little stood in the way. There was no real API rate limit at all. To prove that to myself, I had a script create around 1,000 posts in a minute and a half — no throttling, no checks, nothing anywhere telling me to slow down.

And here’s the part I still think is funny: the thing that finally stopped me wasn’t GETTR’s API. It was Cloudflare. The rate limit that eventually kicked in was Cloudflare’s generic protection sitting in front of the site — not anything GETTR had built themselves.

By the end I had an account with roughly a thousand posts on it. Scrolling from the top of them to the bottom took 22 seconds:

For a platform that launched to that much attention, that’s a lot of front door left unlocked.