Abhinav Saxena

From rails to a paved road

2026-06-07T00:00:00+00:00

For years, the most fun I had building anything was on Rails and Phoenix.

Not because of the languages. Because of the feeling. You ran one generator, you got a working app with auth, a database, background jobs, and a deploy story, and then you spent your time on the thing you actually wanted to build. The framework had already made a hundred decisions for you, and most of them were right.

Then I would go back to Python and feel the difference immediately.

Python is the language I reach for most. But for years the honest answer to “how do I structure a real web app in Python” was Django, and Django is excellent at exactly the kind of app it was designed for. FastAPI is where a lot of new energy went, and deservedly so. It is fast, it is typed, the developer experience is lovely. But FastAPI hands you a request router and wishes you luck. Auth, sessions, jobs, deploy, the folder layout, the thing that turns a tutorial into a product - all of that is left as an exercise.

So everyone writes that glue themselves. Badly, usually, and differently every time. I have done it more than once, and did not enjoy it any of the times.

Pave is my attempt to stop writing it.

The pitch is one line: full-stack Python, no React required. You write FastAPI. Pave handles the parts around it - auth, background jobs, an HTMX component kit, a markdown content system, and a deploy pipeline - and it ships your app to a real Linux box with one SSH command.

boring on purpose

The first decision I made was the one most people will argue with, so let me say it plainly. No Docker. No Kubernetes. No Node build step.

I want to be careful here, because this is a preference, not a law. There are good reasons to reach for containers, and if you already run a fleet on Kubernetes, Pave is not asking you to tear it down. But for the app that does not exist yet - the one you are trying to get to its first real user - all of that is ceremony you pay for before you have earned it.

A handful of long-lived Python processes supervised by systemd will carry most apps a lot further than people admit. So that is what Pave does. It ships Python files to an Ubuntu host and runs them under systemd, behind Nginx, served by Gunicorn. Migrations with Alembic. The ORM is SQLAlchemy 2.0, async. Deploy is Fabric.

The whole thing is the kind of stack a sysadmin in 2010 would recognize, and I mean that as the highest compliment I can give infrastructure. It is boring. Boring things do not page you at 2am.

If you have heard “you’ll regret not using Docker” enough times to half-believe it, here is the honest trade-off. The day you genuinely outgrow one box, you will have to do some work to move. But there is no Pave-specific lock-in to undo first, and you will be doing that work with real traffic and real numbers in front of you, instead of guessing about scale you do not have yet.

the job queue problem

Background jobs are where the boring-infra promise usually breaks.

You want to send a verification email without making the user wait for it. Easy enough. So you reach for a job queue. The standard answer in Python is Celery, and Celery wants Redis or RabbitMQ. Now your “one box, one database” app has grown a second piece of infrastructure whose only job is to hold a list of things to do later.

You already have a database that is very good at holding lists of things. It is right there. It is Postgres.

So Pave’s job queue, Soniq, runs on Postgres. No Redis, no broker, no new daemon to babysit. It does the unglamorous things a queue needs to do - retries, a worker you run with one command - and it does them against the database you were already running. Two real jobs ship with Pave as worked examples, not toys: processing a webhook, and sending that verification email off the request path.

I wrote Soniq as its own library because I kept wanting it in projects that had nothing to do with Pave. But this is the project where it earns its keep. One fewer moving part is not a small thing. It is the whole point.

no React, and I mean it

The other place I dug in is the frontend.

I have watched the React tax get paid for more than a decade, on teams I led that shipped React and React Native. My own frontend JavaScript was Backbone, back when that was the reasonable choice. So for this class of app I am opting out, and the reflex I am opting out of is reaching for a separate frontend build, a Node toolchain, and a single-page app for what is fundamentally a few forms and an admin dashboard. You are now running two applications that have to agree with each other, and a build step that breaks in its own special ways.

Pave renders on the server. The components are Jinja2 templates, made interactive with HTMX and a little Alpine.js, styled with Tailwind. Every component traces back to one set of design tokens, so the buttons match the forms match the cards without anyone freelancing a hex code at midnight. Dark by default, with a real light theme, responsive down to a phone, all from the same templates. No separate mobile build.

