← Writing

The 2017 book I still keep

I wrote a blockchain book in 2017. The chapters on markets dated fast; the custody questions are the ones I still ask before I trust a stack.

In 2017 I published Blockchain: Ultimate Guide to Understanding Blockchain, Bitcoin, Cryptocurrencies, Smart Contracts and the Future of Money. I went into it a skeptic, tested what I could, and came out a measured proponent. A copy still sits on my desk, and not for the chapters on wallets and markets. I keep it because it put custody in plain language.

Why it stayed on the desk

I wrote the book during a stretch of client meetings where every slide deck had a chain diagram and almost none had a backup plan. Writing it was how I got the vocabulary for those meetings. The chapters on wallets and markets dated quickly. The framing around custody did not.

Custody, in that context, meant knowing who held the authoritative record and whether you could recover it when the hosted service changed terms or shut down. I still use that definition when a new stack arrives with a smoother interface. Custody is the ability to name the machine you can touch and the restore path you can run before you depend on the record. If those two answers require a vendor ticket, you are borrowing the record.

I had learned that lesson years earlier, at midnight on a corrupted MySQL database, with no documentation of who had admin rights on the box. The book was my chance to say it in a short way before the next deck arrived with a new noun for the hole.

The corruption itself was ordinary database work. A table that had taken writes all week stopped opening, and the error log pointed at InnoDB while the storefront returned empty carts. The client wanted Friday’s orders on the phone. I wanted the binary logs and a user list that matched the machine in front of me.

I could open the data directory and see ibdata1 next to the .frm files. I still could not say who else held SUPER on that instance. Two contractors had been given root for a migration the month before, and one laptop still had the password in a text file. Wednesday’s tape restored a schema that would boot, and Thursday’s orders were not in that dump.

That is the recovery question I still ask before I trust a hosted record. Can I bring the data back without calling a person who may already be gone? If the answer depends on a portal I do not administer, I am holding a login and hoping someone is still paying the invoice.

Writing the book put that question on paper at a moment when every meeting wanted to skip past it. People wanted the diagram on the first slide. I wanted the restore drill written down where I could find it after midnight.

The LAMP box and the same habit today

In the late 1990s I ran PHP and MySQL on hardware I could touch. I could follow a request from the vhost config through the include path to the query log. The stack was messy and legible to anyone willing to spend an afternoon with the files.

If the page came back empty, I could read the path it took on that box. Apache handed the file to PHP, PHP opened a connection, and MySQL wrote a line I could grep without waiting on a vendor status page.

PHP talked to MySQL through the old mysql_* functions for years on sites I administered. Those calls worked on the happy path and mixed the password with the query text in the same include. When I moved a codebase to mysqli, and later to PDO, the change was about visibility of the connection and of a failed query. A DSN lived in one place I could lock down. A broken statement failed in a way I could log. Prepared statements made those failure modes readable on a box I still had to keep up.

When a client asked whether their order history was safe, I could point to the backup tape rotation and the user table permissions. The answer was sometimes uncomfortable, but comfort came from knowing where the bits lived and who could change them.

Take the order history question as a worked example from that desk. The client wanted to know if last month’s invoices would still be there after a disk died, and that is a restore question asked in a sales meeting. I walked the Apache vhost to the PHP include that opened the catalog database, then showed the GRANT rows for the application user. That user could SELECT and INSERT into the order tables. It could not DROP the catalog. The restore drill used last night’s dump and a spare box on the same desk, and we ran it before anyone promised the invoices were safe.

I still apply that walk when someone offers to hold the catalog for me in a region I will never visit. Name the machine you can stand next to, and run the restore on hardware you can touch. If either step requires a dashboard that closes when the contract ends, I treat the catalog as theirs.

The LAMP years taught the habit. When rooms stopped talking about include paths, the book put the same questions in writing, and they stayed put while the slides moved on.

Weights on a disk I run

I run small open models on hardware I own for a related reason. The weights sit on storage I control. The inference runtime is software I can inspect and pin to a version. A cloud API can be faster. It can also change behavior between Tuesday and Wednesday without a changelog I am allowed to read.

The book trained a reflex I still use on a draft I care about. Before I hand data to a system, I want to know where the record lives and whether my inputs become someone else’s training set. Ledger pitches and model pitches use different nouns. The control question is familiar.

A remote endpoint can swap the weights while I am in the middle of a draft. The window looks smoother the next morning, and the privacy page may have changed while I was working. I wrote up how I keep the weights and the runtime pinned in running small open models on hardware you already own.

A cloud model can be the right tool for a throwaway prompt I would paste into a public search box. I use one when the draft can leave the building without costing me a client. Anything I would hate to lose, or would hate to see in someone else’s training set, stays local. The book is why that line is still easy to find.

A hosted agent with a private mode

On 10 August 2026, Meta published The Future is for Everyone. The essay argues that a singular lab holding the capability is the danger. I agree with that claim because I have watched one shop hold both the database and the policy that governed it. Concentration of the runtime is the failure I already knew from hosted catalogs.

The same essay offers a personal agent and a fully private mode for that agent. A private mode on a hosted agent is still a hosted agent running on hardware I do not administer. I can read the privacy page they published that week. I cannot pin the runtime or keep the weights on a disk I name, and I cannot run last Tuesday’s binary when the product moves. That is enough for me to keep the paperback in reach.

The paperback on the desk

The paperback stays on the desk as a custody reminder. When a vendor promises efficiency without naming who holds the record, I still reach for it before I reach for a new acronym.

The questions have not grown more fashionable since those client meetings. Who holds the authoritative copy, and who can change it without telling me. I asked both on the LAMP box after the midnight restore. I ask both of every model pitch that wants a draft I still have to stand behind.

I keep the book for the idea that made custody boring enough to check before the meeting ended. If the restore path is exciting, you are already late.