Adriano Foschi

Permissions are two problems, not one

Sat, 08 Aug 2026 00:00:00 GMT

Open GitHub and the first thing in front of you is a list of repositories: the ones you can see. It looks like the most ordinary screen in the product, and it’s actually the point where the permission system has to do the hardest thing you can ask of it.

Because the question that page answers isn’t “can this user see this repository?”, it’s “which repositories can this user see?”. Put that way it sounds like the same question turned around. For whoever implements it, it isn’t remotely the same: in the first case you have two concrete things in front of you, a user and an object, and you only have to decide yes or no. In the second you’re holding the user alone, and the set of possible answers is everything that exists in the system.

There’s also the fact that the path making a repository visible is almost never written on the repository. You can see it because you’re a member of an organization that grants a base level of access across all its repositories; because you belong to a team the repository was granted to; because you belong to a team that is a child of that team, and access is inherited downwards; or because someone added you as a collaborator on that single repository and nothing else. Visibility is the result of inherited rules applied across several levels, and none of those levels, taken on its own, can tell you what is visible.

This way of deciding access has a name: ReBAC, relationship-based access control. What sets it apart from the more familiar models is where the information lives. Under RBAC a permission is a property of the user: you hold a role, and the role carries capabilities with it. Under ABAC it’s the outcome of comparing attributes — the user’s department, the document’s classification. Under ReBAC it’s neither: it’s a consequence of how entities are connected to each other. Nowhere is it written that you can see that repository. You can see it because a chain of relationships leads you there, and to know that, someone has to walk it.

I’m currently dealing with two systems that approach this problem from opposite directions. Neither of them gives me an answer I’m happy with.

The engine that does everything

The first is a product where granular permissions aren’t an architectural indulgence: they’re a real requirement, and it comes from customers. Saying who is an administrator and who isn’t doesn’t cover it — you have to be able to express who sees what down to the single entity, with delegations, exceptions, and visibility that is inherited along the organizational structure and sometimes has to stop at a given level.

We answered that requirement by building a model of our own. That one is ReBAC in substance too, even though we never called it that: an entity’s visibility depends on how it is connected to the structure, not on a label it carries. And the result is an engine that can express anything. It’s genuinely powerful: whatever access policy gets asked for, the configuration that produces it exists.

Manageability pays the bill. Years of successive rewrites — each of which solved a real problem and left a layer behind it — have spread the logic that decides an access across too many places at once. When a bug shows up, and they do, the hard part isn’t fixing it: it’s working out where that decision was made. Nobody holds the whole system in their head, and it isn’t a matter of attention: there’s no vantage point from which you can look at all of it at once.

The diagnosis I’ve settled on is that we wrote ourselves an authorization language without being a company that makes authorization. Every new requirement was answered by making the engine more expressive, because that’s the natural thing to do when the engine is yours. But expressiveness is exactly what you pay for later in maintenance: the more things a system can say, the less it’s possible to look at it and know what it is saying.

Outsourcing what isn’t the core business

The second system is a new prototype I’m building from scratch. There I wanted to try the opposite route: if writing your own permission engine is how you end up with a language to maintain, then you take authorization from outside, the way you take email delivery or authentication from outside. It isn’t my core business, and there are companies for which it is.

I looked at Permify, Permit.io and OpenFGA. The serious experiments I ran on OpenFGA, because it’s the reference open-source implementation of the model Google described in Zanzibar — the system that decides access inside Google, and the paper this entire category of products grew out of. If the pattern makes sense, that’s where you’ll see it.

What the declarative model gets right

And for a good stretch of the way it makes a great deal of sense. The authorization model is a declarative file: you write the entity types, the relationships between them, and the permissions as expressions over those relationships. The inheritance that in a homegrown engine is code scattered around is a single line there — whoever owns the container has that permission on everything the container holds, written once and true everywhere. That file lives in a repository of its own, with its tests beside it: YAML scenarios saying “this user, this permission, this entity, expected true”, running offline, with no database and no application, in a couple of seconds. I wrote sixteen of them, a hundred and twenty assertions, covering the cases nobody in the older system ever dared verify systematically: isolation between separate units, a user with no role at all, an unknown user. I didn’t even have to host it: there’s a managed service with a free tier, and for a prototype that’s enough.

There’s also a discipline this separation imposes, and I think it’s the right one. Roles stay domain facts in my own database, with their invariants and their events; the external service is a projection, updated by an event handler. Which forces you to decide the order of writes. If the relationship is a domain fact, database first and service second: if the second step fails, the fact exists and the permissions arrive late, and that’s an annoyance. In the reverse order, if the database fails, you’re left with granted permissions that no longer have any fact behind them — and that isn’t an annoyance, it’s a hole.

So far the experiment is a success, and that deserves saying before I get to how it ended.

Then comes the list

Then comes the moment you have to build the page that lists things. It isn’t an edge case: it’s the first screen anyone who logs in sees, exactly as on GitHub. And there you discover that the service you delegated authorization to answers beautifully the question you ask about one object at a time, and very badly the one you have to ask about all of them.

There are two routes, and I tried both. The first is to filter afterwards: you query the database with your normal filters and your normal pagination, take the identifiers of the page you got back, send them to the service in bulk asking which of these the user can see, and throw the rest away. It works, in the sense that the result is correct. Except that the total count you show at the bottom of the list is the one from before the filter, so it’s a lie; and a page of twenty-five items reaches the user holding whatever survived. For someone with access to nearly everything the difference doesn’t show. For a user with access to a small slice — which is the common case, not the exception — two or three of the twenty-five remain, and pagination simply stops working: you’d have to keep asking for pages until you managed to fill one.

Filtering first, and the list that arrives whole

The second route is to filter first: you ask the service for the list of objects the user holds that permission on, and hand it to the database. Here the problem is that the list arrives whole. There’s no real pagination to draw twenty-five from: it gives you all of them, and you have to feed them into a clause enumerating thousands of identifiers, then sort and paginate downstream. At small numbers it’s a solution. At real numbers it’s a query nobody wants in production.

Against this objection there’s an encouraging figure in circulation, a public case study reporting a page that went from ten seconds to four hundred milliseconds with this approach. I read it carefully because I wanted it to be true, and it doesn’t say what it appears to say: the bulk filter accounts for a factor of two, eight seconds to four. The big jump comes from something else — moving the database into the same region as the service. That’s a networking fix, not an answer to the problem.

The materialization deadlock

At this point there’s only one obvious move, and it’s the one everybody makes: if you can’t filter at runtime, you build a local index. A table in your own database saying, for each user, what they can see. From there on the list goes back to being an ordinary query, with its pagination and its count, because the filter has become a JOIN.

The problem is how you fill that table. What you need are the computed permissions — “this user can see this object” — and the external service doesn’t give you those. It has an API for following changes, but it returns relationships, that is, the facts you wrote into it: that you’re a member of that team, that the team has access to that repository. That’s data you already have. The interesting part is what the engine derives by walking the graph, and that part it keeps to itself: it computes it to answer one question, then discards it.

To get it out you have to ask, and asking means one question per object. Thousands of questions per user, to be redone every time anything changes anywhere along the chain. It’s the same wall as before, moved inside the synchronization process.

Where each service stops

Permify has the better API on this front — a reverse lookup starting from the subject’s relationships, with cursor pagination and a streaming variant — and for a moment it looks like the answer. But it returns the objects of one type at a time, and a complete index wants all of them: the organizations, then the repositories of those organizations, then what lives inside those repositories. The cardinality explodes the same way. The mechanism changes, the bottleneck doesn’t.

Permit.io is the only one attacking the problem at the root: partial evaluation of the policy, which instead of a list of identifiers hands you a clause to drop into a WHERE. That’s exactly the right thing. Only, for Postgres it’s in early access, it works for attribute-based policies rather than relationship-based ones — that is, not for the model I have — and it requires writing the rules in a separate language. Mature materialization does exist, but as commercial products in early access, or on stacks that aren’t mine.

Every arrow leaving @user is a different path to the same kind of object. To answer “can they see repo A?” one path reaching the destination is enough. To answer “which repositories can they see?” the walk has to be repeated for every repository that exists — and none of the repositories knows it is reachable.

The limit is structural, not an implementation detail

Lined up together, every attempt fails at the same point, and it’s a point that doesn’t depend on the product I picked. Filtering downstream breaks counts and pagination. Filtering upstream doesn’t compose with SQL. The local index needs computed permissions the engine doesn’t expose. Generating SQL clauses, which would be the right answer, only exists for a policy model different from mine. Changing tools changes the name of the API, not the outcome.

The reason lies in the shape of the problem itself. These engines answer by walking a graph from a point: give me a user and an object, and I’ll find whether a path joins them. It’s a targeted operation and that’s why it’s extremely fast, milliseconds. The inverse question isn’t the same operation reversed: it’s the same operation repeated for every candidate object, because there’s nowhere that records which objects are reachable. Which is, incidentally, exactly the thing that makes ReBAC convenient — visibility isn’t a label on anything, it’s a consequence — seen from the other side.

That’s where, for me, the experiment closes. Inside those systems there’s logic that knows how to answer the right question, and it’s powerful, declarative, tested by me with a hundred and twenty assertions. But it isn’t lendable. There’s no way to tell it “apply yourself to everything and tell me what comes out” in a form I can put in a WHERE. So, to get the list, that logic is something I have to rewrite: in my database, in my language, from scratch.

And if I write the same rule twice in two different places, those two definitions have to stay in agreement forever. The worse part is which of the two actually counts: the copy, the one I rewrote, is what decides what people see on screen. The original only guards the writes. If they drift apart nobody notices, because a wrong list doesn’t raise an error — it just has one row too few, or one too many.

Giving up, and going back to Postgres

In the prototype I removed the external service and put authorization inside Postgres, as native functions. It wasn’t the conclusion I wanted — the stated goal was to stop writing myself a permission engine at home — but between two copies of the same rule and a single copy, the single copy wins.

The functions come in two families. One for point checks, one per write operation that needs authorizing: they take the user and whatever they’re acting on, and answer true or false. The other for filtering: they take the user and return a set of identifiers, the ones they’re allowed to see. Translated into the vocabulary of the earlier example, the list of repositories becomes this:

SELECT r.*
FROM repositories r
WHERE r.id IN (SELECT authorized_repositories(:user_id))
  AND r.archived = false
ORDER BY r.pushed_at DESC
LIMIT 25 OFFSET 0;

Which is the thing I’d been looking for from the start: a subquery like any other, composing with the filters that were already there, with the sort and with the pagination. The total count is an ordinary COUNT(*) and it tells the truth. Check and filter read the same data in the same transaction, so there’s no window in which permissions lag behind facts — because there’s nothing to synchronize, there’s no second place.

The move cost less than expected, for a reason worth stating: the application had never known about the external service. Use cases called a port with a deliberately generic signature — user, permission, context — and behind that port sat an adapter. Replacing it with one that runs the SQL functions didn’t require touching any application logic.

And what convinces me most is how it grows. If tomorrow I need a permission that doesn’t flow through the structure but is granted directly on a single entity, you add an assignment table, an OR clause in the check function and the same clause in the filtering one. One more level of granularity costs three changes, always the same three, and they’re SQL. Linear growth, rather than an engine that gets a little more expressive every time.

Three open problems, and the last one is serious

That said, I don’t want to make it look like a clean solution, because it has three open problems and I consider the last one serious.

The first is that I don’t know how far it holds. The functions run, and on the prototype they’re instant — but a prototype doesn’t carry a real customer’s data volume, and I haven’t measured anything under load yet. At some point a filter recomputed on every query will stop being free, and I don’t know where that point is. Finding it is the next thing to do: until I have, everything above is a decision made on reasonable grounds, not on measurements.

The second is what I lost by going back inside the database. The declarative model was readable: one file, the types, the relationships, the permissions as expressions over those relationships. And its tests ran in two seconds with nothing running, a hundred and twenty assertions stating in black and white who sees what. Now the access policy is code inside the database, versioned through migrations and verifiable only against a live database. It works better and it’s harder to look at. It’s a trade I made deliberately, but it’s still a trade.

The third is the paradox this whole story runs into. The prototype can afford native functions because its model is simple: a few roles, a few dozen combinations, a two-level hierarchy. If it grew as complex as the other product’s, this decision would have to be re-evaluated from scratch — meaning I’d find myself exactly where I started, with homegrown authorization logic that widens with every requirement. The simple system can do without an external engine, and indeed it just got rid of one. The complex system, the one that would genuinely benefit from an external engine, is precisely the one that gets least out of it: it has the deepest hierarchies, the longest lists and the largest volumes, which are exactly the three things these tools don’t help with. Whoever can afford them doesn’t need them; whoever needs them can’t afford them.

The compromise: making the question smaller

Then there’s a third possibility, one I haven’t taken all the way yet but that I’m coming round to — and that I suspect is what everyone does without writing it down anywhere. It doesn’t consist of answering the hard question better. It consists of never asking it in that form.

Seen from the outside, the screen that lists everything a user can see doesn’t exist, in any product. GitHub shows you an account’s repositories, or an organization’s; search works within a scope. There is no page promising the complete set of what you have access to, sorted by date. If that page doesn’t exist, maybe it’s because nobody ever wanted it enough to pay for it — and I was treating it as a requirement only because it’s easy to state.

Technically this changes one thing, but it changes all of it. If every query carries a mandatory scope — this organization, this owner, this period — the candidate set stops being “everything that exists” and becomes a number I can bound contractually. And if that number is small enough, downstream filtering becomes viable again: I don’t filter a page, I filter the whole set and paginate after. The count is computed over the survivors, so it’s true, and the pages are full. What didn’t work in the earlier section wasn’t filtering afterwards: it was filtering after having already paginated.

What the scope constraint costs

The price is honest and worth stating. It’s a product constraint dressed as a technical decision, and it holds only as long as I control the surface: a generic query API is something I couldn’t afford. I lose exactly the questions that have no scope — global search, exporting everything a user can see, cross-cutting counters of the “you have forty-seven items expiring” sort. The bound on candidates has to be guaranteed rather than hoped for, because the customer with the twenty-thousand-object organization does eventually turn up, and you need a hard limit with defined behaviour for when it’s crossed. And on every request I pay for a bulk check across the whole scope: latency, and on a metered service a line item too.

The fact remains that this isn’t an answer to the question: it’s a negotiated surrender, making the question small enough that the tool I have can handle it. And the longer I look at it, the less it feels like a defeat. “Which repositories can user X see” isn’t a question that arises from a need — it arises from how we designed the screen. The real need is always narrower: which repositories in this organization, which ones touched recently, which ones match what I’m searching for right now. And narrower questions are ones the tools I tried answer extremely well.