There is no package.json. Tailwind runs from a standalone binary. I will admit I was a little smug the first time I deleted node_modules from a project and nothing broke. t This will not suit everyone, and the README says so. If you are building a rich SPA, the HTMX kit will fight you, and you should use something built for that fight. But for the enormous category of apps that are mostly server-rendered pages with some interactivity, all of that JavaScript machinery was solving a problem you did not have.

deploy in one line

Here is the part I am most quietly proud of.

Once a server is prepared, you deploy with fab production deploy. That one command validates your environment schema, builds the CSS, runs migrations and tests and the type check, snapshots a new release on the server, flips a symlink to make it live atomically, restarts the systemd service, and then probes /health. If the health check fails, it rolls back on its own before the command even returns to your prompt.

That last sentence is the one that matters. The deploys that hurt are not the ones that fail loudly. They are the ones that half-succeed and leave you SSHed into a box at midnight trying to remember what the last good state was. The release-directory model and the automatic rollback exist so that a bad deploy is a non-event. The old version never went anywhere. You flip back.

That is the part Python never gave me. Not the speed of the first deploy, the calm of every one after it. Rails and Phoenix made deploying boring years ago, and boring is exactly what you want from the thing that puts your work in front of people. This is me trying to make it boring in Python.

what this actually is

Pave is not a framework. It is a template - a starting point you clone, with the boring decisions already made and wired together correctly, so you can delete the ones you disagree with instead of assembling everything from nothing.

It is pre-1.0, so the API may still shift. The name comes from the obvious place: you pave a path before you walk it. Pave lays the production surface down first, then you build on top.

I built it because I wanted, in Python, the absence of a hundred small fights before the first real line of my own code. Not the magic. Just that.

It is MIT licensed and on GitHub at github.com/abhinavs/pave. Fork it, ship it, change the name on the tin.

I am going back to building the app now. Which, I suppose, was the entire idea.

Introducing sqlalchemy-annotate

2026-05-19T00:00:00+00:00

I have released sqlalchemy-annotate, a small command-line tool that keeps a schema summary at the top of every SQLAlchemy model file.

When you read a SQLAlchemy model, the Python tells you which attributes exist but not what the database does with them. Whether a column is nullable, how long a string can be, which columns are indexed, what the foreign keys point at - none of that is visible in the model. You have to open the migration or connect to the database to find out. Rails has addressed this for years with annotate_models. This tool brings the same idea to modern SQLAlchemy 2.x and Alembic projects.

It maintains a block like this, kept in sync with your actual metadata:

# == Schema Information
#
# Table name: users
#
# id         : integer, primary key
# email      : varchar, not null
# created_at : timestamp
#
# Indexes
#   ix_users_email (email) UNIQUE
#
# == End Schema Information

There are three commands. sqlalchemy-annotate generate writes or updates the block, typically run after a migration. sqlalchemy-annotate check exits non-zero when a model has drifted from its comment, which makes it suitable as a CI gate or pre-commit hook. sqlalchemy-annotate remove strips every block.

Two design decisions are worth stating directly.

First, it never connects to a database. The schema is read from Base.metadata. If you pass a connection URL, only its dialect is used, so types compile correctly offline, and the URL is then discarded. Annotating a file does not require database credentials.

Second, it does not rewrite files with regular expressions. All edits go through a single libcst transformer, so imports, comments, blank lines and formatting outside the marked block are preserved exactly. Running generate twice produces no further change, which is what makes check reliable.

One trade-off should be clear before you adopt it. The tool imports your model package, in the same way pytest and Alembic do. If importing your models triggers side effects, those will run. For most projects this is not an issue, but it is worth knowing.

Installation is from PyPI:

pip install sqlalchemy-annotate

The source, full documentation and configuration options are at github.com/abhinavs/sqlalchemy-annotate. The tool is intentionally small. The schema already exists in your metadata; this simply puts it where the person reading the model can see it.

Introducing Soniq

