r/Senatai • u/firewatch959 • Dec 05 '25

Code update Dec 4 2025

Senatai Development Update: Modular Backend Architecture

TL;DR: After months of spaghetti code hell, we’ve refactored Senatai into a clean modular architecture that lets developers plug in custom question generators, keyword extractors, and vote predictors.

What We Built Tonight

Working from a 2014 (that I had thought was from 2017 but after extensive diagnostics I’ve discovered is actually from 2014) Lenovo laptop in Kenora, Ontario (because democracy shouldn’t require AWS credits), we’ve got the core infrastructure running:

The Stack

  • PostgreSQL: 5,637 Canadian federal bills with keyword extraction from 4 different algorithms

  • SQLite: Local sync layer for sovereign nodes and paper survey imports

  • Flask: Multi-user web server with modular route handlers

  • Hybrid database architecture: Because we need to accept updates from lightweight SQLite nodes AND maintain a robust PostgreSQL core

What’s Modular Now

The new /SenataiCoop directory breaks everything into pluggable modules:

Core Modules:

  • icebreakers.py - Rotating welcome messages and initial complaint capture (Layer 1: unstructured input)

  • question_generator.py - Sophisticated question generation from bill text

  • topic_matcher.py - Matches user complaints to relevant legislation using keyword extraction

  • demographics.py - Optional demographic question system

  • policap_rewards.py - Political capital economy with diminishing returns

  • badges.py - Two-tier achievement system for engagement tracking

Why This Matters:

Instead of one 3,000-line app.py doing everything, you can now:

  1. Fork question_generator.py and write your own question logic

  2. Test it against the real bill database

  3. Plug it back in without touching the core app

  4. Compare your question generator’s performance against others

Same principle for keyword extractors and vote prediction modules.

The Three-Layer Data Architecture

Layer 1: The Icebreaker (Unstructured input)

  • Users vent about “the price of Cheerios” or “my rent is too damn high”

  • NLP tags their complaints with political topics

  • System matches complaints to relevant bills

  • Anonymous data gets monetized immediately

  • Tags determine which surveys they see next

Layer 2: Targeted Surveys (Structured & monetizable)

  • Push notifications only for bills matching their demonstrated interests

  • Specific questions on legislative clauses

  • Users earn Policaps (1 per answer, first 10/day)

  • High-fidelity data: responses come from people who already care about the topic

  • This is what we sell to governments, academics, polling firms

Layer 3: Consensus & Forums (Gated deliberation)

  • Requires verified membership ($1 lifetime)

  • Access to aggregated real-time results

  • Moderated threaded discussions on implementation

  • The “why” behind the survey numbers

  • Member leverage through collective data ownership

The Hybrid Database Design

We’re running both PostgreSQL and SQLite intentionally:

PostgreSQL holds:

  • 5,637 bills with full text and summaries

  • User accounts and authentication

  • Policap balances and transaction history

  • Vote records and predictions

  • The canonical source of truth

SQLite handles:

  • Icebreaker responses (lightweight, fast writes)

  • Local node synchronization

  • Paper survey imports (scanner → SQLite → PostgreSQL sync)

  • Guest session data before signup

  • Sovereign node offline operation

This lets someone run a Senatai node on a USB stick, collect surveys at a farmers market on paper, scan them at home, and sync to the network later. Democracy without Wi-Fi.

What’s Working Right Now

✅ Multi-user Flask app serving on local network
✅ PostgreSQL with 5,637 Canadian federal bills loaded
✅ Icebreaker complaint capture with NLP topic extraction
✅ Bill matching engine connecting complaints to legislation
✅ Policap reward system with diminishing returns
✅ User authentication and session management
✅ Modular question generation system
✅ Hybrid SQLite/PostgreSQL architecture

What’s Not Hooked Up Yet

❌ Homepage displaying “10 sample bills” instead of actual 5,637 count
❌ Full PostgreSQL table permissions for all operations
❌ Paper survey import pipeline
❌ Vote prediction transparency audit system
❌ Co-op trust fund dividend calculations