I’m not there yet. Today the prototype filters in SQL, and for what it has to do that’s fine. But if I had to bet on where the answer lies, I wouldn’t bet on an engine that learns to answer the big question. I’d bet on no longer needing to ask it.

Same word, two different jobs: sysadmin before and after AWS

Tue, 14 Jul 2026 00:00:00 GMT

During my last years at university, and for a while after graduating, I worked as a systems administrator for a small hosting company, to pay for my studies. The job was simple enough to describe in full: I managed the customer control panel, answered support tickets, and whenever a client needed a new environment I set one up — almost always a LAMP(P) stack, Linux/Apache/MySQL/PHP, sometimes with something on top for managing the database. I configured small Linux boxes, one at a time, following more or less the same pattern every time. None of it was complex. I never really thought of myself as “a systems administrator” for that job — it was closer to running through a checklist than designing anything.

A completely different job

From 2019, the work changed completely. I started building product — an initiative that began inside the company I worked for and would later spin out as an independent startup in 2023 (4HSE) — and for years that work had nothing to do with servers, tickets, or control panels. It was product development: features, application architecture, the kind of problems you solve in code, not in the machine running it. The systems administrator I’d been to pay for my studies felt like it belonged to a different life.

The same word, on AWS

Then, after years of purely product-focused work, I found myself doing — in small doses — what I would have called “sysadmin work” a decade earlier. Only this time the terrain was completely different: EC2, ECS, Docker containers, CloudFront, RDS, S3, Lambda, CloudWatch. Same label as the first job — “I handle the infrastructure” — but almost no real overlap with what I used to do at the hosting company.

Why were these never the same job?

The core of the difference isn’t scale, it’s the nature of the work itself. At the hosting company, “being a systems administrator” meant keeping a machine alive: installing packages one by one, configuring Apache and MySQL by hand on that specific box, and when something broke, opening a ticket and fixing it right there, on that instance. I didn’t declare the database, I installed and maintained it myself. I didn’t design the network, I inherited whatever was already there. On AWS, that same kind of responsibility is almost an entirely different exercise: I don’t install a database, I declare an RDS instance and let it be managed; the application doesn’t run on a machine I maintain package by package, it runs in a Docker container orchestrated by ECS; I don’t inherit the network, I design it — VPCs, security groups, who’s allowed to talk to whom. The job isn’t “keep a machine alive” anymore, it’s “compose managed services that keep themselves alive.” It’s the same word, systems administrator, applied to two jobs that barely touch.

	At the hosting company	On AWS
The database	Installed and maintained by hand, on that box	Declared as an RDS instance, and managed
Where the application runs	A Linux box kept alive package by package	A container orchestrated by ECS
The network	Inherited, whatever was already there	Designed: VPCs, security groups, who may talk to whom
The job, in one line	Keep a machine alive	Compose managed services that keep themselves alive
The skill	Mechanical	Architectural

What changed wasn’t just my own experience — the job itself changed. Platforms like AWS didn’t make the systems administrator’s work easier, they made it a different job. In my case, keeping a machine alive by hand and composing managed services that keep themselves alive have almost nothing in common as skills — one is mechanical, the other architectural. That’s probably why, the second time I found myself doing it, it didn’t feel like going back to the first job — it felt like a new one.

The cost of writing collapsed. The cost of checking didn't

Tue, 05 May 2026 00:00:00 GMT

This is an approach I started building in 2026 and am still in the middle of. It has no results to report yet — no before-and-after numbers, no verdict. I’m writing it down because the reasoning behind it is the part I’d want to read from someone else, and because committing to it in public makes it harder for me to quietly move the goalposts later.

The short version: getting an AI agent to write code well is not mainly a prompting problem. The leverage isn’t in the prompt. It’s in the system that decides what the agent works on, what gate verifies the result, and what state survives between one run and the next. So instead of collecting prompting tricks, I’ve been building the system.

Why checking, not writing, is now the bottleneck

Producing code has become dramatically cheap. Checking it has not.

That sentence is the whole argument, so it’s worth being precise about why the second half is true. A model can hand me a coherent 400-line change in under a minute. Reading that change properly costs me exactly what it cost before — arguably more, because the failure mode has changed. Obviously-wrong code announces itself. Plausible-but-wrong code doesn’t: it compiles, it reads like something a competent person wrote, it passes the tests that exist, and it’s wrong in a way that requires knowing the intent to see. Volume went up, and the per-unit cost of verification went up with it.

So the bottleneck moved. The scarce resource is no longer typing, it’s attention — and attention doesn’t scale by adding agents. If the cost of production drops by an order of magnitude and the cost of verification doesn’t, then verification is where the whole thing either works or quietly fails.

There’s an obvious move here that doesn’t work: have a second agent review the first one’s code. I use maker/checker separation, but on its own, without an objective check underneath it, that arrangement is two optimists agreeing with each other. The model that wrote the code is a lenient judge of it, and a second model with no fixed standard to check against tends to find the work acceptable too. Agreement is not verification.

The practical consequence is that “done” has to be measurable rather than a judgement. Which means as much verification as possible has to stop being an act of reading and become an act of running.

Introducing Obrussa

Obrussa is a public repository of standards, architecture decision records and templates that every project of mine inherits, and it contains no product code — MIT licensed, so the template can be copied into anything, including closed source. The word is Latin, from the Greek obryza: the assaying of gold by fire. Aurum ad obrussam is gold refined to the highest purity, and Seneca uses ad obrussam figuratively for something that has been put to the test and proved genuine. It seemed like the right name for a system whose entire job is telling apart what is correct from what merely looks correct.

In concrete terms: architecture decision records covering the framework itself, a document on how to keep many repositories aligned without duplicating or contradicting each other, and a service template — the skeleton a new repo starts from, carrying a deliberately thin context file, the gate specification, a state file, a contract, and an empty skills folder waiting to be earned.

At the top of it sits the principle everything else is derived from: the leverage is no longer in the prompt, it’s in the system that decides what the agent works on, what gate verifies the result, and what state survives between runs. Everything below is what that turns into when you make it concrete.

Two tiers, split by what happens when a check is wrong

Tests check what you thought to check. That covers the code compiling, the happy path working, the cases someone imagined. What tests systematically miss is a different category:

security that isn’t a functional bug — missing authorisation, an injection point where the happy path passes cleanly, careless secret handling;
contradictions between modules — A assumes X, B assumes not-X, and each passes its own tests;
code that is internally coherent and wrong with respect to the intent.

These don’t announce themselves per change. They accumulate invisibly and surface together, late, which is the most expensive moment available.

My first attempt at the gate sorted the checks into four levels: form, security, coherence, licensing. It looked tidy and it was the wrong cut, because it answered what gets checked and left open the only question that turns out to matter — what must never be left to a judgement. Those are different questions, and only the second one tells you where to spend.

So the gate has two tiers, and an invariant is assigned to one by the consequence of getting it wrong.

Tier one is deterministic and blocking, and it exists only for invariants where a false negative is catastrophic and irreversible. In most systems that list is short, and writing it down explicitly is most of the work: cross-tenant data access, a secret reaching a commit, something private crossing into something public, a licence boundary that may only be crossed one way. For these, a probabilistic guarantee is not a guarantee. They get fitness functions on the import graph, isolation tests, secret and dependency and licence scanning, strict types and lint. Never an LLM alone — a model may review them in addition, never instead.

Tier two is an LLM reading the standards as its rubric, and it covers everything that resists codification: architectural intent, whether a write really goes through a properly scoped use case, naming coherence, replay safety. A different model from the one that wrote the change.

The cut is by consequence, not by subject. The first attempt sorted checks by what they looked at, which left the only question that decides where to spend unanswered.

The rule fits on one line:

Catastrophic and irreversible → deterministic. Everything else → the rubric.

Two things follow from that, and they’re the parts I’d defend hardest.

The first is that the prose is the prompt. The reviewing model reads the standards documents themselves — not a checklist derived from them. Nothing gets translated, so there’s no second artefact to drift out of sync, and the standards earn their token cost twice: once as the rules a person argues with, once as the rubric a model applies. It also disciplines the writing, because a rule too vague to be applied by a model was too vague to be applied by a person and nobody had noticed.

The second is a small operational rule with a nasty failure mode behind it. A change to a standard that touches a deterministic check has to land in the same pull request as the change to its config. Otherwise the code stays green while obeying the rule you just replaced, and prose and enforcement part company silently. The gate guarantees code follows the standard; that rule is what keeps the standard and its enforcement together, and nothing automated catches it.

What the two tiers have in common is the same purpose as before: converting as much as possible into something CI can fail. What CI fails, nobody has to notice.

The number that decides whether this works

The metric I’m tracking is cost per accepted change: what it takes, end to end including my own review time, to get one change actually merged. Not lines produced, not tokens spent, not how impressive the diff looked.

That number is also the falsification condition, which matters to me more than Obrussa does. Below a certain acceptance rate, AI leverage is negative — you’re paying in review attention more than you’re saving in production. If that’s where the number lands, the honest response is to say so rather than to keep adding process. I’d rather have a metric that can tell me I’m wrong than a conviction that can’t.

And there is an irreducible share of human judgement that no gate absorbs. I handle it by risk-tiering rather than by pretending: authentication, payments, personal data and security boundaries get read line by line, by me. Everywhere else, the gate plus spot-checks is the deal. That’s an explicit trade, and writing it down is what makes it a trade instead of a drift.

Three kinds of memory, and one that’s deferred

The other half of Obrussa is what an agent knows when it starts. Three tiers, separated by cost and by when they load:

Always-on context — vision, architecture, domain, threat model, the standards that apply, and the repo’s CLAUDE.md. This describes what the system is and what the rules are. It loads every session, so it’s paid for in tokens every session, so it has to stay thin. It’s also the tier-two rubric, which is the argument for paying for it.
Skills — a procedure for something recurring, loaded on demand, able to carry scripts and reference material. This is where repeatable know-how goes precisely so it doesn’t bloat the always-on context.
Dynamic state — a STATE.md saying where the work currently is, updated as slices land.

The rule that keeps them apart: if it’s always true about the project, it belongs in context; if it’s how you do X when you need X, it belongs in a skill. Putting procedures in the always-on file is the token waste to avoid.

One thing I deliberately left out: a vector store. Product memory (RAG over a corpus) and coding-agent memory are different problems, and for the second one the codebase plus git plus native search already is the semantic memory. Adding retrieval infrastructure here would be solving a problem I don’t have.

Skills are also deliberately deferred. The empty skills/ folder ships in the template with a candidates file next to it, and nothing gets promoted into a skill until at least one manual run of that procedure has proved reliable. A skill written before that is an unverified hypothesis with the authority of documentation — it crystallises a convention nobody has tested. Order matters: foundations, then the gate, then the template, then a first service built in vertical slices under the gate, then skills extracted from whatever actually held.

Many repos, and the context you give up

The layout I use is hub and spoke: one private repo holding system-level documents, standards, versioned contracts and a service catalogue, plus one repo per service. That buys clean licence and visibility boundaries and costs something specific: an agent working in one repo cannot see the others. It will happily make an assumption about a neighbour that used to be true.

The substitute for the unified context you gave up is contracts published as versioned artefacts, with consumer/provider contract tests in the gate. That’s the machine-checkable replacement — it doesn’t inform the agent, it fails when the agent gets it wrong, which is the same outcome one step later. And the tedious job of keeping N repos on the same version of shared conventions is repetitive and machine-checkable, which makes it the honest place for an automated maintenance loop: a bot opening pull requests across repos when the standards change. Loops earn their place there, in maintenance, not in greenfield work where nobody can say what “correct” means yet.

Where Obrussa actually stands

Today it is a boilerplate and a set of decisions, being applied for the first time. The parts I believe most are the asymmetry argument and the insistence that “done” be measurable — those hold regardless of tooling. The part I’m least sure about is proportion: whether a solo developer can carry a deterministic tier plus contract tests plus a review pass without the ceremony eating the gain it was supposed to protect. Splitting the gate by consequence helps here more than it first appears — the expensive tier is the deterministic one, so keeping its list of invariants short is exactly what makes the thing affordable. That’s exactly what cost per accepted change is there to answer, and it’s a number I don’t have yet.

What I’m confident about is the shape of the problem. When producing a change becomes nearly free and verifying it doesn’t, everything that matters moves to the verification side. Prompting better doesn’t touch that. Building a system where correctness is checked by something that never gets tired, and where human attention is spent deliberately on the parts that deserve it, might.

Architecture as a standard, not a suggestion

Tue, 03 Mar 2026 00:00:00 GMT

Since the AI era began, every one of us developers has watched our value as programmers depreciate: writing code was the skill the job rested on, and it has become the part a machine does in seconds. Ask for a feature and you instantly get hundreds of lines — the cost of writing is essentially gone. But that cost doesn’t vanish, it moves to checking, and checking is more expensive than writing: reviewing code you didn’t write is tiring, and reviewing mountains of it much more so. There’s no escape in verifying step by step either, because you don’t know up front where the model is heading — you’re judging a move without knowing the game. That’s where vibe-coding starts: not out of laziness, but because at some point genuinely verifying costs more than accepting and hoping.

Where does AI-assisted coding actually fail?

There is one thing I’ve noticed with some consistency, though: the point where these tools fail isn’t implementation. Ask for an algorithm, a transformation, a complicated query, and it comes out correct — that’s exactly the kind of closed problem they’re strong at. What comes out arbitrary are the architectural boundaries: where to put a file, which layer may know which other, how information should travel between layers, what belongs to the domain and what to infrastructure.

The framework alone doesn’t fix it. A framework gives you bricks and a few conventions, but it isn’t rigid enough: it leaves too many roads open, all equally plausible. And when every road is plausible, the choice becomes arbitrary — not wrong, random. Two similar features end up structured two different ways, and neither violates any rule, because the rule doesn’t exist.

Giving the AI a pattern to treat as scripture

The most effective lever I’ve found is removing that ambiguity up front: hand over a precisely documented design pattern and require it be treated as scripture, not as a suggestion. If the organization of the code is already decided, it isn’t something the model has to invent — and the space in which it can go wrong shrinks to what it’s actually good at.

The catch is that this only works if you know that pattern, and know it well. I should be honest about my starting point: I’ve built a lot of experience on complex, highly scalable systems, but I built it in the field, almost never approaching the material theoretically. I knew how to make things work without always being able to name the principle I was applying — which is probably the norm among experienced developers rather than the exception. To have a model put a principle into practice, though, I need to know it with a precision I never needed before: I have to be able to write it down, justify it, and tell the case where it holds from the case where it doesn’t. That’s the unexpected gain of this period — the machine writes the code, I have to know the theory, and better than before.

The choice: hexagonal clean architecture

The pattern I started studying most seriously is hexagonal clean architecture. Let me say it immediately: for many projects it’s overkill, and I have no intention of arguing otherwise. The ceremony it demands — ports, adapters, a layer that isn’t allowed to talk to another — is hard to justify on a small service that just needs to work.