2026-05-03T00:00:00+00:00

Soniq - the job queue for people who don’t want another job queue

I’ve been rebuilding the same job scheduler since 2011.

The first version used MongoDB. The core trick was find_and_modify – MongoDB’s atomic operation that lets you fetch a document and update it in a single step. Claim a job before anyone else does, or don’t claim it at all. No double processing. I ran a hosted multi-tenant version for two or three years. People used it. It mostly worked.

Then I moved on. But the problem stayed with me.

Over the years I’ve used most of the serious job queue libraries. Resque and Sidekiq in Ruby. RQ in Python. Each one solved the core problem well enough. Each one also required something extra: Redis, a specific runtime, or an entirely different programming model. The closest thing to what I wanted was Oban in Elixir – PostgreSQL-backed, no broker, no Redis. But I was building in Python.

I kept thinking about the infra cost. Not the money, but the maintenance. Every component you add to a production system is something that can fail, something you have to monitor, something you have to explain to whoever reads your deploy config next. Redis is not expensive to run. But Redis is one more thing to run.

I believe in boring infrastructure. The best infra component is usually the one you don’t add. Most Python applications already run PostgreSQL. Your jobs can too. It’s already there. It’s already backed up. You already understand it.

Last year I built Fastjob. PostgreSQL as the datastore, transactional enqueue, dashboard, webhooks, scheduler. Feature-rich. I’m also willing to admit it became complicated. I added things before the core was solid, and eventually the project became what I was trying to avoid: one more thing to manage.

In January this year I started again, on weekends. I call it Soniq.

Soniq is a batteries-included async job queue for Python. The only infrastructure dependency is PostgreSQL.

No Redis cluster. No separate broker. No operational split brain between your app state and your queue state.

If your application already depends on PostgreSQL, your queue can too.

What that gives you that most queues don’t:

Transactional enqueue. A job is either committed or it isn’t. A user signs up, the database transaction commits, the welcome email job commits in the same transaction - there is no gap where one succeeds and the other disappears.
Built-in scheduler and recurring jobs
Built-in dashboard, no paid tier
Prometheus metrics out of the box

Most applications don’t need a dedicated distributed queue cluster just to send emails and process background tasks. Soniq is built for that majority - teams that need reliability and operational simplicity more than extreme throughput.

If you’re already running PostgreSQL and don’t want another broker, Soniq is ready - MIT licensed, batteries included.

Terminal is having a second life

2026-04-22T00:00:00+00:00

In 2001 I started with telnet.

I was a student at BITS Pilani and telnet was simply how you got to the internet. I used Pine to send email. Lynx to browse. The world came to me as text on a black screen and I thought nothing of it. It was just how computers worked.

Then GUIs got faster, browsers got richer, and the terminal slowly became the thing you minimised and forgot about. Developers kept using it. Everyone else moved on.

I kept using it too. At Yahoo in 2005, the terminal was where the real work happened. I was working on a big data processing pipeline and my QA system was a pipe. Feed the output through grep, filter it with cut, join datasets with join, scan compressed logs with zcat and zgrep. Each tool did one thing. The intelligence lived in how you chained them. And if something went wrong, the tool that failed said so. The pipeline stopped. You knew exactly where to look.

It felt powerful then. I didn’t fully understand why.

I’ve spent the last two months building vrk – Unix-style tools for LLM pipelines – and the Yahoo pipeline keeps coming back to me.

Not as nostalgia. As explanation.

AI agents need to do things: fetch a URL, check it fits within a model’s token limit, redact secrets, call the model, validate the output. The problem is what happens when something goes wrong. A model doesn’t crash on bad input. It guesses. It fills in what it didn’t see with text that sounds right. You find out three steps later, or you don’t find out at all.

Agents, like the shell, are probabilistic at the edges but need determinism at the joints. The pipes are the joints.

That’s the insight I kept arriving at while building vrk. The contract that made grep useful – stdin in, stdout out, exit loudly on failure – turns out to be exactly the contract an agent pipeline needs.

