Taking Back Our Votes: Why We Must Move Voter Lists from Secret Servers to Open Technology

Date: 19-10-2026

Imagine a giant, master notebook that contains the name, address, and identity of every single voter in the country. Now, imagine that this notebook is kept in a single, locked room. Only one group of people has the key, and only they are allowed to hold the pen to add or erase names.

This is what a centralized server is. When it comes to something as critical as our voter lists, putting all our trust in a single, centralized server controlled by the Election Commission of India (ECI) is a dangerous game.

Here is why we need to rethink how our election data is stored, who controls it, and how modern technology can bring true, undeniable transparency to our democracy.

Centralization of SIR

The Special Intensive Revision (SIR) of voter rolls in India has been centralized, a shift that has sparked significant legal and political controversy.

• Process Centralization: The Election Commission of India (ECI) utilized centralized software to generate notices and flag “logical discrepancies” against historical rolls from 2002–2005, overriding the traditional decentralized role of local Electoral Registration Officers (EROs) who are statutorily empowered to make inclusion/exclusion decisions.
• Scale of Deletion: This centralized digital purge has resulted in the removal of over 130 million names from draft rolls across multiple states, with critics arguing the opaque algorithms disproportionately excluded eligible voters, particularly women and minorities.
• Internal Dissent: Reports in late 2026 revealed internal dissent within the ECI, with commissioners warning against the “gradual centralization” of the database and the unilateral decisions made by the Chief Election Commissioner without consensus.

The Problem with the “Master Server”

When the ECI manages voter rolls on a centralized server, that single server holds absolute power. The authority controlling the server has the ability to add or delete voters at their own whim.

If a name is quietly removed from the master server, the citizen might not know until they show up at the polling booth and are turned away. Because the server is centralized, there is no easy way for the public to independently verify if the “master list” has been secretly tampered with. We are forced to blindly trust the system.

The Illusion of Transparency: Why PDFs Aren’t Enough

To provide transparency, the ECI often releases the voter lists as massive PDF files. But a PDF is not true transparency.

• A PDF is just a digital photograph of the data at one specific second in time.
• It is incredibly heavy, hard to search, and impossible for a computer program to easily read.
• If the central server is updated the very next day, the PDF is instantly outdated.

We don’t just need to see the data; we need to be able to interact with it and verify it in real-time.

The Solution: Open APIs for Civil Society

Instead of handing out massive PDF books, the voter list needs to be open access through APIs (Application Programming Interfaces).

Think of an API as a digital window. Instead of downloading a 10,000-page PDF, an API allows a computer from a local NGO, a news organization, or a civil society group to ask a specific question and get an instant, machine-readable answer.

• Example: An NGO’s computer can ask the API, “Show me all registered voters in Booth Number 45 of Ward 12,” and instantly receive a neat, verifiable list.

When APIs are open, thousands of independent organizations can constantly cross-check the data. If a centralized authority tries to silently delete voters in a specific neighborhood, civil society algorithms will instantly flag the missing names. Open APIs turn transparency from a “once-a-year PDF dump” into a continuous, real-time public audit.

The Paradigm Shift: One Booth Level Officer (BLO), One Database

To build a system where voter data is open, fast, and impossible for a single central authority to secretly manipulate, we must break the centralized monolith. We do this by shifting the power to the Booth Level Officer (BLO)—the local government official or teacher responsible for maintaining the voter roll of a specific, small geographic area (a polling booth).

The Golden Rule of Decentralized Elections: Every single BLO must have their own dedicated Turso database instance and their own NextJs/Dioxus software instance, hosted independently.

Instead of one giant database for the whole country, we create thousands of small, independent digital filing cabinets—one for each BLO’s jurisdiction.

Turso: The “Database Per Tenant” Revolution

The Many-Database Architecture: Should You Give Every Tenant Their Own Database?

This is where Turso changes the game. In the old centralized way, all data was thrown into one giant pool, separated only by invisible software rules. Turso uses a concept called “Database per Tenant.”

In our system, the “tenant” is the individual Booth Level Officer (or their specific polling booth). By giving each BLO their own dedicated Turso database, we unlock massive, structural benefits:

1. Isolation is Structural Instead of mixing every voter in the country into one giant pool and hoping the software rules keep them safe, the data is physically separated into different vaults. The walls between the data are made of brick, not just drawn with a pencil. If the central server is compromised, or if there is a software bug in one area, the BLO’s local database remains completely safe and untouched.