But it’s effective precisely where it’s needed here, for three reasons. First: it doesn’t leave the model any choice about how to organize the code, because the structure is decided before a line is written. Second: it states explicitly how information travels between layers, which is the other half of what goes arbitrary when a rule is missing. The third matters with no AI involved at all: separating the domain from technical details preserves the application’s ability to evolve, and an application that can replace pieces without rewriting itself is an application that lasts.

As a framework I picked NestJS, which comes with modules and dependency injection out of the box: the layers have something to rest on instead of having to be simulated. Everything that follows is the rigidity I added on top.

Four layers, and the dependency rule

There are four layers and the dependencies all point inward. At the centre, the domain: entities, value objects, events, and zero framework imports — no decorators, no database driver, no notion that HTTP exists. Around it the application, which depends only on the domain, orchestrates the use cases and declares the ports, the interfaces describing what it needs from outside. At the edge, two families of adapters: infrastructure implements those ports against the real world — repositories, HTTP clients, providers — and presentation is the way in: controllers, DTOs, CLI, translating the outside world into use-case calls.

The hard rule is that inner layers never import outer ones. The domain stays testable with no database and no framework, and database, framework and entry channel become replaceable details — that’s the invariant of all clean architecture, not a preference of mine.

There is one part of that rule I care about more than the rest, because it’s the part most often forgotten: infrastructure and presentation do not import each other. They’re siblings at the edge, not one stacked on the other, and whoever composes them is what puts them in touch. A controller that could import a repository directly would have a road around the use case — and that road would get taken, if not by me then by an agent looking for the shortest path from request to database. Forbidding it in both directions is what makes the use case the only way through instead of the recommended way through.

Dependencies point inward, and the two edge layers are siblings: a controller reaching a repository directly would be a road around the use case.

Ports owned by the consumer, and the composition root

The piece that took me longest to genuinely understand isn’t the pyramid of layers, it’s where ports and their adapters live.

A port is always declared where it is consumed, never where it is implemented. The consumer states what it needs — an interface saying “I need to be able to save a subscriber”, written in the application layer of the module that has to save one — rather than the provider announcing what it offers. It looks like a detail about where files go, and it’s actually the direction of the dependency: if the port belonged to whoever implements it, the centre would have to know the edge, and the inversion the whole pattern rests on wouldn’t be there.

Where the adapter lives, on the other hand, depends on which boundary it crosses. In the normal case it sits in the infrastructure of the same module, wired by that module: ordinary clean architecture, entirely internal. But when an adapter would cross a boundary between modules it can’t sit there, because to implement that port it would have to import the other module — and that import is exactly what the boundary forbids. So the port stays with the consumer, and the adapter is provided and wired by the composition root: the application that composes the modules.

This was the thing I understood worst at the beginning, and I mistook it for a loophole — a place where the rules count for less. It’s the opposite. The composition root is the only point in the system with the right to know every piece, and it exists precisely so that everything else can avoid knowing each other: a module declares what it needs without knowing who will give it, and therefore stays compilable, testable and shippable on its own. Different deployment shapes become different roots composing the same modules with different adapters wired in, without a line inside the modules changing.

The port stays with the consumer that needs it. Only the root is allowed to know both modules, which is what lets each of them compile and ship on its own.

Who enforces the dependency rule?

So far this is a drawing, and a drawing doesn’t hold on its own. The difference between a real architecture and a diagram in a README is whether something fails when the rule is broken.

The import graph is checked on every change by a dedicated tool — dependency-cruiser, in my case — which is the single source of truth about boundaries and fails the build in CI. An inner layer importing an outer one, an inbound adapter importing an outbound one, a cycle between modules: all blocking errors, not observations left to a code review. And the constraint is declared in one place, instead of scattered across conventions each person remembers their own way.

Two reinforcements matter as much as the main rule. The first is strict dependency resolution: a package a module hasn’t declared doesn’t even resolve, so the wrong import dies at build time and never reaches the linter. The second is that every module must be able to compile on its own: it’s the most honest test of independence, because a hidden dependency doesn’t survive compiling in isolation — there’s no way to “nearly” pass it.

This is the part that changes character when the other side is a model rather than a person. You explain a convention to a colleague and count on them remembering it, and if they forget you find out in review. An agent needs something that tells it no mechanically, immediately, every time — and that says it before hundreds of plausible lines have been written in the wrong place. A rule that lives only in a document is, to an agent, a suggestion.

The conventions inside the layers

Boundaries say where a thing may live; they don’t say how it’s written. That part is conventions, and their usefulness isn’t being clever — it’s being already decided.

The first is the role suffix in the filename: *.use-case.ts, *.port.ts, *.adapter.ts, *.repository.ts, *.vo.ts, *.controller.ts, *.dto.ts. The role — and therefore the layer that file belongs in — reads at a glance, and that isn’t only a human benefit: it makes it immediately obvious, to an automated reviewer too, that a file named *.repository.ts sitting in the application layer is in the wrong place.

Then there’s how domain objects are constructed, which is the convention I care about most. A value object is immutable and validates on construction, through a static factory with a private constructor: from outside you cannot call new, and the only available entrance validates and normalizes. The consequence is stronger than a recommendation — invalid state isn’t discouraged, it’s unrepresentable: a malformed email never becomes a value object, so there is no point in the system it could reach. Entities follow the same logic with two distinct factories, one to create a new instance, which emits a domain event, and one to rebuild it from the database, which doesn’t — because re-reading a row isn’t something that just happened.

Above the domain, the use cases: one per operation, one file each, flat, and zero business logic. They orchestrate — call ports, build entities, use value objects — but the business rule lives in the domain, not there. Controllers are the mirror image: validate the DTO, map to a command, call the use case, map the response. No logic, ever.

One practical detail worth stating because it’s specific to this stack: NestJS can’t inject a TypeScript interface, which doesn’t exist at runtime. So every port is an interface plus a Symbol acting as its injection token. It’s the one place where the pattern has to bend to the language, and I’d rather say so than pretend the abstraction is free.

Two-layer validation, and the error model

There are two validations and they don’t duplicate each other, because they answer different questions. At the edge, on the DTO, you validate shape: types, required fields, formats, body size. A malformed input is rejected immediately, before touching any logic, and it’s a security surface too. In the domain you validate business, on construction, so that an invalid domain object doesn’t exist. The reason the domain doesn’t trust the DTO is concrete: not every entry point comes through a DTO. A CLI command, an event handler, a test build domain objects directly — if the business rules lived in the DTO validator, each of those roads would be an open door.

Errors follow the same separation. There are two hierarchies, both framework-independent: one for business rule violations, one for technical faults. Persistence adapters wrap driver errors in the second, so a database error never reaches the user raw. And nothing is caught in the core: domain, use cases and controllers let it propagate. Exactly two points catch — the persistence adapter, translating the technical inward, and the inbound adapter, translating outward. Two points of translation instead of one scattered through every function.

How it renders outward is by naming convention, not a hand-written map: an exception whose name ends in NotFoundException becomes a 404, AlreadyExistsException or ConstraintException a 409, PermissionsException a 403, any other domain violation a 422, and any technical fault a generic 500. The core stays entirely unaware of the protocol — which genuinely matters, because the same set of exceptions has to render on a channel that isn’t HTTP: from the CLI those same exceptions become exit codes and messages on stderr, not a mirror of HTTP statuses.

One detail I learned the hard way and consider non-negotiable: every error carries a stable code, decoupled from the class name. If the code exposed to consumers were the class name, renaming a class — an internal refactor, invisible from outside — would break whoever relies on that code. The class name classifies the status; the code is public contract, and the two need keeping apart.

Persistence: a typed query builder, no ORM

For persistence I moved to a typed query builder — Kysely — and dropped the ORM. The reason isn’t stylistic, and it follows entirely from the pattern described so far.

Aggregates, in this model, are detached: the repository reads rows and translates them with a mapper, and the domain object that comes out isn’t “managed” by anything. Between aggregates there are no relations and no foreign keys — integrity is application-level and cascades are orchestrated by the use cases. Which means every convenience an ORM offers is inapplicable: nothing to track, nothing to lazy-load, nothing to synchronize. And an inapplicable but available convenience isn’t neutral: it’s implicit state sitting there for whoever uses it by mistake, with effects that surface far from where it was used. On a managed object model an ORM is the right call; here it would be an engine left running under the floor.

The migration is the only declaration of the schema

The consequence that convinced me most, though, is about declaring the schema. The migration is the only declaration of the schema: the types describe the shape of the rows — column names, types, what can be omitted on insert — while the structures, meaning primary keys, unique constraints and indexes, live only in the migration that creates them. From which follows something worth stating in full: there is no schema-versus-types drift check, because there is no second declaration to reconcile. An ORM requires that check because it forces you to declare twice — the entity metadata and the migration SQL — so the check solves a problem the tool itself introduced. Here that class of error isn’t caught better: it isn’t representable.

I have to state the reverse too, because it appears to contradict what I just wrote. Columns — name, type, nullability — are described twice, in the migration and in the row type, and nothing verifies it mechanically. That’s a choice, not an oversight: a mismatch between types and schema isn’t a catastrophic or irreversible invariant, so it doesn’t warrant a blocking check, and the burden stays with whoever writes it. In practice the immediate effects police it: column names go straight into the SQL, so a wrong one fails the integration tests against a real Postgres right away; a column declared and absent breaks the query selecting it. What’s genuinely left uncovered is nullability on a path no test exercises — and I’d rather know that and say it than believe I’m covered.

One last detail that strikes me as the most elegant part of all this: each migration is typed against the world it was born in, not the current schema. Otherwise code that is immutable by definition — an applied migration is never touched — would depend on something that evolves, and an old migration would stop compiling at the first schema change.

Why this suits working with an AI

The benefit is narrower than the topic suggests, and I want to calibrate it precisely: an explicit standard plus a check that actually runs does not make generated code correct. It makes it placeable, and it makes boundary errors visible early and mechanically. Those are two different things, and only the second is what architecture buys you.

Placeable means the question “where does this piece go” already has an answer before the model starts. It doesn’t have to invent a structure, and therefore can’t invent a different one next week for a similar feature: the arbitrary part — the thing I said at the start is the real point of failure — has been removed from the problem, not delegated more skilfully. And there’s a side effect I appreciated more than I expected: the architecture doesn’t have to live in the prompt. It lives in the repository, in normative files the model reads, and it doesn’t need repeating every conversation or remembering by me.

Splitting the verification work

Then there’s a division of verification labour that turned out to be the most useful part. Structural violations — a layer importing outward, an inbound adapter touching an outbound one, a module that won’t compile alone — aren’t matters of judgement: a machine catches those, always, and they block. What’s left over are the shades of intent: whether that’s really orchestration or business logic in disguise, whether the port is declared on the right side. Those are judgements, and they can be made by a reviewer — human or model — reading the standard itself as its rubric, not a checklist derived from it. That detail matters: a checklist summarized from a document drifts away from the document; if the reviewer reads the document, there’s nothing that can diverge.

The final accounting is this, and it returns to where I started. The cost had moved to checking, and checking mountains of code I didn’t write is the expensive part. I haven’t eliminated it. I’ve made one entire class of it — boundaries, which is precisely where these tools go wrong — either impossible or immediately obvious, so that the attention I have left can go to what a machine can’t judge.

What it deliberately leaves open

It’s worth saying where this standard is silent, because the silence is designed as much as the rules.

It fixes structure, not style. It says where a piece of code goes and who may know whom; it doesn’t say how you write inside a layer, how to decompose an algorithm, how to name a local variable, which library to pick for a contained job. Inside a use case or inside an adapter there’s all the freedom there ever was. That’s a choice about proportion, and it matches this article’s thesis: rigidity should be spent where these tools fail, on the boundaries, and not spent where they’re already reliable. Constraining implementation too would cost review attention and buy nothing — and a standard that constrains everything is a standard nobody keeps for long.

What actually moved

The value that seemed to be depreciating wasn’t mine: it was one particular form I used to put it in. Writing code was the visible part of the job, but it wasn’t the part the expertise lived in — and now that the visible part costs almost nothing, what’s left making the difference is knowing where the lines go, and knowing it precisely enough to write it as a rule a machine can check.

That’s the paradox of this period, for me: a tool that writes code in my place has made me a more theoretical engineer than I was. I had to properly study what I had only ever practised, because to demand that a model respect a boundary, I have to be able to define it myself first.

An air conditioner on my own network, and nobody else's

Tue, 09 Dec 2025 00:00:00 GMT

The air conditioner at home is controlled by its remote, and by nothing else. It has no network socket, it talks to nothing, and if the remote is in the other room you get up.

The little boxes you can buy to solve this have been around for years: they fire infrared on your behalf and you drive them from an app. The thing is, that app talks to the manufacturer’s server, so the command to switch on an appliance three metres away takes a trip through a data centre. If that service shuts down, or changes its terms, or is simply out, the air conditioner goes back to being a machine with a remote.

I wanted all of it to stay inside the house. The goal was to get the air conditioner into Home Assistant — the home automation system that holds a household’s devices together, running on a machine of mine rather than somebody else’s — so I could switch it on, switch it off and, above all, automate it along with everything else. In 2020 I built the thing myself.

It’s a blinking LED, really

There is nothing mysterious inside an infrared remote. It’s a diode that emits light beyond the range of the eye, switching it on and off very fast in a pattern, and the air conditioner has a receiver that knows how to read that pattern. Point a phone camera at one and you can see it flicker, because plenty of sensors don’t filter it out.

So not much is needed: something that sits on the home network, an infrared LED, and a component to drive it — a microcontroller pin can’t supply the current an LED needs to be seen a few metres away. I used a transistor, with a resistor to limit the current.

Then there’s the part few people think about: a receiver. A transmitter on its own works, but it works blind. It fires the command and doesn’t know whether it arrived; more to the point, it knows nothing about what happens when somebody picks up the real remote and changes the temperature. With a receiver alongside it, the device also listens to the infrared going past, and what happens in the room stops being invisible.

From breadboard to perfboard

The first step was on a breadboard, with jumper wires: the board, the LED, the transistor, the resistor. The simplest test there is — aim the LED at the split unit and see whether it responds.

The first version, on a breadboard. Enough to find out whether the air conditioner would answer at all.

Then the same thing soldered onto a scrap of perfboard the size of a stamp, transmitter and receiver on the same little board, with the LED left on its long legs so it can be pointed where it’s needed. The board is one of those carrying an ESP8266: the few-euro wifi module that made putting anything at all on a network normal.

Everything wired together before going into the box: the mains module, the infrared board, the sensor on its lead, and the microcontroller.

It isn’t precision work. It’s an afternoon with a soldering iron, and it looks like it.