I started using the terminal because it was all there was. I keep using it because nothing that came after improved on the pipe.

AI doesn’t have a Moore’s Law

2026-04-21T00:00:00+00:00

It has something harder to name, and harder to ignore.

In January 2023, two months after ChatGPT launched, I started building annexr. I thought I was late. Three years later, I realize I was early.

That mismatch - feeling late while being early - is the signature experience of building in AI right now. It has nothing to do with individual foresight. It has everything to do with how progress in this field compounds.

One curve vs. many

Moore’s Law was one curve: transistor density doubling on a predictable clock. Clean, measurable, predictive. And even that wasn’t a natural law. At Intel, it was a goal the company worked hard to keep. When physics pushed back, they adapted.

AI progress isn’t like that. There is no single company shepherding a single metric. It is a bundle of partially correlated curves: compute, algorithms, inference cost, hardware efficiency, and how long AI systems can work without a human in the loop.

What makes this unusual is that two different kinds of improvement run at once.

Moore’s Law runs on the calendar. Time passes, chips improve.
Wright’s Law runs on cumulative work done. The more you make something, the cheaper it gets.

In AI, both are active simultaneously. That coupling is what makes progress feel relentless. The decoupling is what produces the walls.

The curves, briefly

Four numbers worth knowing:

Training compute has grown roughly 4.5x per year since 2010
Algorithmic efficiency improves separately: the same capability now takes about 3x less compute each year
Inference cost has fallen by orders of magnitude, anywhere from 9x to 900x per year depending on the task
Agent task horizon - how long an AI can work before needing help - has been doubling roughly every four months

These aren’t independent. Falling inference cost enables more compute at inference time, which improves reasoning, which pushes the task-horizon curve further, until it hits a wall.

Where the curves break

The logarithmic trap. Benchmark performance scales roughly with the log of compute. Each doubling of performance costs far more than a doubling of the training budget. The current bet is test-time compute, shifting spend from training to reasoning during use. Whether the economics hold at scale is still open.

The data wall. High-quality human text is largely exhausted at frontier training scales. Synthetic data and model self-play have kept the curve alive in narrow domains like math and code. Whether they generalize is the open question.

The reliability gap. Task horizon measures length, not robustness. An agent that can work for a hundred hours but has a 1% chance of failure each hour is unusable for anything high-stakes. Reliability data lags capability data badly, which is itself a signal about what the industry has optimized for.

The power grid. Moore’s Law was about density, doing more in the same space. AI scaling is about absolute magnitude. Bigger clusters need more gigawatts. Power grids follow civil engineering timelines, not silicon ones.

The institutional curve, which is essentially flat. Compliance, procurement, security review, change management: none of these scale exponentially. The AI curves are steep. The institutional curve is close to flat.

What this means practically

The line of what is worth building keeps moving. Something too expensive or too unreliable last quarter can make sense this quarter. Something that barely works today can be boring infrastructure a year from now.

But the problems blocking real adoption have shifted. They are no longer mostly about capability. They are about reliability, power capacity, data quality, and how long it takes large organizations to trust new systems.

Most of the interesting work for the rest of this decade sits in closing the gap between a steep capability curve and a nearly flat institutional one. Not pushing the frontier further. Getting organizations to the threshold.

That is a harder problem than making the models smarter. It is also a more tractable one.

If you want the backstory on how these three threads came together, I wrote about that separately: The AI moment was seventy years in the making.

Sources and further reading

The AI moment was seventy years in the making

2026-04-21T00:00:00+00:00

Three independent lines of work. Each took decades. None waited for the others.

In 1947, Bell Labs invented the transistor. A year later, Claude Shannon, working in the same building, published a paper on the mathematics of communication. Neither discovery knew what it was starting.

What we call “the AI moment” is not one thing. It is the convergence of three threads, each of which matured on its own schedule, developed independently of the others.

The first thread: a language for information itself

In 1948, Claude Shannon published A Mathematical Theory of Communication. He was trying to solve a practical problem: how do you transmit a signal reliably over a noisy channel?