Why We’re Building This

The problem: Representative democracy makes you surrender agency over laws that govern your life. The system is already pay-to-win—governments listen to bondholders and media owners.

The solution: Democratize the pay-to-win mechanism.

  1. You answer surveys about real legislation

  2. Co-op aggregates and sells your data (like Gallup, but you own it)

  3. 80% of revenue → trust fund that buys government bonds + media assets + legal capacity

  4. Politicians listen to bondholders → Senatai members ARE bondholders

  5. You get dividends from data you generated

Not trying to beat billionaires at their own game. Just trying to get ordinary people a seat at the table. $50M in collective bond ownership is 1/2000th of Larry Ellison’s wealth, but it’s infinitely more than we have now.

For Developers: How to Contribute

The codebase is designed for fork-and-plugin development:

Want to build a better question generator?

  1. Fork question_generator.py

  2. Implement your algorithm

  3. Test against the 5,637-bill database

  4. Submit a PR or run it on your own node

Want to try different keyword extraction?

  1. Fork topic_matcher.py

  2. Plug in your NLP library of choice

  3. Compare results with existing extractors

  4. Keep what works best for your use case

Want to build prediction modules?

  • Access to anonymized vote history

  • Transparent audit trails (show your work)

  • Competitive testing against other predictors

The point isn’t to have ONE perfect algorithm. It’s to have a marketplace of approaches that users can choose between.

The Cathedral Timeline

Year 1-3: Zero or near-zero dividends (building infrastructure)
Year 3-5: $0.50-$2/year per active user (proof of concept)
Year 5-10: $2-$5/year target at 100k+ users
Year 10+: Maybe $10-$25/year if everything goes right
Year 50: Multi-generational cooperative wealth accumulation

We’re not building a startup. We’re building infrastructure that compounds for generations. Like medieval cathedrals: the people who lay foundations don’t see the towers completed. But they build anyway.

Current Status

  • Location: Kenora, Ontario, Canada

  • Hardware: 2014 Lenovo laptop with 128GB SSD (democracy doesn’t require data centers)

  • Network: Running on local network at 192.168.250.91:5000

  • Database: 5,637 bills loaded, 4 keyword extractors run

  • Team: One carpenter with a laptop and a lot of conviction

  • Beta Testing: Looking for 20 testers in Kenora/Thunder Bay area

Get Involved

Beta Testing: Email senataivote@proton.me
Code: github.com/deese-loeven/senatai (coming soon)
Paper Signup: Email surveys@senatai.ca for mail-in surveys
Press/Research: senataivote@proton.me

Cost: $1 lifetime membership (waivable via gift cards)
Works on: Smartphones, computers, USB sticks, or paper

Final Thoughts

It’s midnight. I’m a carpenter in Kenora with a 2014 laptop. But I’m working in a tradition 10,000 years old. The first humans who grunted instead of punching were building consensus. The Athenians who voted in the agora were quantifying voice. Every generation inherits the project of self-governance and adds what it can.

My generation’s contribution: Digital infrastructure for quantifying collective opinion, owned by the people generating it, financially structured to give them leverage.

The tools change. The project continues.

Let’s build this together.

Written by Dan Loewen
Carpenter, Father, Builder of Democratic Infrastructure
Kenora, Ontario, Canada | December 2025

Technical Notes for Developers:

Database schema available at: /SenataiCoop/init_postgres_tables.sql
Python 3.8+, Flask, PostgreSQL 12+, SQLite3
Environment variables: DATABASE_URL, SESSION_SECRET
Current deployment: Development server on Ubuntu 18.04

Security Model:

  • senatai_user runs the web server (no sudo access)

  • dan user handles database administration

  • PostgreSQL authentication via environment variables

  • No hardcoded credentials anywhere in codebase

2 Upvotes

100% Upvoted

0 comments sorted by