Power decides the shape of the object

At this point the question stops being electronics and becomes shape: how does this thing sit in a room.

A USB power supply was the short road, and it would have produced the object you see everywhere — a little box with a cable running down to a socket. Instead I put a module inside the box that takes mains voltage and gives back the 5 volts the board needs: two fingers wide, a few euros.

Inside the box: the board, and next to it the module that brings the mains down to 5 volts.

That choice does mean mains voltage runs inside the enclosure, and the care that calls for is of a different order: insulate properly, leave nothing exposed, close it up. Not a detail to wave through.

The advantage isn’t the price, it’s that the object becomes self-contained: a closed box with two wires going in and nothing around it. From there you can put it anywhere there’s power — which is exactly what made the final arrangement possible.

The sensor the air conditioner doesn’t have

On the same board I added a temperature and humidity sensor, on a lead long enough to place it where it’s useful. It wasn’t in the original plan, but once you have a networked device attached to the air conditioner, not putting a sensor on it is a waste.

The sensor is the white grille on the right, deliberately on a long lead so it wouldn’t have to sit wherever the rest of the electronics ended up.

There’s a practical reason too. The air conditioner measures temperature with its own probe, which sits inside the unit, high up near the ceiling, where the air is warmer than the air people are actually in. That number is fine for the machine’s own thermostat, but if you want to trigger something based on how warm the room is, you need a reading taken somewhere else.

Then the installation got in the way. With the box ending up inside the air conditioner, a sensor in there measures the machine’s air, not the room’s. It sits inside, but as far from the motor as it can be, almost looking out. It’s a compromise, and it may as well be said plainly: it isn’t the same as a sensor standing free in the middle of the room, but it’s a far closer reading of the room than the one the split gives.

Tasmota: replacing the firmware instead of writing one

I didn’t write any firmware for the microcontroller. I put Tasmota on it — free firmware born to free smart plugs from the manufacturer’s cloud. You install it in place of the factory one, and the device starts speaking MQTT on the home network, with a configuration page and nothing else around it.

It goes on over serial, with a USB adapter wired to the board’s pins. First the microcontroller has to be put into programming mode, GPIO0 pulled to ground as the power comes up, and then the memory is written from the command line: erase it, then write the firmware at address zero.

esptool.py --port /dev/ttyUSB0 erase_flash
esptool.py --port /dev/ttyUSB0 write_flash -fm dout 0x0 tasmota-ir.bin

The filename matters: tasmota-ir, not plain Tasmota. A separate build exists because the library that speaks infrared carries an enormous number of protocols — every air conditioner manufacturer has its own — and all of it together doesn’t fit alongside the rest of the features. So the project made a build that keeps almost every IR protocol and gives other things up. With standard Tasmota you can’t drive the air conditioner at all.

Then you tell the firmware which pin does what: one to send, one to receive, one for the sensor.

Finding the right protocol was the long part. The library knows several LG variants, and nobody tells you which one your appliance speaks: you try one, watch whether the split responds, change it. It took me a good many attempts. In the end it was the one Tasmota calls LG2. And this is where the receiver stopped being a luxury: press a button on the real remote, read what Tasmota made of it — protocol, mode, temperature — and hold that up against what you were about to send.

Where it ended up

For a while the box stayed where it’s natural to put it: on the wall under the split, white on white, its cable running down to the socket.

Then I took the last step. There is already power inside the air conditioner, and the module I’d put in the box starts from mains voltage anyway, so it only had to be connected there. The device ended up inside the casing of the indoor unit, powered by the machine it controls, with the LED aimed where it needs to be and the sensor kept as far from the motor as possible. From outside there’s nothing to see: there’s an air conditioner, exactly as before.

It has been working since 2020. In those years the only thing I’ve had to go back to is the configuration on the Home Assistant side, which has changed a great deal in the meantime. The hardware, no — that just sits there.

Five years is a long time for something soldered onto a scrap of perfboard in an afternoon. The reason it has held, I think, is that it depends on nothing: it has no account, it calls no server, and the only thing it has to do is light an LED at the right moment.

Quality was nobody's job, and then it was mine

Tue, 21 Oct 2025 00:00:00 GMT

From 2015 to 2023 I worked as a full-stack developer at a software house: consulting until 2019, on clients in banking, insurance and e-learning; the company’s own product, a B2B SaaS, from 2019 on. For years I told these eight years as consulting-versus-product. But what I actually learned isn’t about the contract label — it’s about me: I’m not someone who sits still on a system that’s already built. I like to learn, to build, to experiment. And it’s that instinct, not the kind of contract, that decided which of those years actually felt right.

What consulting actually is: being the vendor

Consulting has a precise shape: you’re the vendor. You work on a system that isn’t yours, inside decisions made by other people before you arrived. You’re paid to deliver an agreed scope by an agreed date — that’s, literally, the definition of “done.” Almost all of it was work on software that already existed, at banks and insurers with their own architects and their own standards, settled years before I showed up. The work often came through subcontracting — a detail of my situation, not what mattered. You’re not brought in to have opinions; you’re brought in because there’s more work than there are people. Inside that edge the work was real: Scrum, environments you can’t touch directly, deployments with a window and a sign-off, documentation written for an auditor more than for a developer. I got good at it, and it’s a skill I still carry.

Why quality wasn’t a requirement, and nobody said so

What I remember most, though, is how little anything moved. Technology choices were effectively closed — not defended, closed: a thing was done a certain way because it had always been done that way, and proposing otherwise had nowhere to land. Those questions belonged to the client’s own architects, answered years earlier. You could flag a risk and watch it get filed. Not rejected. Filed. I don’t think that was bad luck: when the software is already there and belongs to someone else, resisting change is the default state, and low quality is what years of that default leave behind. And nobody talked about it — not cynicism, closer to a tacit agreement: if something shipped and nothing caught fire, it was fine. Quality wasn’t a requirement traded away against cost. It simply wasn’t a requirement.

The small clients, where I owned every decision

Alongside the large engagements there was a steady stream of smaller projects, for clients who came once. On those I ran everything myself — from the first conversation to delivery, technical choices included, with the responsibility that comes attached. They were solutions built from zero, with no architecture to inherit and no one to ask permission from: an idea could be tried on Tuesday and be in production by Thursday. On paper it was consulting, same as the large accounts; in substance I was building a product for a client, from scratch — and that, not the contract label, is why I learned more there. On the large accounts, instead, the goal was delivering the agreed scope by the date, full stop. I understand the real pressures of a legacy system and a regulated release — but I wouldn’t use them as an excuse for what I saw: in an environment handling other people’s money and data, quality and security should matter more, not less. Instead, shipping without real care wasn’t a problem for whoever was in the room at the time: it would be a problem for whoever came after — often another vendor, not me. That comfort, not the system’s complexity, is the part I don’t buy.

What changed when the product became ours

Moving onto the company’s own product in 2019 changed three things, and none of them was the technology. First: technical decisions became available — not automatically won, but arguable: proposing a better approach turned into a normal part of the job instead of a category error. Second: consequences came back. Code I wrote badly, I met again six months later, and so did everyone around me — quality stops being a line item in someone else’s signed-off estimate and becomes something you personally pay for or benefit from. Third: the time horizon. A project ends. A product continues — refactoring, debt carried on purpose, migrations, maintenance with no final release. You start thinking in years, because the system will still be there in years, and so, probably, will you. And it’s exactly this terrain — where a proposal has somewhere to land, where you get it wrong and learn again, where you build something that lasts — that suits me: not because it was “product” instead of “consulting,” but because it’s where I could keep learning, building, experimenting.

The risk on the product side: losing the compass

There’s a risk on this side too, and it’s honest to admit it: on an internal product the roadmap bends constantly — a customer asks, an opportunity opens up this quarter — and every single bend is defensible. What’s at risk is the medium and long term: the direction you set when you were thinking clearly, which nobody ever cancels, just keeps getting deferred one reasonable decision at a time. Losing the compass never feels like a decision, which is exactly what makes it hard to notice and even harder to argue against.

From these eight years I took two different things. From the first half, discipline: scoping honestly, delivering what was agreed, reading an organization well enough to know what could actually change and what couldn’t. From the second, something harder to put on a CV: owning the consequences is the only mechanism that makes quality matter to anyone — but it needs the right environment to exist at all. If I’m honest, though, what pulled me toward product wasn’t quality in the abstract. It’s that I’m not someone who sits still. I like to learn, to build, to experiment, and product is where that instinct gets to run instead of being filed away with everything else.

There’s a coda to this. Years later, the technical direction of that same product became my responsibility. The compass problem I’d watched from a developer’s seat turned into the thing I answer for. It’s a fair outcome, and an uncomfortable one: I can no longer file the observation. But it’s also, exactly, what I wanted — a place to build for long enough to have to answer for it.

A wallet inside a chat app that holds no keys

Tue, 22 Jul 2025 00:00:00 GMT

The hardest part of a wallet has never been the wallet. It’s that using one starts with installing something, and most people won’t.

Chat apps are the obvious way out. People are already in them all day, a bot costs nothing to try, and sending money to someone you’re in the middle of a conversation with is a natural act rather than an errand to run. So I built a Telegram front end for Sovrano, the smart-account wallet I’m building on Koinos.

And immediately ran into the thing that makes chat wallets quietly awful.

A bot is a server

Telegram bots are not code running on your phone. A bot is a process on somebody else’s machine, receiving your messages through an API. If that process can sign a transaction then it holds a key — and a service holding your key on your behalf is a custodian, which is precisely the arrangement self-custody exists to avoid.

Most wallets inside chat apps resolve this by being custodial and not dwelling on the point. The money is theirs until you withdraw it. It works, it’s convenient, and it’s a different product wearing the same word.

I wanted the other thing: the reach of a chat interface, without the bot ever being able to move a coin. Which meant accepting up front that the bot could not be a wallet. It could only be the remote control for one.

Every signature leaves the chat

So the bot holds nothing. It knows which addresses you’re watching, because it has to show you balances, and that’s where it ends. Logging in means typing your nickname: it isn’t authentication, it’s telling the interface what to look at.

Whenever something genuinely needs a signature, the flow goes elsewhere. The bot prepares the operation — recipient, token, amount — and replies with a link. You approve it in the browser, with whichever authentication method you chose for your account: a passkey and your fingerprint, or a login with Google, Facebook, Discord, or Telegram itself. The signed result comes back to the bot, which drops you back into the conversation, and that link burns there: it’s good once.

The bot never sees a key, at any point. It sees an intention going out and a signed result coming back.

That the signature has to happen outside the chat isn’t an inconvenience to engineer around, incidentally — it’s the security property working. Whatever method you pick, the credential isn’t in the bot and can’t be reached from there: a passkey is bound to the site that created it and needs the operating system’s own prompt, a social login forces you through the provider. There is deliberately no way for a bot to trigger either one on your behalf, and that is exactly why a compromised bot can’t quietly authorize anything.

There’s a case that makes it obvious: you can sign with Telegram itself, with the same identity you’re using to talk to the bot. The authorization still leaves the chat, and the bot still stays outside it.

The bot sees an intention going out and a signed result coming back. At no point in the sequence is there a step where it holds a key.

The same handoff, recorded: /start, the bot hands off to auth.sovrano.app, a passkey is registered, and the bot confirms the account without ever seeing it.

Chat turns out to be a good interface

The rest was more fun than I expected. Bots are bad at dashboards and unusually good at asking one question at a time — which happens to be the right shape for sending money.

Which token: here are your balances, as buttons. To whom: type a nickname, and it resolves. How much. Here’s the summary, confirm. That’s a wizard, and a wizard inside a chat doesn’t feel like a form to fill in: it feels like the conversation you were already having. Balances, transaction history, NFTs and deposit addresses are all just messages with buttons underneath.

For now the bot stops at those features. I intend to add more, even if it won’t be simple, within the limits of what Telegram’s interface allows.

Where an interface can live

The bot is proof of something more general. Almost everything a wallet interface does — finding the right token, resolving a nickname, formatting an amount, showing you what you’re about to confirm — has no need to touch a secret. Only the signature does. And the bot doesn’t produce that signature: it delegates it to an external gateway that opens in the browser, the same piece any other application can call to have an operation authorized.

The real point is that not even that gateway holds your keys. Whether the account is controlled by a passkey, by an OAuth2 identity or by the usual twelve words, the credential stays where it is — on your device, with your provider, in your head — and the gateway only asks. Which is why the interface can live anywhere at all: inside a chat, inside a website, inside any place you’d never trust with a key, because there is no key there.

Sovrano: a self-custody wallet you open with a fingerprint

Tue, 17 Jun 2025 00:00:00 GMT

Self-custody is presented as freedom, and it is, but the fine print is that you become your own bank’s entire security department. Write down twelve words. Store them somewhere a fire won’t reach and a guest won’t find. Never type them into anything. Lose them and your money is gone, with no one to appeal to.

Then, before you can do anything at all, install a browser extension, and acquire some of the network’s token to pay fees with — using, presumably, the wallet you don’t have yet.

I built Sovrano to find out how much of that could simply be deleted.

What Sovrano is: a wallet you open with a fingerprint

Sovrano is a self-custody wallet on Koinos, a blockchain with no transaction fees. It’s built on Veive, a modular smart-account protocol I’d written for the same chain, where an account isn’t a key pair but a contract, and its behaviour — how a signature is checked, what an operation is allowed to do — comes from modules installed into it.

That’s the load-bearing choice. If the account is a contract that decides for itself what counts as a valid signature, then “sign in with your fingerprint” isn’t a convenience layer bolted onto a key. It’s the account’s actual authentication rule, enforced on chain.

And because the account lives on the chain rather than on a device, it isn’t tied to any platform. Sovrano runs as a PWA in any browser — desktop or mobile, on any operating system — and as a native Android app. There’s no key file to move from one device to another: you register a passkey on each device you want to use, and each one reaches the same account.

So sign-up looks like this:

Sign-up. Note the last line: the seed phrase survives as a discouraged fallback, not the default.

A passkey, an account you already have, or — if you insist — twelve words. Inverting that default was the entire point. No extension to install, no tokens to acquire before you start, and nothing to write on paper.

Signing up with an account you already have: pick a nickname, authorize with X, done.

Passkeys, and hardware keys

Passkeys were the straightforward half: WebAuthn produces a signature, the account contract verifies it, done.

What I like most about that approach is what it opens up as a consequence. A passkey doesn’t have to live in a phone: WebAuthn also talks to FIDO2 security keys — a YubiKey, a SoloKey, or any cheap USB key. Plug it in, enter the PIN, touch it to confirm, and you have the security of a hardware wallet without buying one: the keys never leave the device, physical presence is required to approve a transaction, and there’s no seed phrase in existence to be stolen or intercepted.