What he produced was something much larger. A mathematical language for information itself. Entropy. Compression. Channel capacity. The idea that meaning could be separated from medium, quantified, and reasoned about formally.

It laid the mathematical foundation that machine learning, deep learning, and modern AI are built on. Every token prediction in a modern language model is a descendant of that paper. Shannon did not know he was laying the foundation for AI. He was solving a telephone problem.

The second thread: hardware that could actually run the math

The transistor was invented in 1947. Seven decades of shrinking, specializing, and parallelizing followed.

The moment hardware met modern AI visibly was 2012. A team at the University of Toronto trained a neural network called AlexNet on GPUs and won ImageNet by a margin that made everyone in the field stop and recalculate. GPUs were designed for graphics. They turned out to be the right shape for deep learning: massively parallel, fast at matrix operations, cheap enough to experiment with.

Google followed with custom silicon. TPUs arrived in 2016, designed specifically for neural network workloads. The physical substrate that made scale possible was now being purpose-built for it.

The third thread: an architecture that changed everything

In June 2017, a team at Google published Attention Is All You Need. The paper proposed the Transformer: a new architecture that dropped recurrence entirely and used attention mechanisms to process sequences in parallel.

Google understood it well enough to ship BERT in 2018 and T5 in 2019. What it did not do was productize at the pace the architecture deserved. The constraint was probably search revenue. If your core business is people finding answers on web pages, a model that answers questions directly is a threat you have to manage carefully.

OpenAI had no such constraint. GPT-2 in 2019. GPT-3 in 2020. The technical trajectory was visible to anyone watching. The three threads had already crossed.

What actually happened in 2022

By the time ChatGPT launched in November 2022, nothing fundamental had changed in the underlying technology. The models were better, but the architecture, the hardware, the training approach: all of it had been in place for years.

What changed was the interface. A chat box that anyone could use. No API key. No prompting knowledge required. The intersection of seventy years of work was suddenly in front of everyone with an internet connection.

The rupture of 2022 was not a moment of invention. It was a moment of attention.

The three threads took different amounts of time. Shannon’s 1948 paper needed sixty years of hardware before it could run at scale. The Transformer needed less than five years to go from research paper to the technology inside a product used by a hundred million people.

The gap between discovery and deployment has been shrinking the whole time. That, more than any single breakthrough, is what makes the current moment feel different from the ones before it.

The follow-on question, where those curves are headed and where they break, is what I wrote about in AI doesn’t have a Moore’s Law.

On learning new things without old baggage

2026-02-27T00:00:00+00:00

Whenever I’m in Bangalore, I still default to Hindi.

I lived there for ~6 years, but I never really learned Kannada. The moment someone spoke to me, my brain looked for a Hindi equivalent and came up short.

Kids don’t do this. A child learning a new language maps words to real things - the sound and the reality arrive together.

Adults, on the other hand, map words to other words. Duolingo does this too - every lesson maps the new language onto the one you already know. No wonder so few learners ever hold a real conversation.

The same pattern shows up when engineers learn new programming paradigms.

I learned C first. Then tried jumping to Java. Object-oriented programming felt alien - I kept asking “what’s the C equivalent of this?” and half the time, there wasn’t one. I gave up, took a detour through Perl, and arrived at objects gradually. The direct path didn’t work because I was carrying the old map into new territory.

This is exactly what’s happening with AI right now.

Most people learn AI tools by mapping them onto familiar things. ChatGPT is like Google, but better. Copilot is like autocomplete, but smarter. An agent is like a junior employee you can delegate to.

These analogies help you start. They also limit how far you go.

I’ll be honest - I catch myself doing this too. Twenty years in tech means twenty years of mental models that I keep reaching for, even when they don’t quite fit.

The people I’ve seen get the most out of AI are often the ones without that baggage. AI-native - they didn’t learn to Google before ChatGPT, didn’t debug by posting on Stack Overflow before Claude Code. They’re not translating. They’re just using it for what it is.

That model doesn’t come from reading about AI. It comes from approaching it with fresh eyes, not a map drawn from somewhere else.