2. Safe and Easy Backups Backing up or restoring one customer (in this case, one BLO’s jurisdiction) touches only one database. If a BLO needs to restore their voter list to a previous state to fix an error, it only touches their own vault. There is zero risk of accidentally corrupting or rolling back the entire country’s voter data at once.

3. Clean Deletions Deleting a customer is as simple as dropping a database. If a polling booth is dissolved, merged, or a BLO’s specific dataset needs to be completely wiped and reset, you simply delete that single database vault. No complex, risky code is required, and there is no chance of accidentally deleting someone else’s data.

4. Offline-first by design. Voter verification workers can keep working in areas with poor or no connectivity. Every verification is saved to the device’s local database right away, so no work is lost. When a connection returns, the app syncs all pending changes to the server automatically.

5. Data Residency is Solved by Geography Laws often dictate that certain data must stay within specific physical borders. Because each BLO has their own Turso instance, data residency comes down to simply choosing which region you place that specific database in. If a state law says voter data for Kerala must stay on servers in South India, you just place that specific BLO’s Turso database in a South Indian data center. It is as simple as choosing a physical address for a filing cabinet.

NextJs or Dioxus: The Fast, Reliable Public Face

Having a secure, decentralized database (Turso) and open data windows (APIs) is only half the battle. The BLOs, the public, and civil society need a way to actually see and use this data without the website crashing when millions of people log in during election season. This is where NextJs or Dioxus come in.

• NextJs (The Interactive Dashboard): NextJs is a technology used to build the “face” of the website. It creates a smart, interactive dashboard. When a citizen or a BLO types in a voter ID to check their status, NextJs updates the screen instantly without having to reload the whole webpage. It makes checking your voter status as easy and smooth as using a modern smartphone app.

Drizzle with Turso

• Dioxus (The Heavy Lifter): Dioxus is a super-fast, highly secure engine built in the background. When millions of citizens try to check their voting status on the morning of the election, centralized servers usually crash under the pressure. Dioxus is designed to build and deliver these web pages lightning-fast, ensuring the BLO’s portal never slows down, even under massive traffic.

Toasty now fully supports Turso

Android and desktop apps can be built with minimal effort using Dioxus or Tauri if you are using Next.js.

Deployment - Serverless vs. Docker Containers

Because every BLO has its own NextJs and Turso instance, you have ultimate flexibility in how you host them.

All source code must be open-source for independent security audits. Open-source code also removes the technical burden of independent server hosting from the BLOs.

Option A: Serverless Hosting (Fly.io / Vercel / AWS Lambda)

For maximum edge distribution, host each BLO as a serverless function.

• How it works: You deploy the Dioxus/ NextJs a serverless provider.
• Turso Integration: Turso is perfectly suited for serverless because SQLite doesn’t require a persistent connection pool. The BLO opens a connection to its Turso DB only when a request comes in, eliminating cold-start database latency.
• Pros: Zero idle costs, auto-scaling to zero, global edge deployment.

Option B: Docker Container Hosting (Kubernetes / ECS)

If your BLOs require heavy, persistent background processing (e.g., generating massive PDF invoices), Docker containers are better.

• How it works: Each BLO is packaged into its own Docker image containing the Dioxus binary and the NextJs static assets.
• Orchestration: You use Kubernetes or Docker Swarm. The BLO gets its own Deployment and Service.
• Turso Integration: The Docker container mounts the Turso edge-synced local cache, ensuring microsecond read latencies while writes are asynchronously synced to the Turso cloud cluster.
• Pros: Predictable performance, no cold starts, full control over the runtime environment.

A New Vision for Democratic Tech

Technology is not neutral; the way we build our digital infrastructure dictates who holds power.

As long as voter lists are kept on centralized servers and released as static PDFs, the public is forced to blindly trust the central authority holding the keys. But by moving to an open, decentralized model, we change the balance of power.

By using Turso to give every Booth Level Officer their own structurally isolated database, APIs to let civil society constantly audit the rolls, and NextJs/Dioxus to provide a fast, crash-proof experience for the citizens, we can build an election system that is truly transparent and tamper-proof.

Democracy belongs to the people, and it is managed on the ground by the Booth Level Officers. It’s time our digital infrastructure reflects that.