Signing in with a hardware passkey: the PIN, then a physical touch on the key.

Social login was the awkward half. OpenID Connect providers issue a signed ID token, and a contract can verify that token’s signature and read its claims — that part works. But plenty of the accounts people actually have aren’t OpenID providers. X, Discord and Telegram authenticate you perfectly well and then hand you something that is not an ID token.

So I wrote an identity broker: a small Passport service that speaks each provider’s own dialect — OAuth for Google, whatever Discord and X and Telegram want — normalizes the result into a subject like google|1234, and mints an RS256-signed ID token of its own, published with a JWK so anything can verify it. Downstream, every provider looks identical: one token shape, one signature algorithm, one public key. The on-chain module doesn’t need to know which one you used.

Google, Apple, Microsoft, X, Facebook: whichever one you picked, the broker is what makes the result verifiable on chain.

Downstream of the broker every provider looks identical, which is what the contract needs. The cost is that the broker signs those tokens, so it can mint an identity for anyone.

I want to be straight about the cost of that. The broker signs those tokens, so the broker is a trusted issuer, and whoever holds its private key can mint an identity for anyone. In a wallet whose whole premise is self-custody, that’s a real centralization point sitting next to the front door. The honest framing is that it was a deliberate trade — reach now, decentralize the issuer later — and “later” is doing a lot of work in that sentence.

What you install into the account

Removing the barriers to entry was half the work. The other half is what that account can do once you have it — and this is where building on modular smart accounts stops being an architectural detail and becomes the product.

Because the account is a contract and its behaviour comes from installed modules, the wallet isn’t a fixed set of features: it’s a container you add rules to. Some of those modules are what the wallet itself stands on: signature validation, the authentication modules for passkeys and OpenID, and allowance — the pre-authorization that records exactly the approved operation and consumes it on use, so an application never holds a broader permission than the one you gave it.

Then there’s multisig, and that’s where a personal wallet becomes something else. The same account can be managed by several people, with transactions requiring signatures from a configurable number of authorized members: a business treasury, a DAO, an investment group. And the same mechanism, applied to the module install and uninstall scopes, becomes recovery: you appoint trusted guardians, register several devices and several social accounts, and if you lose access to one of them the others can authorize replacing it. Account recovery without a seed phrase existing to be recovered.

Beyond those, the same module structure makes writable things a wallet normally can’t offer, because they don’t live in the wallet — they live in the account: a piggybank that sets aside a percentage of every payment, a daily or weekly spending limit, parental control over a child’s account, a subscription guard that catches recurring payments. I didn’t write those — they’re the use cases I documented as a demonstration of what the system allows, and they remain the most interesting part of what there was still to build.

Two parts: the wallet and the payment gateway

It’s worth being clear about the structure here, because Sovrano isn’t one product but two. There’s the wallet, and there’s the payment gateway.

The gateway runs in the browser, and it works the way PayPal or a hosted checkout page works: an application doesn’t embed the wallet and doesn’t ask it for keys, it sends the user to the gateway and gets a result back. If a wallet isn’t a browser extension, applications need some other way to reach it — and the answer is the pattern the web settled twenty years ago: redirects.

A client-side SDK handles it, with three moves. Signup sends a new user off to create an account and returns with their address and nickname. Connector is log-in: the application gets back who it’s now talking to. Authorizer hands over an unsigned transaction, the user reviews and approves it on Sovrano, and it comes back signed, ready to broadcast. Each of the three produces a URL to send the user to, and knows how to read the response when they come back. Anyone who has integrated OAuth recognises every step, which was exactly the goal.

The part that satisfies me most is that the Sovrano Wallet app uses that same SDK. There’s no privileged channel reserved for the official wallet: the wallet is a client of the gateway like any other application, going through the same public interface a third party would use.

Under the hood, an approved action is two operations in one transaction: a pre-authorization that records exactly what was approved — contract, method, arguments — and the execution, which only goes through if it matches. Approve once, spend once.

Telling the user what they’re signing

There’s a problem inside that authorization step, and it isn’t cryptographic. A blockchain operation is a contract address, an entry point, and a blob of encoded arguments. Asking someone to approve that is not consent, it’s a formality with extra steps — the “Requested operations” screen in those demos has to say something true and comprehensible, or there’s no point showing it at all.

So the wallet backend carries a resolver per operation type it understands. The transfer resolver pulls the token’s metadata, formats the amount with the right decimals, and resolves the sender and recipient nicknames, so the screen can say “5 KOIN to @someone” instead of rendering base58. Others cover installing and uninstalling modules, registering and revoking a passkey, registering and revoking an OpenID identity, and specific actions from the applications built on it.

And then there’s the default resolver, for operations nothing recognises. That fallback is the honest bit: a wallet cannot decode a contract it has never heard of, and the right response is to say so plainly rather than dress an unknown call up in reassuring language.

The rest of the app follows from having nicknames: pay @someone, request money from @someone, a list of activity, somewhere to put idle funds. Ordinary shapes, which was the ambition.

Paying @adrianofoschi: search the nickname, and the same “Requested operations” screen resolves it before you sign.

What holds

What I’d defend is the premise. Every barrier I set out to remove came off: account creation is a fingerprint or an account you already have, transactions cost nothing, there’s no extension to install, and the seed phrase is a fallback you have to go looking for. None of that required weakening self-custody, because the account itself is programmable enough to hold the rules. Nobody else holds the keys: the user’s own device does, and what can happen with them is decided by a contract that belongs to them.

No system call for that: getting passkey and JWT signatures verified on chain

Tue, 15 Apr 2025 00:00:00 GMT

Every blockchain hands contracts a short, fixed menu of cryptography. Usually it’s exactly one curve: the one the chain’s own accounts are built on, wired in as a system call, and nothing else.

That’s fine right up until you want an account controlled by something people actually own. A passkey signs with ECDSA over the NIST P-256 curve. An OpenID Connect identity token issued by Google or Microsoft is signed RS256 — RSA with SHA-256. On Koinos, a contract can verify neither: the system call doesn’t exist, so there’s nothing to call.

If you want smart accounts controlled by a fingerprint, or by an account someone already has, that gap is the whole problem. This is how I closed it.

The first attempt: writing it

The first attempt was to write it. Contracts on Koinos are written in AssemblyScript — a subset of TypeScript that compiles to WebAssembly — so the shortest road was to implement the verification there, in the same language as everything else.

It worked, and it wasn’t usable. There are no fees on this chain: every transaction consumes mana, a metered budget, and there’s a ceiling on how much of it one can burn. Verifying a signature is arithmetic on enormous numbers — modular exponentiations, curve multiplications — and that arithmetic written in AssemblyScript cost too much. A single verification ate an amount of resources that made doing it on every operation impractical. And on every operation is exactly when it’s needed.

The problem wasn’t correctness, it was cost. Which changes the question: not “how do I write this”, but “where do I find an implementation already written to run where resources are scarce”.

Where to find cryptography that fits in a VM

There’s a second reason not to write it, independent of cost. These algorithms have decades of subtle ways to go wrong, and a mistake doesn’t crash anything: it makes the contract accept a signature it should have rejected. You find out when somebody takes advantage of it.

So I was looking for an implementation already written, already used in production, that could run under a contract’s constraints: no operating system, no dynamic memory allocation, and compiled code that has to stay small.

Those are a bootloader’s constraints.

For P-256 I took BearSSL’s ECDSA verifier, by way of oreparaz/p256, which reduces it to a single header file; BearSSL is written for embedded systems. For RSA I took the implementation from Chrome OS verified boot — the code that checks the operating system’s signature at startup — and forked it to verify JWTs before porting it to the chain.

Verified boot is the clearer case of the two. A bootloader verifies signatures and never produces one, runs before an operating system exists, doesn’t allocate memory, and has to fit in very little space: the same four things a contract has to do. Someone had already solved the problem under my exact constraints, a decade earlier, for reasons that have nothing to do with any of this.

The work was getting it into the chain: that C inside a C++ contract compiled to WebAssembly with the Koinos toolchain, and small enough to deploy.

Make it work off the chain first

Debugging a contract inside a VM is slow and blind: you see that the verification answered no, and you don’t know why. So before putting anything on chain, I got a real Google token verifying in C, on my laptop.

Mostly it was there to separate two kinds of error. When a verification fails, the problem is either in the port or in the data being handed to it, and the data is the treacherous part. A JWT has to be taken apart into its three pieces, the signature is encoded in a variant of base64 that isn’t base64, and it has to be decoded correctly before it’s any use. A 2048-bit RSA signature is exactly 256 bytes long: if it isn’t after decoding, there’s no point going further, because everything after that will fail for the wrong reason.

With the same code running on a laptop, that answer arrives in a second. Only then is it worth compiling anything to WebAssembly.

The contract is almost nothing

The contract itself is the smallest part. Each of the two wraps its imported header in about a hundred lines: one entry point, three arguments — signature, public key, message — and a yes or a no coming out. No state, no stored data, no authority: a pure function that happens to live on a blockchain.

The interesting part is what goes in and what doesn’t, because every choice is the same choice: take work away from the chain.

The public key the RSA contract expects isn’t the key the provider hands you. It’s a prepared version, holding the modulus plus a constant computed in advance to make the multiplications fast. Verified boot has that computed by whoever prepares the key, rather than by the device doing the verifying — a decision made for bootloaders that is worth even more here. The sum is done once, outside, and what’s left for the contract is only the part that can’t be avoided. Same logic for the message: the contract receives a 32-byte digest, not the token, because hashing a few hundred bytes has no business happening on chain.

Everything that can be computed in advance is computed off the chain. What is left inside the box is the part that cannot be avoided.

One thing that can’t be moved out is the padding check. Verifying an RSA signature doesn’t just mean comparing two numbers: the signed block has to be rebuilt and checked byte by byte. That’s where forged signatures hide, and skipping the check means accepting them.

The same idea holds on the P-256 side, and it shows in the arguments: the contract doesn’t receive the passkey’s response and doesn’t parse it. It receives exactly the bytes the browser signed, assembled outside.

The verifier’s whole job, at the right-hand end of the flow: three arguments in, true out.

No dynamic allocation anywhere, fixed-size buffers throughout. The two contracts are the same file with a different verifier inside.

Two stateless contracts, each answering a single question, and from there on any smart account on the chain can be controlled by a passkey or by a token issued by an identity provider — with the check happening on the chain, instead of a server saying “trust me, I verified it”.

What I take away isn’t the code, it’s where I found it — and why there. When you need a cryptographic primitive inside a VM with few resources, the useful implementations aren’t in the server-side libraries you reach for first: they’re in bootloaders, in embedded TLS stacks, in firmware. The people who wrote them were working under the same constraint that had stopped me here — do as little as possible, with as little as possible — and the decisions that fall out of it, like precomputing everything that can be precomputed somewhere else, hold on a blockchain exactly as they held at the start of a computer.

Veive: turning a blockchain account into something you can program

Tue, 11 Mar 2025 00:00:00 GMT

On most blockchains, an account is a key pair. Not a record, not an object with rules — a public key you can be paid at, and a private key that can do absolutely anything with what’s there.

Almost every complaint about using a blockchain follows from that one fact. There is no recovery, because there is nothing to recover to: lose the key and the account is gone, and no one can help you. There are no permissions, because a key has nothing to reason with — an account can either do everything or nothing. No spending limit, no second approver, no letting an application move exactly one token and nothing else. And onboarding always terminates in the same instruction: write down these twelve words, keep them forever, tell no one. All of these are symptoms of the same cause: there’s no account capable of running its own logic — not just signing or refusing, but reacting, automating, doing things on its own behalf.

Ethereum’s answer is account abstraction: make the account a smart contract, so it can decide for itself what a valid signature is and what an operation is allowed to do. ERC-4337 established the pattern, and ERC-7579 standardized modular smart accounts — accounts you extend by installing modules.

Koinos, a blockchain with no transaction fees, had no account abstraction at all. I set out to build it, and called it Veive.

An account made of parts

A Veive account is a contract that does very little by itself. It’s a container. Behaviour arrives as modules you install into it, and there are four kinds:

Validation modules decide whether an operation is authorized. This is policy: a valid signature, multiple approvers, a pre-authorized allowance.
Execution modules carry an operation out — and, because they’re just code, they can do more than the operation literally asked for.
Sign modules define how you prove it’s you — a seed phrase, a passkey, an identity provider.
Hook modules run before and after an operation. Pre-hooks can check conditions and block; post-hooks can log, notify, or trigger follow-up work.

The flow of a single operation through validation, a pre-hook, execution, and a post-hook — the account calls each module type in turn, and every one of them can stop it.

It’s tempting to read that list as four flavours of permission check. It isn’t. Only the first one is about saying no.

The split I’d defend hardest is the third one. In ERC-7579 the validator both authenticates and authorizes. Separating the signature method from the authorization policy means they can vary independently: you can move an account from a seed phrase to a fingerprint to a Google login without touching a single rule about what that account is permitted to do. Authentication is a mechanism, policy is a decision, and they change on completely different schedules.

An operation is a specific thing

ERC-7579 is deliberately vague about what an “operation” is. Veive pins it down: an operation is a contract_id, an entry_point, and its args — this contract, this method, these arguments.

Being concrete there is what makes fine-grained policy expressible at all. “Require multiple signatures for transfer on the KOIN contract, and a plain signature for everything else” is only a sentence you can write if the system knows what a call to a specific method of a specific contract is.

The missing chokepoint

The one piece of ERC-4337 I could not copy was its EntryPoint — and not copying it is what made the result stronger.

ERC-4337 routes everything through a singleton EntryPoint contract. Every user operation goes in there, gets validated, and comes out the other side. It’s a chokepoint, and chokepoints are convenient: one place to stand and check things.

Koinos has no EntryPoint. Operations reach accounts directly. My first read was that this was a gap I’d have to work around.

What Koinos has instead is a native authorize hook: when a call needs an account’s authority, the chain asks that account, directly, whether it authorizes it. Veive implements that hook, and the consequence is better than the thing I was copying.

An EntryPoint only sees what passes through the EntryPoint. The chain’s own authority mechanism sees everything — including operations generated internally by other contracts partway through a transaction. So when a contract, in the middle of doing something you did approve, tries to slip in a token transfer from your account that you didn’t, your validation modules are consulted for that too, and it fails. Not because I added a defence against it, but because validation is wired into the layer that actually knows about every call, rather than into a lane that well-behaved traffic agrees to use.

The same hook covers the chain’s other authorization types, so an account’s policies also govern uploading contract code and applying a transaction — not just calls. And there’s one small guard I’m fond of: if the caller asking for authorization is the validation module itself, the answer is always no. A module cannot vote itself into power.

Scopes: picking the right module at the right moment

If an account can hold many modules, something has to decide which one applies to the operation in front of it. Veive resolves that through scopes, at three levels of specificity:

entry_point + contract_id — this method on this contract
entry_point — this method anywhere
any operation

Resolution runs most-specific-first, and the rules differ per module type, which is the detail that makes the whole thing behave sensibly:

Validators: the single most specific match wins. Exactly one policy decides, so there’s never an ambiguous verdict.
Executors and hooks: everything that matches runs. These compose; a logging hook and a rate-limit hook have no reason to exclude each other.
Sign modules: one, account-wide. Two simultaneous ways to prove identity is two attack surfaces, and the whole point of the account is that identity has a single answer.

Different resolution strategies for different module types sounds like an inconsistency. It’s the opposite: a decision must be unambiguous, side effects should accumulate, and identity should be singular. The dispatch matches what each kind of module is actually for.

What you actually build with it

The reason all of this matters isn’t the taxonomy — it’s that behaviour people normally expect from a bank lands inside the account, where no application can route around it.

A piggybank. An execution module installed in the transfer scope that puts a percentage of every outgoing transfer into a savings account. Not a feature of a wallet app, not a service you sign up for: the account does it. Every transfer, from any application, from any device, including ones that have never heard of the module.

A spending limit. A pre-hook that inspects the operation before it runs and blocks it if it exceeds a cap. The cap belongs to the account, so it applies to every path into that account rather than to the one interface that bothered to implement it.

A notification. A post-hook that fires after significant transfers. Because hooks are scoped like everything else, “significant” can mean one thing for a specific token contract and something else globally.

A pre-authorized allowance. mod-allowance is a validation module that inverts the usual order: you approve an exact operation in advance — contract, method, arguments, transaction — and store it. When the operation later arrives, it’s checked against what you approved, and on a match the allowance is consumed. Approving something once means it can happen once; a replayed transaction finds nothing left to spend. And since Veive validates internally generated operations too, this covers the calls a contract makes on your behalf partway through doing something else, not just the ones you sent yourself.

Recovery through guardians. The same multisig module used for shared ownership also works for recovery: installed in the module install/uninstall scopes, a group of guardians — with a configurable threshold, say two of three — can authorize replacing a lost signing method, like a lost device’s WebAuthn key. No external recovery service is needed: it’s the same validation mechanism, applied to a different scope.

Multiple signatures. A validation module requiring several approvers for operations in a given scope, while everything outside that scope carries on with a single signature.

None of these need the applications to cooperate, and none of them need the account to be rewritten. Install, and the account behaves differently from that block onward.

Passkeys and Google accounts, verified on chain

The sign modules are where the abstraction stops being theory.

mod-sign-webauthn lets an account be controlled by a WebAuthn credential — a passkey. You register the credential’s public key with the account, and from then on a fingerprint or a face signs transactions. No seed phrase exists anywhere.

mod-sign-openid goes further: you link an OpenID Connect identity — a Google or Microsoft account — and the account verifies the provider’s ID token itself. On chain, the contract decodes the JWT, checks it against the provider’s public key, and reads the claims to confirm the operation was authorized by that user. A person who has never heard of a blockchain signs in with the account they already have.

Neither of those was possible with what the chain provided. WebAuthn signs with ECDSA over P-256; OpenID ID tokens are signed RS256. Koinos could verify neither, so both primitives had to be brought on chain as standalone verifier contracts, written in C++ and compiled to WebAssembly, exposing a single method: given a signature, a public key and a message, is this valid?

The cryptography itself I didn’t write, and there’s no reason anyone should — P-256 verification came from BearSSL’s single-file ECDSA verifier, and RSA from the implementation in Chrome OS’s verified boot, which I forked to work through JWT verification before porting it. The work was getting battle-tested C into a blockchain VM: onto the Koinos C++ SDK, through the WASI toolchain, and small enough to deploy.

A nickname registry is the last piece of the barrier. An account you reach by @name, open with a fingerprint, on a chain where transactions cost nothing, is an account a normal person can be handed. No extension to install, no tokens to buy first, no secret to guard for the rest of their life.

Where it stands

The module packages are published on npm under MIT — validation, execution, sign and hooks base libraries, plus concrete modules for mnemonic, WebAuthn and OpenID signing, multisig validation, and pre-authorized allowances. They’re installable.

The documentation site, rebuilt and republished on GitHub.

What I don’t discount is the design. The constraint I thought was a deficiency — no EntryPoint to build on — is exactly what forced validation down into the layer where every call is visible, and produced authorization coverage the pattern I was copying doesn’t have.

The freelance years: real clients, and a lesson school never taught me

Mon, 16 Dec 2024 00:00:00 GMT

Freelancing, from 2013 to 2015, was the first time nobody else’s name was attached to the work — no principal assigning it, no institution funding it, no program structuring it. No one was vouching for me. If a client trusted the work, it was because of the work itself, not because something else stood behind it.

Finding clients, two different ways

I worked both ends of it: bidding for projects on Freelancer.com, competing with people I’d never see, entirely on a portfolio and a proposal — and local clients, found the older way, through word of mouth. The two were almost opposite experiences. On Freelancer.com you were a line item in a list of quotes, judged on price and past reviews before anyone read a word you wrote. Locally, you were a person someone’s cousin recommended, and the first meeting mattered more than the portfolio did.

What the work actually was

It wasn’t one kind of project. Some of it was commercial websites — a WordPress theme built for a studio, a site for a small brand, the kind of work that’s mostly about understanding what a business actually needs to show people, not just building a page. Some of it was heavier: management software for real operations, complex enough to need actual design before any code — I built one for a nightclub’s day-to-day bookings and administration, in a Node.js framework called Feathers, which at the time was still a fairly deliberate choice. I also built and shipped small standalone tools, like a QR code generator site people could use directly, no client relationship required at all.

The lesson that mattered more than any of it

If I had to pick one thing this period taught me that four years of a CS degree hadn’t: technical skill gets you in the room, but it’s not what keeps a client relationship working. Understanding what someone actually needs — which is very often not exactly what they first ask for — and managing expectations honestly when reality doesn’t match the timeline or the budget, matters just as much as the code itself. Nobody grades that. You just find out the hard way when a project that was technically fine still left a client unhappy, or a project that had real problems still ended well because you communicated clearly through it.

That’s the part no classroom ever tested, and the part freelancing forced on me directly.

Graded by someone who didn't understand what I'd built

Tue, 08 Oct 2024 00:00:00 GMT

I started a Computer Science degree in 2009 with a very weak background in mathematics. It had never been my subject, and the degree’s math courses made that clear immediately: I ended up repeating several of them, struggling to keep pace while other students seemed to move through without much effort. For a couple of years I felt like I was always one step behind — not from lack of effort, but because I was missing foundations other people already had.

Not all of the math was an obstacle, though. Discrete mathematics, of all things, was one of the courses that opened my mind the most from a logical standpoint: sets, relations, graphs, propositional logic — a way of thinking that felt closer to how I already reasoned when writing code, and that course was the first to make it explicit. The Programming Languages course was one of the most interesting of the whole degree too, for a different reason: not so much its difficulty, but the pleasure of seeing formalized what I had so far only worked out by intuition.

The Web Programming exam: usability and security

One exam I was looking forward to more than most, near the end of the degree, was Web Programming. The assignment was simple to state and anything but simple to do well: build a web project — any web application — and document the work. The two requirements that mattered most were usability and security: avoiding, at the most basic level, mistakes like SQL injection. In practice, most of my classmates turned in projects that either didn’t work or were riddled with elementary security holes, built on the same PHP-LAMP examples that were being copy-pasted from site to site at the time.

What I built: an MVVM frontend and a BlaBlaCar clone

I decided to do things differently. On the server side I chose a PHP micro-framework designed specifically to guarantee a high level of security by default, instead of hand-writing queries and routing the way almost everyone else did. On the frontend I used Knockout.js — an MVVM (Model-View-ViewModel) framework that predated Angular and React by a few years, one of the first to bring automatic binding between data and interface to the web without updating the DOM by hand, line by line. With those two pieces I built a working clone of BlaBlaCar: ride search, bookings, user management, and a modern, responsive interface — far from a given at the time, when most university projects stopped at a fixed layout designed only for the lab monitor.

A 20, and a professor who didn’t know what MVVM was

The final grade was 20 out of 30. Very low, especially next to what I’d seen other students submit. I went to ask the professor for an explanation, expecting some technical point I’d missed. Instead, from the conversation, I noticed something else: he hadn’t actually understood what an MVVM framework was, or what it meant in practice to separate logic from data and view that way. His level of knowledge about what I had built was, simply, lower than mine. It was a hard thing to take in — not so much the grade itself, but discovering that whoever was judging me didn’t have the tools to do it. I absorbed it anyway.

The opposite result, in Physics

The flip side came from another exam around the same period: Physics. It was a subject I had no great hopes for — I felt as distant from it as from pure mathematics, maybe more. I sat the exam without expecting much. The result was 30 out of 30 with honors, the highest grade I could imagine, exactly where I expected the least.

Put side by side, those two grades don’t tell a coherent story, and I think that’s exactly the point. A 20 on the work I was proudest of, a 30 with honors where I expected nothing: the grade wasn’t a reliable measure of either the quality of what I’d done or my actual understanding of the subject. Sometimes the person judging doesn’t have the tools to see what’s in front of them, and the merit stays invisible. Other times it goes the other way, and you get rewarded beyond any expectation. I learned early not to put too much weight on a single number — and to trust more in what I actually knew I had built.

A prediction game with no fees, and the server that keeps time for it

Tue, 11 Jun 2024 00:00:00 GMT

Prediction games have been popular for a while now. The format is always the same: you bet on how something will turn out, and whoever gets it right splits the money of whoever got it wrong. It works because it asks you to know nothing about finance, only to have an opinion about where a price is going over the next few hours.

What I built is the minimal version. A round opens on a currency pair. You put some tokens on long or short. Betting closes, the round runs, and at the end the price is compared against where it started. The winning side splits the pot; the losing side filled it. It’s a prototype, running on testnet, built on Koinos — a blockchain with no transaction fees.

Fees are the first thing that makes a game like this impossible. On a chain with gas, a one-dollar bet costs more in fees than it can win: the stake has to be big for the toll to be worth paying. Remove the fee and small stakes become possible again, so rounds can be short and casual instead of long and serious.

But the real friction comes earlier, and fees are only its last line. To bet one dollar, someone has to install a wallet, put twelve words somewhere safe, open an account on a centralized exchange, verify their identity, buy the token, work out which network they’re buying it on, and send it to their own address. Then they can bet their dollar. Nobody walks that whole road for a game. The chain took the fees away; the rest of the road, this prototype doesn’t touch.

Choosing a pool, and betting in one. The two payout figures move as money lands on either side.

The contract was the easy part

The on-chain half is unremarkable, which is the right outcome. A round has a state — open, in progress, closed, or one of two failure states — and users’ bets hang off it. Three operations matter: entering by putting money on a side, collecting if you won, taking your stake back when a round can’t be settled. Everything else is bookkeeping.

Payouts are pari-mutuel, not fixed odds. There’s no house on the other side of your bet: the winners divide what the losers staked, in proportion to what each put in. That’s why the two percentages on the betting screen keep moving — they aren’t a price the game is offering you, they’re the current shape of the pot.

Written and deployed, that’s a few hundred lines of AssemblyScript. And it does nothing at all, forever, because of two things a blockchain cannot do.

Koinos has no oracle

An oracle is the piece that connects a blockchain to the world outside, and it’s needed for two distinct things that often get conflated.

The first is time. Nothing happens on a blockchain unless someone sends a transaction: there’s no scheduler, no cron. A contract reacts, it never acts. So “betting closes in eleven minutes” isn’t something the contract can enforce by itself — somebody has to show up at the right moment and tell it to change state: open the next round, close betting on this one, settle that one.

The second is facts. A contract can’t go and read the price of Bitcoin: it has no network access, and it must not have any. Every node executing that transaction has to arrive at an identical result, and two nodes calling an API a second apart would not. Determinism is the basis of consensus, and reaching outside is how you break it. So the price has to be handed to the contract from outside.

On bigger chains this service already exists as infrastructure in its own right, shared by whoever needs it. On Koinos it doesn’t. So I implemented it: an external server that reads the state of the current round, works out which transition is due, asks Coinbase’s public API for the pair’s rate, and sends the transaction that moves the round forward, carrying the price along as an argument.

The rules sit in the contract and nobody can change them. The clock and the price arrive from one process, one key and one exchange’s endpoint — which is where the trust actually sits.

The server is a point of trust

The rules of the game are on chain and nobody can change them. The clock and the price are not. If the server stops, rounds hang; if it gets the price wrong, or lies about it, the round closes badly and the chain records the result without asking questions. This isn’t trustless: the stakes are held by a contract nobody can rewrite, but settlement depends on one process, one key, and one exchange’s public endpoint.

The correct solution is an oracle network: several independent reporters, staked, penalised for disagreeing. That’s an order of magnitude more work than the game itself, and it doesn’t fit inside a prototype.

What does fit is making sure that when something goes wrong, the money comes back. That’s why a round has two failure states next to the successful one: if the server doesn’t return, if one side has no players, if something doesn’t add up, the round is marked skipped or suspended rather than closed, and the refund opens. Nobody loses a stake to an event that didn’t happen properly.

Mana: measuring the limit rather than guessing it

Koinos charges no fees: it meters transactions with mana, a regenerating budget, and before sending one you have to declare how much it may consume. Estimate too low and the transaction fails, too high and you tie up more than you need.

So the server sends everything twice: first as a trial run that isn’t broadcast, purely to read back how much it actually consumed, then for real with that figure plus ten percent. The limit is measured rather than guessed.

What I take away from this project is a question. When someone shows me a decentralized application, I don’t ask whether it’s decentralized — almost none of them are, if you’re strict about it. I ask which parts aren’t, and what those parts can do to me on their worst day. Usually there are more of them than the pitch lets on, and almost nobody has thought about the refund.

Update — February 2025

Since writing this I’ve started building Sovrano, a smart-account wallet you sign into with an account you already have, with no twelve words to keep safe. That’s where a game like this one should live. The missing piece isn’t the contract: it’s everything that comes before it — installing a wallet, opening an exchange account, verifying your identity, buying the token, sending it to yourself. The goal is to bring the purchase inside the wallet too, so that between wanting to bet a dollar and having bet it there’s nothing left in the way. I’m not there yet.

The other direction is the game itself. Right now it can do one thing: compare a pair’s price against where it started. But the contract doesn’t need to know it’s looking at a price — it needs an event with a date and an outcome, reported from outside. Making it agnostic about the type of event means being able to open rounds on a match, on a vote, on anything with a verifiable result: what changes is who brings the result in, not the rest.

My thesis: Hadoop vs. MySQL, and an honest result nobody expected