The ceiling isn’t the tool. It’s the map you bring to it. And I’m still drawing a new one.

Microservices are a people decision, not a technical one.

2026-02-21T00:00:00+00:00

I’ve seen companies running thirty microservices with a twelve-person engineering team.

Nobody questions it. Microservices have become the default answer to “how should we structure our system?” - adopted for the wrong reasons, creating new problems while the old ones quietly follow along.

My unpopular opinion - microservices are mostly a way to organise teams, not to scale systems. And most companies that adopt them are doing it backwards.

The actual value

Mel Conway observed in 1967 that organisations design systems that mirror their own communication structure. Three teams building together produce a three-part system - whether that’s the right architecture or not.

This is the real case for microservices. When the payments team owns the payments service end to end - builds it, deploys it, fixes it at 2am - they stop waiting on five other teams to ship a change. Reduced coordination. Clearer ownership. That’s worth something.

But it only works when the split is real. One team, one thing, completely.

Most companies don’t do it this way.

The mistake

The most common thing I’ve seen: splitting code without splitting ownership.

You have a user service, an auth service, an account service. They all touch the same user data. Any change to how a user is represented requires coordinating across three teams. The services are separate. The work isn’t.

The mess hasn’t gone away. It’s moved into the gaps between services.

And when something breaks, it breaks across multiple services at once. A bug that takes an hour to find in a monolith takes a day when you’re tracing requests through four systems and reading logs from three different places.

Every service also needs its own deployment pipeline, its own monitoring, its own on-call rotation. At Netflix this overhead is justified. At a 20-person startup it’s a tax on every engineer, every day. I’ve watched teams ship at half their previous speed after going microservices - not because the technology was wrong, but because the team wasn’t big enough to carry the weight.

Why this matters more now

AI coding agents change the calculation further.

An agent can hold an entire codebase in context and make changes across multiple modules without getting lost. What’s harder is reasoning across service boundaries - different repositories, different API contracts, different deployment pipelines. Every boundary you add is friction for the agent.

A modular monolith, where code is well-structured but lives in one place, is significantly easier for an agent to work with. I think this is where most teams will land as AI-assisted development matures - not because microservices are wrong, but because the tool that’s transforming how we build software works best with fewer walls.

When to actually use them

Microservices make sense when teams are genuinely separate - different product lines, different shipping cadences, minimal coordination needed. They make sense when one part of your system has dramatically different scaling needs from the rest. At real scale, the operational overhead is worth it.

The mistake is using them as the starting point. Start with a well-structured monolith. Split when you have a specific reason to split, not because microservices sound like the professional choice.

The architecture should follow the team structure. Most of the time, the team is smaller than the architecture suggests.

addy - like apt install, but for people

2025-07-21T00:00:00+00:00

Every company has a version of this problem.

A new engineer joins. Someone sends a Slack message to whoever manages the servers. That person sets up access when they find the time - creating accounts, copying keys, updating permission files. All done by hand, all from memory. When that engineer leaves, most of this gets undone. Some of it doesn’t - old access quietly lingers on servers nobody thinks to check.

Some teams give up and share a common deploy or ubuntu user. One SSH key, everyone uses it. Fast to set up, impossible to audit. When something breaks in production - or something gets deleted - you have no idea who was logged in. The logs say ubuntu. That’s where the investigation ends.

The drift nobody notices

The manual approach creates drift quietly. Keys that should have been removed are still there. A contractor who left six months ago can still log in. Nobody knows exactly who has access to what because it lives scattered across the configuration of individual servers, not in any one place you can actually look at.

You only find out how bad it is during a breach, an audit, or a compliance review.

Where the idea came from

I worked at Yahoo from 2005 to 2007. One of the internal tools we used was yinst - a package manager built for Yahoo’s massive server fleet. Among other things, it handled adding and removing users across servers. One command, right setup, clean removal.

I didn’t think much of it at the time. That was just how things worked at Yahoo.