Tue, 12 Mar 2024 00:00:00 GMT

I started a computer science degree in 2009. By the time I got to my thesis in 2012, Big Data was becoming a real word, not just a buzzword yet, and I wanted my thesis to be about actually building one of these systems rather than just reading about them — a data warehouse that pulled together data from different web sources using the emerging Hadoop/Hive stack, instead of a traditional relational database.

What I actually built

The dataset was geolocated tweets, cross-referenced with nearby points of interest — cafes, banks, bookstores, transit stations — each with its own category, rating and price level. The connecting concept was the “hotspot”: a public WiFi access point, with its own coordinates. The core question the model let you ask was things like: how much does a hotspot’s neighborhood get talked about, how “urbanized” is it based on how many places surround it, and what’s the weighted price level of everything nearby.

The multidimensional model: tweets as one fact table, hotspot-to-place relationships as another, joined through a shared hotspot dimension.

Computing “how close is this hotspot to that place” meant calculating real-world distance from latitude/longitude pairs, so I wrote a small Java UDF — a Haversine distance function — and loaded it straight into Hive as a custom SQL function. It’s still sitting in a public repo, still compiles, still does exactly what it did in 2012.

The experiment

Building the warehouse in Hive wasn’t the actual thesis question. The real question was whether it was worth it — so I built the identical data warehouse a second time, in plain MySQL, and benchmarked both against a real sample: about 103,000 records across tweets, places, hotspots and users. Three things got measured: storage size, import time, and query response time.

Two of the three results were exactly what you’d expect from the pitch. Hive’s storage came out smaller — about 8MB against MySQL’s 13.5MB for the same data — because a schema-less format doesn’t waste space on padding or null columns the way a rigid relational schema does. Import time wasn’t close: Hive loaded the entire dataset in just over 2 seconds, MySQL took over 5 minutes, because Hive is essentially writing files while MySQL is doing per-row inserts with constraint checking.

Then came the query benchmarks, and the results weren’t what the pitch promised. On two of the four analytical queries — the ones combining a join with heavier aggregation and sorting — Hive was actually slower than plain MySQL, not faster.

Measured on ~103,000 records	Hive	MySQL
Storage for the same data	~8 MB	13.5 MB
Import time, whole dataset	just over 2 seconds	over 5 minutes
The four analytical queries	slower on two of them	faster on those same two

Why, and why it mattered more than the speedup did

The honest explanation, which is also the more useful lesson: the whole benchmark ran on a single machine. Hadoop and Hive are built to win by spreading work across many nodes in parallel — take that away, and you’re left with the translation overhead of turning a query into a MapReduce job, with none of the payoff. On top of that, 103,000 records simply isn’t big data. MySQL is built to be fast at exactly that scale, and at that scale it held its own.

I didn’t design the experiment to prove Hive right — I designed it to find out, and the answer was “it depends on scale, and only actually measuring it tells you.” That’s a duller conclusion than “the new thing wins,” and a much more useful one. It’s the first time a project taught me not to trust a technology’s reputation over an actual benchmark, on my own data, at my own scale — a habit that’s saved me more than once since.

The thesis got a 106/110. The UDF is still on GitHub.

A migration with no undo, and 2,000 users in three weeks

Tue, 09 Jan 2024 00:00:00 GMT

By autumn I had a mobile wallet in production. Konio was a native iOS and Android wallet for Koinos, a blockchain with no transaction fees, and I had written it alone: create or import a wallet from a seed phrase, hold tokens and NFTs, sign for dApps over WalletConnect, in eleven languages.

It worked. The data model underneath it did not, and the next six months went into three things: fixing that, making the app comprehensible, and getting people to use it.

The data model I had shipped was wrong

Version one stored everything in two blobs. One JSON object in ordinary device storage held settings, accounts, coins and the address book; one encrypted object in the OS keystore held the keys and the password. Accounts carried an array of token contract ids, and those tokens lived in a separate map keyed by contract id alone.

That was exactly the problem. A token isn’t a single, global thing: if I had two accounts, each with its own balance of the same token, or the same token on two different networks, to the app they were the exact same entry — because I stored it keyed only by contract id, with no record of which account or which network it belonged to. The result was that two different balances would end up overwriting each other. Every new feature I tried to add, starting with real multi-network support, ran straight into this limit.

In October I rebuilt it from scratch: instead of two big blobs, five separate stores — settings, accounts, secrets, coins, contacts — where every entry carries its own unique identifier. For coins, that identifier was no longer just the contract, but the combination of account, network and contract together: exactly what a balance actually is, in reality — a specific number for a specific account on a specific network.

Doing that without a server

There was no backend here, no backups, and no undo. The only copy of a user’s data was on their phone, and part of that data was the keys to their money. A migration that half-succeeded wouldn’t produce a support ticket, it would produce a person locked out of their own funds — permanently, because there’s no password reset for a blockchain account.

Four decisions made it survivable, and I’d reuse all of them:

Migrations were dated, ordered, and committed one at a time. Each one was a function keyed by a date — 20231003, 20231004, and so on — sorted and applied in sequence, with the stored version bumped only after a migration returned successfully. A failure halfway through the chain left the version at the last step that had actually worked, so the next attempt resumed at exactly the right place instead of redoing work already done.

Failure was loud and blocking. A dedicated screen gated the app when a migration was pending, and if one threw, it showed the real error text instead of a friendly message. That looked unpolished. It was the right call: the alternative was an app that carried on with half-converted data and let the user act on it.

Old data got deleted one version later, not in the same step. The migration that read the v1 blobs didn’t remove them. A separate, later migration did. For one release, the original data sat there untouched as a safety net — cheap insurance, paid for in a few kilobytes.

Small, boring migrations were fine. Five shipped between October and February. One re-encoded every stored NFT token id to hex. Two just corrected a default value. Keeping them tiny is what made each one easy to reason about, and reasoning about them was the whole job.

Making the app explain itself

Over the same period I restructured the interface to be clearer at a glance — anonymous icons out, named sections in. The overall UX improved a lot too, especially the send and receive screens, and the whole NFT section.

The redesigned main screen. The orange figure under the balance is mana.

The change I cared about most was that small orange percentage. Mana is what makes transactions on Koinos free: it’s a resource tied to the tokens you hold, spent when you transact and regenerated over time. Users had no existing mental model for it, and the temptation was to hide it — free should mean the user doesn’t have to think about it. Hiding it was worse. Someone whose transaction failed because mana ran low, with nothing on screen having warned them, concluded the app was broken. Showing “42%” and letting them tap through to a fuller explanation treated a real constraint as a real constraint.

Letting the ecosystem add itself

Three of the repositories weren’t code. konio-tokenlist, konio-dapplist and konio-collectionlist were folders of small JSON files, one per token, dApp or NFT collection, and anyone could add their own with a pull request. A token entry was a contract id, a symbol, a logo, and a price endpoint plus the path to read the number out of the response. A dApp entry was a name, a summary, tags, a URL and an icon.

A listing announcement from January 2024. Each of these arrived as a pull request against a folder of JSON files.

This was self-defense as much as openness. I was one person. Curating an in-app catalog by hand is an unbounded second job that grows exactly as fast as the thing succeeds; reviewing a ten-line JSON pull request takes two minutes. It also meant a project didn’t need my attention to appear in the wallet — they needed a text file. By January the app shipped with those lists prefilled, plus push notifications and a discovery feed that read the project’s own posts.

The giveaway

In November I ran an onboarding campaign, and I ran it myself — the code and the marketing were the same person.

It was announced on 12 November and ran from the 21st to the 27th, hosted on Zealy, where participants complete small tasks to earn entries. The prize pool was over $3,000: a 48-piece NFT collection I wrote a smart contract for, KOIN, tokens contributed by partner projects, and KAP name vouchers. Twelve projects from the Koinos ecosystem put prizes in. Influencers carried it to a few hundred thousand social followers.

On 20 December the wallet passed 2,000 active users.

I’ll be honest about what that number is and isn’t. A giveaway measures reach, not retention — a meaningful share of those installs were there for the prize pool and behaved accordingly. What it did do, beyond the wallet, was pull twelve separate projects into a single coordinated push and give a small ecosystem a week of momentum it wouldn’t otherwise have had. That part I’d count as the real result.

The blockchain that felt like web2, and the mobile wallet it was missing

Tue, 03 Oct 2023 00:00:00 GMT

I was drawn to web3, and I was looking for a blockchain that would let me build with the mindset and tools of a web2 developer — smart contracts in AssemblyScript, close to TypeScript, REST APIs instead of the usual opaque RPC endpoints. Koinos stood out for the rest of it too: no ICO, no pre-mine, a Proof-of-Burn consensus designed to combine proof-of-stake efficiency with proof-of-work economics, and on-chain governance that upgrades the protocol by vote instead of by hard fork. But what actually convinced me was that the developer experience looked like ordinary web development.

Smart contracts were written in AssemblyScript, a subset of TypeScript, through an SDK that compiled them to WebAssembly. The node exposed REST APIs, and there was koilib, a JavaScript library that behaved like any other SDK you’d pull off npm — a genuinely good one, with APIs for pretty much anything I needed. I didn’t have to earn the right to write the first line of code by learning a new language and a new mental model first: everything I already knew from years of web work transferred directly. I’d never worked with React Native before, and this was a good excuse to get into it — there was a learning curve, but the path was clear.

Once I joined the community — small, but already a few years old — I noticed something I hadn’t expected: Koinos had been around for a while, and yet there was no way to use it from a phone. Just browser extensions. Nothing native on mobile. It was a well-shaped gap: the problem was obvious, the scope was finite, and I’d find out quickly whether I could actually pull it off.

What Konio is: a native wallet for iOS and Android

I started writing Konio on 22 June, and by autumn it was already on both app stores: a native wallet for iOS and Android, built with React Native and Expo, using koilib to talk to the chain.

The feature list was what you’d expect. Create or import a wallet from a seed phrase, then derive additional named accounts from that same seed so there was only one thing to keep safe. Biometric unlock and an autolock timer. Send and receive tokens and NFTs, with an address book so I wasn’t pasting base58 strings by hand. WalletConnect, so the wallet could sign for dApps — including scanning a QR code from a desktop browser. An in-app browser for dApps. Multiple networks. Eleven languages, because the Koinos community was scattered across a lot of countries and none of them were mine.

The main screen. Mana is the resource that makes transactions free on Koinos, so it gets a row of its own next to the balances.

Sending tokens. Most of the work in a wallet is in the ordinary screens, not the cryptography.

That summer Koinos ran a hackathon, the Supercharger, from 10 July to 7 September. I entered Konio and won. It’s a small ecosystem and I want to be honest about the scale of that — but it was enough to settle whether the gap I’d picked was real or just something I’d talked myself into.

The cryptography, honestly, was the easy part. koilib signed the transactions; I didn’t need to invent anything. The hard part was somewhere else, somewhere I didn’t expect.

The hard part was state

A wallet had no server. There was no backend holding the truth, no account to restore from, no “log in on your new phone and everything comes back.” Whatever the app knew lived on that device and nowhere else, and a meaningful slice of it — private keys, the password — could never leave the operating system’s secure storage. Get the state layer wrong and you didn’t get a bug report, you got somebody who couldn’t reach their money.

On top of that, everything in a wallet was connected to everything else. Forty-one screens all read and wrote the same handful of entities: accounts, coins, networks, contacts, NFTs, transactions, WalletConnect sessions, mana balances. Adding an account had to create the default coin entries for every configured network. Switching network had to change what half the app was showing.

For state I used Hookstate — a little-known library, but a very capable one if you use it with care, lighter and more adaptable than alternatives like Zustand. The persistence layer, though, I wrote by hand.

I built it around an adapter: every store saved and reloaded its data through a common interface, but the backend behind that interface changed depending on what it had to hold. Ordinary data went through the phone’s normal storage; private keys and the password went through the operating system’s encrypted keystore instead — the same mechanism that protects system passwords, not something I built myself. The code that read and wrote the two kinds of data was identical; only the adapter handed to it changed. So the difference between “ordinary data” and “data that needs protecting” wasn’t a rule scattered through the code, it was the choice of a single adapter.

The other piece was hydration: on app launch, state started out empty, and data got reloaded from disk asynchronously — that took a moment. In that moment, a balance shown as zero was indistinguishable, to the user, from a balance that was actually zero: it looked exactly like a wallet that had lost their money. To avoid that, every store explicitly flagged when it had finished reloading, and screens waited on that flag before showing any number, instead of showing an empty state as if it were already the truth.

Accounts, coins, and networks constantly referred back to each other, and wiring them all directly to one another would have created a tangle of dependencies. Instead, every store registered itself under a name and looked up the others only when needed, rather than depending on them directly.

None of this was exotic. It was the same problem as any offline-first app: the device is the source of truth, persistence is async, and the data model is a graph rather than a list. What sharpened my thinking was the stakes. In most apps, a state bug means a wrong number on a screen and a refresh. Here, the number on the screen was the only record.

Getting it published was a second project

Writing the wallet took a few months. Getting Apple to accept it took a different kind of stubbornness, and none of it was technical.

The blocking rule sits in the App Store Review Guidelines at 3.1.5(b): an app may offer virtual currency storage only if it comes from a developer enrolled as an organization. An individual developer account can’t publish a wallet at all — full stop, regardless of what the app does or how well it does it. So the first hard requirement for shipping this project had nothing to do with software: I needed a legal entity, and I didn’t have one. Konio went out under E-Time, the software house I was working for at the time, which agreed to act as the publishing entity.

That got me into the queue. The queue was its own education. Crypto apps get treated as guilty until proven otherwise, and the rejections read like they’d been written without anyone actually opening the app: objections to behavior that wasn’t there, points I’d already fixed and explained in the previous submission coming back verbatim, replies that didn’t engage with the answer I’d already given. Every round cost days, and none of those days made the app any better.

I don’t think that scrutiny is unreasonable in principle — a wallet is one of the few categories of app where a malicious build can drain someone’s savings, and the store is the only thing standing in front of that. But the process, as I experienced it, filtered on paperwork and pattern-matching rather than on whether the software was any good. A solo developer with no company behind them doesn’t get past the first gate, and that has nothing to do with the quality of what they built.

Konio’s source is on GitHub, under GPL-3.0 — publishing it felt like the right way to close out a project that a hackathon and an App Store review had already put through enough scrutiny. What stays with me, after seven months of writing it, is a habit: treating local state as a system with its own architecture — adapters, hydration, a dependency graph — rather than as a bag of variables the screens happen to share.

Building software my school needed

Tue, 25 Jul 2023 00:00:00 GMT

In 2003, right after middle school, for someone with my grades the path seemed already decided: a liceo. A technical or industrial institute, in the mind of everyone around me, was the choice you made when you couldn’t handle something more demanding — not something a good student did.