Years later, building and managing infrastructure at smaller companies, I kept noticing the absence of it. The manual approach isn’t wrong exactly - it works fine when the team is small and careful. But it doesn’t scale with the team, and it has no memory. When someone leaves or an audit arrives, you’re reconstructing history from Slack messages and gut feel.

addy is my attempt to bring that same idea - one command, predictable outcome, Git as the record - to teams that don’t have a hundred infra engineers to build it from scratch.

What addy does

addy treats server access like a package. Your team’s SSH public keys live in a Git repository. addy reads from that repository and applies changes to your server.

sudo addy install user/alice   # creates Linux user, installs SSH key
sudo addy install sudo/alice   # grants passwordless sudo
sudo addy remove sudo/alice    # revokes sudo
sudo addy remove user/alice    # removes access entirely

No database. No service to run. No web interface to maintain. Just a Git repo and simple commands.

When someone joins, you add their public key to the repo and run one command. When they leave, you remove the key and run one command. Their access is gone - cleanly, completely, verifiably. No shared users. No drift.

Why Git is the right place for this

Git gives you two things that matter here.

The first is workflow. Instead of sharing public keys over Slack and hoping someone copies them correctly, engineers open a pull request to add their key to the repository. The team can review it, the change is visible, and there’s a clear record of when it was merged.

The second is audit trail. Every key addition and removal is a commit. When a compliance team asks “show me every access change in the last six months,” you have an answer - not a pile of Slack threads to go through.

The actual granting of access - creating the user on the server, installing the key, updating permissions - still happens through addy commands. That part isn’t automatic. But because the keys live in Git, the record of who should have access is always in one place, versioned, and reviewable.

The setup

pip install addy

sudo addy config set git-repo git@github.com:your-org/ssh-keys.git
sudo addy install user/alice

Your key repository needs one thing: a users/ directory with .pub files named after each person.

users/
  alice.pub
  bob.pub
  charlie.pub

addy handles creating the Linux user, installing the key to the right location, setting correct file permissions, and validating the key format before doing any of it. For sudo access, it writes a sudoers file and validates it with visudo - so a malformed entry doesn’t accidentally lock you out.

Who this is for

Teams of 5 to 50 people. Big enough to have real access management overhead. Small enough that nobody has built internal tooling for it yet.

If you’re managing server access through Slack messages and shared users, addy is worth an hour of your time.

The alternative is finding out - during an audit or after an incident - that you don’t actually know who has access to what, and no log to help you figure it out.

github.com/abhinavs/addy

Notes on CBDC

2022-10-09T00:00:00+00:00

RBI has recently published a concept note on Central Bank’s Digital Currency (CBDC) - it is available to read here.

I glanced through it and found it pretty interesting. At a personal level, I’m quite hopeful that a well-implemented CBDC can marry the benefits of cash with current pseudo-digital money.

Why CBDC

At the moment ~3% of GDP is spent on printing, distributing, and securely storing cash. Moreover, India has around 15-30% of its GDP as a shadow economy (not all of the shadow economy is illegal, but much of it is)

Digital money in its current form (credit card, UPI) has too many entities in the middle to solve for trust. As a result, these entities charge ~2% of the transaction cost from the merchant (which essentially gets passed to customers)

I also believe, a well-implemented CBDC also has a shot to replace USD as the reserve currency of the world. China has already made some progress in implementing digital Yuan (eCNY) - AFAIK, it is primarily targeting transactions between banks (rightfully so)

China’s progress is one of the key reasons why India and RBI are also so keen on CBDC

CBDC & its implementation

Introducing CBDC should not mean that banks lose their relevance, however, it should mean they do high-order things more efficiently. As an example, they should still be the ones doing KYC, however, their recon & settlement process should be way more efficient because of CBDC.

RBI’s concept note on CBDC distinguishes between retail (CBDC-R) and inter-banking entities (CBDC-W) and their respective implementation details.

I think,

CBDC can be implemented without using blockchain and yet can be distributed with no single point of failure (think about how SSL/HTTPS certificates work)
Direct benefit transfer (DBT) scheme launched by the govt could be more efficient with smart CBDC

TODO: update with the design I think can work without blockchain