I had already made up my mind, though. A technical institute meant, sooner or later, computer science — the subject I actually cared about, after years spent tinkering with footballmatch.it. A liceo would have meant years of humanities subjects that, for what I had in mind to do, seemed close to useless. I didn’t choose the technical track because it was a good fit for someone “like me”: I chose it because it was the only place where I’d actually get to study what interested me.

There was one detail I hadn’t accounted for: at that institute, computer science was only taught seriously starting in the third year. The first two years were almost entirely accounting — balance sheets, bookkeeping, the basics of business economics. I’d picked that school specifically to do computer science, and for two years I did something else entirely.

Scrutini: the software that printed every report card

Everything changed in the third year, in 2006. That’s when my school’s principal noticed what I could actually build, and decided to find out how far that went.

The first assignment was “Scrutini,” handed to me and a close friend of mine — the same one I’d go on to share years of study, work, and life with. Scrutini was software for exactly the grading sessions where teachers finalize marks at the end of a term: teachers enter grades, the system produces the reports and prints the actual pagelle — report cards — that go home to parents. We built it in Microsoft Access. Not a glamorous choice, but the right one: a desktop database tool a small school could actually run and maintain, with forms for data entry and a report engine built in, no separate hosting or infrastructure to worry about. Behind the forms, though, there was real programming: we built the report engine in Visual Basic, which I already knew. What mattered wasn’t the technology, though — it was that two sixteen-year-olds had just been handed the software that would produce every student’s official grades. Nobody double-checked that decision for us. It just had to work.

GeCo: double-entry bookkeeping, in Visual Basic

The second project was smaller in scope but had more personality: “GeCo,” short for Gestione Contabilità — accounting management — with a gecko as its icon because the name asked for it. And this is where those two years of accounting, which had felt like wasted time back then, suddenly turned useful: the course included business economics, and a good chunk of those hours were spent on partita doppia — double-entry bookkeeping exercises. GeCo was a Visual Basic tool for exactly that: generating and checking double-entry exercises.

There’s something I didn’t clock at the time: I was building the practice tool for the exact subject I was being taught, in parallel with actually learning it. That loop — learn the domain, then build the tool that teaches it — turned out to be one I’d repeat many times since.

Ambito5: a portal five municipalities ran on

The bigger jump came with Ambito5: a real institutional project, a web portal supporting a formal social-services collaboration between five municipalities — the kind of inter-comune administrative arrangement Italian public services run on, coordinating things like social assistance across towns too small to each staff their own office. This wasn’t a school exercise anymore; it was public infrastructure, and it earned us a scholarship for building it.

It was also our first real requirements-and-architecture job, not just implementation. Five municipalities meant five sets of needs, and someone had to turn that into one coherent system before a single line of code got written. We built it on .NET, with AJAX for the interactive parts — which in those years was still new enough that using it was a deliberate, slightly bleeding-edge choice, not a default.

What it taught me

By the end of those years the pattern was already set: whenever someone handed me a real problem, I’d go build the actual thing rather than just study it. Software a real institution depends on doesn’t come with training wheels — nobody double-checks it for you just because you’re young. Trust gets earned by the work holding up, nothing else.

In 2010, a couple of years after graduating, I went back to that same school — this time as a teacher of programming and web design. First a student, then a teacher.

I didn't want to trade crypto. I wanted to build on it.

Sun, 14 May 2023 00:00:00 GMT

In 2020 I got into cryptocurrencies, not blockchain in any technical sense yet. It was a world I’d always wanted to explore, but for years it had stayed in the background — something I heard about without ever really stepping in. I started the way most people do: buying small amounts on one of the big centralized exchanges, more out of curiosity than conviction. It was there, browsing through the assets on offer, that I kept running into a name that came up more and more often: DeFi.

DeFi pulled me in almost immediately, and not just for the yields. There was an idea underneath it that stuck with me: building freely, without permission, without an intermediary deciding what could or couldn’t be done. A protocol, a contract, rules written into code — and anyone could use it, or build something else on top of it. 2021 made that idea feel almost tangible: it was the year of the bull run, and with it an explosion of projects that seemed to appear every week — aggressive new DeFi protocols, the NFT boom, the first play-to-earn games, the wave (often more promise than substance) of the metaverse. Not everything born in those months made sense, but the pace at which it was born did: something was clearly being built, and anyone who wanted in could get in.

There was something familiar in all of this, even if I didn’t quite see it at the time. In 2001, still a kid, I’d gone from playing a video game to building tools that modified it — from consumer to someone building what other consumers would use. Twenty years later it was happening to me again, just with a different object in my hands: I’d entered the crypto world as a small investor, someone who buys and watches, and I was realizing that the part I actually cared about wasn’t buying — it was understanding how these things get built.

What does it take to build on a blockchain?

So I started studying what it actually meant to build on a blockchain. It was complex, but less than reverse-engineering a video game with no documentation and no organized community to help — here at least there was documentation, fragmented as it often was. I learned the basics: what a blockchain is, what a smart contract is, how a piece of code can live on a distributed network and enforce rules that nobody can unilaterally change once published. Things that forced me to unlearn a few habits from traditional web development, more than I expected going in.

Why Solidity is hard to approach from web2

But the moment I actually tried to get hands-on, I ran into an obstacle I hadn’t expected: Solidity, the language most smart contracts are written in, is not easy to approach coming from web2. It’s not just the syntax. It’s a different way of thinking: every operation has a computational cost you have to calculate and manage — gas, the unit of measure of the Ethereum Virtual Machine — and around that model sit rigid, very specific concepts that a JavaScript developer simply never had to consider. I realized this wasn’t just my own personal struggle: it was a real barrier to entry, one keeping an entire generation of web2 developers, used to a completely different paradigm, out of web3.

Finding Koinos: no ICO, no pre-mine

It was while looking for an alternative that I found Koinos, and it struck me right away as an ethically flawless project. No ICO, no pre-mine: the founding team — coming off an earlier project in another blockchain, which they’d left after a hostile attack on the network — had chosen to build by working for equity, without raising outside capital. A philosophy that felt close to Bitcoin’s original one: using available computational resources without needing dedicated hardware, with a Proof-of-Burn consensus designed to combine the economics of proof-of-work with the efficiency of proof-of-stake. And then there was governance: protocol upgrades happen through a network vote, not a hard fork — Koinos calls itself the most upgradeable blockchain there is, and the fact that it could evolve without splitting in two won me over.

The stack that made me stay

But what actually made me fall for it was the application stack: smart contracts are written in AssemblyScript, a syntax very close to TypeScript, familiar as I already was with JavaScript. The APIs are REST, not the usual opaque RPC endpoints of the blockchain world, and koilib made client-side integration as immediate as working with any other web API. Even the fee model followed the same philosophy of accessibility: no gas to pay on every transaction, but “mana,” a resource that regenerates and that a “payer” can even front on the end user’s behalf. Koinos wasn’t just solving a technical problem — it was deliberately lowering the exact barrier I’d just run into, giving web2 developers immediate access to web3.

I hadn’t written a single line of code on Koinos yet, but I already knew that was the door I’d been looking for. Not the most famous project, not the one with the biggest community or the loudest marketing — simply the one that, out of everything I’d looked at, seemed genuinely built to let people like me in. Sometimes a technology choice isn’t just about specs: it’s recognizing a philosophy you see yourself in.

Building was always the point

Tue, 18 Apr 2023 00:00:00 GMT

Building, not the result

As a kid I didn’t have many toys, and I was a quiet, reflective sort who mostly kept to himself. LEGO was the only toy that mattered. I was fascinated by ancient history, and I’d spend hours flipping through history atlases, staring at ziggurats and pyramids, then rebuilding them piece by piece with thousands of bricks. When I finished — hours later — I’d show my parents, and tear it down a few minutes after. It wasn’t frustration: I felt satisfied, but the result itself barely interested me. What I actually loved was building.

A Pentium in the house, in 1998

In 1998, at nine years old, an encyclopedia on CD-ROM arrived in the mail. Floppy disks were still the norm back then, and a personal computer at home was far from a given — especially in Italy. My father looked at the box and asked the right question: “How do we even look at this? Should we get a computer?” The answer was a Pentium 1, one of the processors that were bringing computers into ordinary households in those years, with plenty of successors still to come over the next decade. I didn’t know it yet, but that machine would become my first real tool.

FIFA arrives, and leaves just as fast

FIFA ’98 showed up for my birthday. Playing it was exciting — FIFA was becoming the PC football game of the era — but the excitement didn’t last: I got bored fast. The following year I got FIFA ’99, and this time the excitement never even arrived. The internet, meanwhile, was a different world: a painfully slow 56k connection, little content, hard to find, and — in Italy at least — used by a small minority of the initiated.

The communities behind the game

I discovered that behind FIFA there were huge online communities, including actual developers. They built patches that updated the original game: team names and lineups after every transfer window, more realistic kits and boots, player faces, new stadiums, and much more. The communities I remember most fondly are Fifamania.it, Fifaonline.it, and Soccergaming.com. I started as a user, downloading patches and installing them, but that wasn’t enough for long — I wanted to understand how they worked. What were those .bin files? How had people made them?

Learning alone, one byte at a time

There was no Stack Overflow, let alone ChatGPT. Information was scarce, and whoever had it tended to guard it jealously instead of sharing it. I taught myself, the hard way, what those files contained and how to modify them — one hex editor session at a time, with nobody around to tell me where to start.

FIFA 2000, ADSL, the first editors

FIFA 2000 arrived along with ADSL, and everything sped up. The internet became accessible to everyone, and information started circulating far more freely. I finally managed to build my first patches using editors that EA Sports itself provided. I remember endless restarts of the game: every patch I broke by mistake would crash everything, and I’d start over. I began producing kits, boots, and player faces, published on the same sites I’d discovered as a user. The happiness was overwhelming: my name was online, and thousands of people were using and appreciating my work.

footballmatch.it, the step up

In 2001 I took the leap: I built my own site, a competitor to the ones I’d been using as a fan — footballmatch.it. I put it together in one sleepless night with my father, using Microsoft FrontPage. At first I did everything with the visual editor, driving myself crazy trying to make it look the same in Internet Explorer and in Mozilla. Then I discovered that underneath that visual editor was plain HTML and CSS, and that writing it by hand was far more fun — and far more reliable — than trusting the WYSIWYG. That was the moment, without my quite realizing it yet, that sealed a pact with my future: I had become a programmer. I put together a team, we shipped free updates every week, and I reached 10,000 unique monthly visitors — a huge number for the era, and even more so for a teenager. Across the community, thousands of people used my work assuming they were dealing with a grown man, maybe with a family of his own. I was just a kid.

The tools before the product

Redoing every texture and every record by hand, in a hex editor, didn’t scale to what we needed. So I started building tools — not as an end in themselves, but because kits, boots, faces and flags all had to be produced at volume for the patches we were actually shipping. A few of the tools that came out of that:

Footballmatch Face Importer 2.0 — imported custom player face textures into the game’s .fsh format, with a live 3D preview of the face and hair mesh before importing.
Footballmatch Player Edit — a fuller editor: face textures, hairstyles, boots, gloves, even shin guards, all through a proper Windows GUI instead of a hex editor.
Footballmatch Flags Importer — swapped team badges and banners, with thumbnail previews of every asset before you committed to importing it.
Footballmatch Shoes Importer — the same idea, scoped to boot textures.

Footballmatch Face Importer 2.0 — the preview was the whole point: see the head before writing it into the game’s texture archive.

None of these tools, though, were really the product: they were the assembly line. The real product was the patch — a complete, installable bundle of updated squads, kits, boots, flags, faces and eventually stadiums, turning a stale FIFA install into something close to the current season.

Footballmatch Player Edit — face, hair, boots, gloves and shin guards, all through dropdowns instead of a hex editor.

The Superpatch on the newsstand

I reached out to Giochi per il mio Computer, one of the best-known PC gaming magazines in Italy at the time, to pitch the Superpatch — the full package that updated FIFA with squads, kits, flags and everything else. It made the newsstand, and millions of Italians saw my name printed on the cover. I was stunned: up to that point, my audience had been a handful of forums. Seeing it land in front of an entire newsstand’s worth of readers was the first time the hobby felt like it might be more than a hobby.

Building, not playing

In the meantime, without quite noticing it, I’d become an all-round editor: 2D graphics for kits and boots, 3D graphics for stadiums and faces, plus the tools to produce all of it at scale. And yet, of all those sleepless nights, not one was spent actually playing a match of FIFA or PES. My mission had never been to play — it was to build. It was that realization, pieced together without my knowing it, that led me — a few years later — to choose my course of study: an experimental computer science program.

My space, my challenges, my memories

Tue, 21 Mar 2023 00:00:00 GMT

I’m someone who needs to build. I like experimenting, getting my hands on things I don’t know, learning something new and seeing how far I can take it — and that’s as true of my work as it is of what I do when nobody asks me to.

What’s been missing is keeping any record of it. The experience stays in my head, or I tell someone about it once, out loud, and that’s where it stops. From here on I’m going to write it down.

Not out of nostalgia. Writing it is useful: to me, because it puts what I’ve done in order and makes it something I can show; to whoever is up against the same problem and is looking for someone who has already been through it; and to anyone following along who wants to know what I’m working on.

How I got here

I taught myself to program long before anyone taught me: taking things apart to see how they were made inside, and putting them back together different. When it came time to choose a school I chose it for that, against the advice of almost everyone around me, and I arrived at university already knowing what I wanted to do with it.

Then it became the job: real clients, other people’s projects, companies, products that keep going for years. Every stage taught me something the one before it couldn’t. Working for someone who pays you isn’t working for yourself, and maintaining something for years isn’t building it.

What never changed is the other half: what I build when nobody asks me to.

What I build when nobody asks me to

There are always two or three things open, outside working hours. Sometimes they come from a problem of my own that nobody has solved the way I’d want; more often from a technology I want to genuinely understand, and the only way I know to understand one is to build something with it that has to work.

That’s where you actually learn, because that’s where choices have a price. Documentation tells you what a tool does; building something real on top of it tells you what it doesn’t do, and what it costs you to find that out late.

Not everything gets anywhere. Some things end up in people’s hands and get used, some stop before that, and some I drop because I’ve learned what I wanted to learn and the thing itself is no longer any use to me. I don’t call those failures: I got what I came for anyway.

What you’ll find here

Accounts of things I actually built, with the technical detail that matters and the results as they went, including the ones that don’t flatter me. A project that didn’t work, explained well, is worth more than a successful one told halfway.

These aren’t tutorials: I’m not trying to teach anyone how to use a tool, and there are better places for that. There’s no thesis to prove either. The subjects will change, because what I work on changes; what stays the same is the angle — a thing that got built, why I built it that way, and what I got out of it.

This is the space to put them in. Starting here.