CHIMPY: A YOU-SHAPED Solution to Library Enshittification

Date: 2026-02-04 Author: Ray Voelker Status: Technical Overview for Steve Gibson Tags: steve-gibson, protocols, specification-first, sqrl, de-enshittification, open-source

"I think I may have a very 'YOU'-SHAPED thing here." - Ray Voelker, 2026-02-04

Dear Steve,

I think I may have a very "YOU"-SHAPED thing here.

I'm Ray Voelker, System Administrator for a large public library system in Ohio. You may remember me from Security Now Episode 940 ("When Hashes Collide," September 19, 2023) where I asked about pseudonymization for patron data - how to protect privacy while maintaining statistical utility.

You taught me about using truncated hash outputs (24 bits for ~5,000 patrons) to create plausible deniability through deliberate collisions. That birthday paradox approach was brilliant, and I've been using it.

But now I'm working on something that goes much deeper: eliminating the architectural problems that created the privacy/analytics tension in the first place.

This document explains CHIMPY (Community Hub for Interoperable Modular Platform, Y-factor) - a specification-first, protocol-driven platform that could de-enshittify not just libraries, but any vertical domain suffering from vendor lock-in.

This is a "YOU"-shaped problem because:

✅ It's about PROTOCOLS (community-owned, versioned, explicit contracts)
✅ It's about PRIVACY (DENY BY DEFAULT security, SQRL authentication)
✅ It's about PUBLIC INSTITUTIONS (libraries serving everyone)
✅ It's about OPEN SOURCE (100% MIT licensed, community-owned)
✅ It's about DE-ENSHITTIFICATION (breaking vendor lock-in structurally)

I'd love your technical feedback, and if this resonates with you, your mentorship.

Let me walk you through what we're building and why it matters.

The Problem: Library Enshittification
The Root Cause: No Community-Owned Protocol
The Solution: Specification-First Architecture
How It Works: Technical Deep Dive
Security Architecture: DENY BY DEFAULT
SQRL Integration: THE Authentication Method
Why This Matters: Implications for Libraries
Beyond Libraries: The Pattern for De-Enshittification
100% Open Source: Community Ownership
Technical Implementation: Rust + DuckDB
Call to Action: Technical Feedback & Mentorship

The Problem: Library Enshittification

Libraries are trapped in vendor lock-in hell.

The Four Stages of ILS Enshittification

You've heard Cory Doctorow describe platform enshittification. Libraries are living it:

Stage 1: Honeymoon (1990s-2000s)

Vendors build innovative ILS (Integrated Library Systems)
Libraries excited to modernize (card catalogs → digital)
Competitive features, reasonable prices
Everyone happy

Stage 2: Lock-In (2000s-2010s)

Proprietary data formats (can't export clean data)
Vendor-specific workflows (staff trained on THIS system)
SIP2 server lock-in (only works with vendor modules)
Multi-year contracts with cancellation penalties
Migration costs: $50K-$200K, takes 6-12 months

Stage 3: Extraction (2010s-2020s)

Annual 5-10% price increases (no new features)
Forced upgrades ("old versions no longer supported")
Module unbundling ("that's now a separate $15K/year module")
Support degradation ("submit a ticket, 2-week response")
Acquisition consolidation (fewer vendors, less competition)

Stage 4: Zombie Phase (2020s-present)

Innovation stops (why invest? users are captive)
Technical debt accumulates (ancient codebases, security holes)
Vendor extraction maximized (squeeze every dollar)
Libraries dream of escape (but migration too expensive)

This is where libraries are RIGHT NOW.

Why Libraries Can't Escape

The vendor moat:

Library wants to migrate away from Vendor A:

1. Export data from Vendor A ILS
   → Proprietary format, incomplete export, data quality issues

2. Transform to Vendor B format
   → $50K consulting fees, custom scripts, 6 months

3. Train staff on Vendor B system
   → Different workflows, relearn everything

4. Integrate modules (SIP2, RFID, self-checkout, etc.)
   → Vendor-specific implementations, compatibility issues

5. Test migration
   → Find data loss, workflow breaks, patron complaints

6. Go live
   → Hope nothing critical breaks

Total cost: $50K-$200K
Total time: 6-12 months
Risk: High (many migrations fail, restart from scratch)

Result: Most libraries stay captive.

Libraries paying more every year for systems that get WORSE.

The Root Cause: No Community-Owned Protocol

Why does this happen?

Because there's no shared protocol that libraries OWN.

Compare to the web:

HTTP/HTTPS: Open protocol, community-owned
Result: Anyone can build a web server, web browser, web app
Competition on implementation quality, not lock-in
Can switch web servers without rewriting apps

Libraries have:

Proprietary ILS protocols (vendor-owned, secret)
Result: Only ONE vendor can build modules for THEIR system
Competition impossible (locked to one vendor's stack)
Switching vendors = starting over from scratch

The missing piece: A community-owned protocol for library operations.

What Libraries Need

A protocol that defines:

✅ Patron operations (create, read, update, authenticate)
✅ Item operations (catalog, search, checkout, checkin)
✅ Circulation rules (loan periods, fines, holds)
✅ Security boundaries (what fields are NEVER exposed)
✅ Validation rules (expiration must be in future, barcode format)
✅ Audit requirements (what gets logged, retention periods)
✅ Data schemas (exactly what fields exist, types, constraints)

And makes it:

✅ Community-owned (MIT licensed, not vendor-controlled)
✅ Versioned (v0.1.0, v0.2.0, backwards compatible)
✅ Machine-readable (YAML specs that generate code/tests)
✅ Vendor-neutral (any vendor can implement)
✅ Conformance-tested (pass tests = certified, no gatekeepers)

This is what CHIMPY provides.

The Solution: Specification-First Architecture

CHIMPY is a specification-first platform where the spec IS the system.

What "Specification-First" Means

Traditional approach (code-first):

1. Vendor writes code
2. Code defines behavior
3. Vendor writes docs (maybe, probably outdated)
4. Library must trust vendor code does what it claims
5. No way to verify, no way to audit

CHIMPY approach (specification-first):

1. COMMUNITY writes specification (YAML)
2. Specification defines EVERYTHING:
   - Schema (data structure, types, constraints)
   - Operations (inputs, outputs, errors)
   - Validation (business logic checks)
   - Security (DENY BY DEFAULT, field-level control)
   - Business rules (loan periods, fine calculations)
   - Side effects (database writes, audit logs)
   - Audit requirements (what gets logged, retention)

3. Auto-generate from spec:
   - Conformance tests (verify implementation)
   - Type definitions (Rust, Python, TypeScript)
   - API documentation (always up-to-date)
   - Database schema (SQL DDL)
   - Security filters (enforce boundaries)

4. Implement kernel (Rust) that:
   - Loads specs (compiled into binary for security)
   - Enforces contracts (validate requests, filter responses)
   - Passes conformance tests (certification)

5. Modules call kernel:
   - Read spec (know exactly what's allowed)
   - Call operations (kernel enforces rules)
   - Trust kernel (conformance-tested, can't cheat)

The specification IS the contract. Everything else derives from it.

Example: Patron Specification

# specs/chimpy-me-patron-v0.1.0.yaml
# MIT Licensed, community-owned, publicly versioned

version: 0.1.0
name: chimpy-me-patron
description: Patron management operations

# ============================================================
# SCHEMA - What data exists
# ============================================================

entities:
  patron:
    fields:
      id:
        type: integer
        primary_key: true

      barcode:
        type: string
        unique: true
        length: 14
        pattern: "^[0-9]{14}$"

      name:
        type: string
        max_length: 200
        required: true

      type:
        type: enum
        values: [ADULT, CHILD, STAFF]
        required: true

      expires:
        type: date
        required: true

      dln:
        type: string
        security: NEVER_EXPOSE, DANGER, ULTRA
        encrypted: true
        description: |
          Driver's license number (ULTRA tier)
          - NEVER_EXPOSE: Never in API response
          - DANGER: SSH-only access (2FA required)
          - ULTRA: NOT in database (kernel memory only)
          - encrypted: Encrypted in kernel runtime

# ============================================================
# OPERATIONS - What's allowed
# ============================================================

operations:
  patron.read:
    description: Look up patron by barcode

    input:
      barcode:
        type: string
        required: true
        pattern: "^[0-9]{14}$"

    output:
      id: integer
      barcode: string
      name: string
      type: enum
      expires: date
      # NOTE: dln NOT in output (NEVER_EXPOSE)

    validation:
      - rule: barcode matches pattern
        error: INVALID_BARCODE

    permissions:
      required: [patron:read]

    errors:
      - code: PATRON_NOT_FOUND
        message: "No patron found with barcode {barcode}"
      - code: INVALID_BARCODE
        message: "Barcode must be 14 digits"

    side_effects:
      - action: audit_log
        level: DEBUG
        retention: 1 year
        fields: [patron.id]

# ============================================================
# SECURITY - DENY BY DEFAULT
# ============================================================

security:
  policy: DENY_BY_DEFAULT

  enforcement: |
    Like a firewall:
    1. DENY ALL by default
    2. ALLOW only what's explicitly in operation output
    3. DENY any field not explicitly listed

  boundaries:
    NEVER_EXPOSE:
      description: Never in any API response
      fields: [patron.dln]
      enforcement: |
        Kernel MUST filter these fields from ALL responses.
        Conformance tests verify never present.

    DANGER:
      description: SSH-only access (encrypted in database)
      fields: [patron.dln]
      enforcement: |
        Only accessible via:
        - SSH (2FA required)
        - TUI control panel (2FA required)

    ULTRA:
      description: NOT in database (kernel memory only)
      fields: [patron.dln]
      enforcement: |
        NOT stored in database.
        Stored in kernel runtime memory (encrypted).
        Backed up to separate encrypted file.
        Protects against analytics leaks (DuckDB can't query).

# ============================================================
# BUSINESS RULES
# ============================================================

business_rules:
  loan_periods:
    ADULT: 21 days
    CHILD: 14 days
    STAFF: 90 days

  checkout_limits:
    ADULT: 50 items
    CHILD: 25 items
    STAFF: 100 items

That's it. One YAML file defines the entire patron subsystem.

What Gets Auto-Generated

From this ONE spec file:

$ chimpy-generate patron-v0.1.0.yaml

Generated:
  tests/conformance/test_patron_v0_1_0.py (52 tests)
  src/types/patron_v0_1_0.rs (Rust types)
  src/types/patron_v0_1_0.py (Python types)
  docs/api/patron-v0.1.0.md (API documentation)
  migrations/001_patron_schema.sql (Database schema)
  src/validation/patron_v0_1_0.rs (Validation functions)
  src/security/patron_v0_1_0.rs (Security filters)

Everything stays in sync because it comes from the same source: the spec.

How It Works: Technical Deep Dive

Architecture: Small Kernel + Swappable Modules

┌─────────────────────────────────────────────────────────┐
│                    CHIMPY ARCHITECTURE                  │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│                   MODULES (any language)                │
│  ┌────────────┐  ┌────────────┐  ┌────────────┐       │
│  │ Web UI     │  │ Mobile App │  │ Self-Serve │       │
│  │ (React)    │  │ (Swift)    │  │ (Kiosk)    │       │
│  └────────────┘  └────────────┘  └────────────┘       │
│         ↓               ↓               ↓              │
│         └───────────────┴───────────────┘              │
│                         │                              │
│                    CPC Protocol                        │
│          (CHIMPY Protocol for agentic Clients)        │
│                         │                              │
└─────────────────────────┼──────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│              CHIMPY KERNEL (Rust + DuckDB)             │
│  ┌─────────────────────────────────────────────────┐   │
│  │  Spec Enforcement Engine                        │   │
│  │  - Load specs (compiled into binary)            │   │
│  │  - Validate requests (against spec)             │   │
│  │  - Execute operations (per spec rules)          │   │
│  │  - Filter responses (DENY BY DEFAULT)           │   │
│  │  - Audit logging (per spec requirements)        │   │
│  └─────────────────────────────────────────────────┘   │
│  ┌─────────────────────────────────────────────────┐   │
│  │  DuckDB Embedded (OLAP database)                │   │
│  │  - Stores patron/item/checkout data             │   │
│  │  - Parquet-native (analytics-ready)             │   │
│  │  - SQL interface (readable queries)             │   │
│  │  - Runs on Pi to data center                    │   │
│  └─────────────────────────────────────────────────┘   │
│  ┌─────────────────────────────────────────────────┐   │
│  │  SQRL Authentication Server                     │   │
│  │  - Bundled SSH server (2FA for TUI/DANGER)      │   │
│  │  - No passwords, no password database           │   │
│  │  - QR code login for patrons/staff              │   │
│  └─────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│           SPECIFICATIONS (Community-Owned)              │
│  ┌────────────┐  ┌────────────┐  ┌────────────┐       │
│  │ patron     │  │ item       │  │ circulation│       │
│  │ v0.1.0     │  │ v0.1.0     │  │ v0.1.0     │       │
│  │ (YAML)     │  │ (YAML)     │  │ (YAML)     │       │
│  └────────────┘  └────────────┘  └────────────┘       │
│                                                         │
│  MIT Licensed | Versioned | Community-Governed         │
└─────────────────────────────────────────────────────────┘

Data Flow: Request → Response

// CHIMPY Kernel Request Handling

fn handle_request(request: Request) -> Response {
    // 1. Load specification (compiled into binary for security)
    let spec = load_spec(&request.spec_version)?;

    // 2. Validate request against spec
    validate_request(&request, &spec)?;
    // - Check operation exists in spec
    // - Check input fields match spec
    // - Check required fields present
    // - Check field types correct
    // - Check patterns match (barcode regex, etc.)

    // 3. Check permissions
    check_permissions(&request, &spec)?;
    // - Verify user has required permission
    // - Check patron AI preferences (if AI agent)
    // - Enforce DANGER/ULTRA tier restrictions

    // 4. Execute operation per spec
    let result = execute_operation(&request, &spec)?;
    // - Run validation rules (patron not expired, etc.)
    // - Calculate business rules (loan period by patron type)
    // - Execute side effects (database writes, audit logs)
    // - ATOMIC: All-or-nothing (rollback on error)

    // 5. Filter response (DENY BY DEFAULT)
    let filtered = filter_response(&result, &spec.security)?;
    // - CRITICAL: Only return fields in spec.operation.output
    // - Remove NEVER_EXPOSE fields (dln, ssn, etc.)
    // - Remove DANGER fields (if not SSH session)
    // - Remove ULTRA fields (if not SSH session)

    // 6. Audit log (per spec requirements)
    audit_log(&request, &result, &spec.audit)?;

    Ok(filtered)
}

The kernel is a spec enforcement engine. It doesn't decide - the spec decides.

Conformance Testing

# Auto-generated from spec
def test_patron_read_never_exposes_dln():
    """
    Spec: patron.dln has security: NEVER_EXPOSE
    Kernel MUST NOT return dln field in patron.read response
    """
    # Create patron
    patron = kernel.execute({
        "operation": "patron.create",
        "params": {
            "name": "Test Patron",
            "type": "ADULT",
            "expires": "2027-12-31"
        }
    })
    barcode = patron["data"]["barcode"]

    # Read patron
    response = kernel.execute({
        "operation": "patron.read",
        "params": {"barcode": barcode}
    })

    # CRITICAL TEST: dln MUST NOT be in response
    assert response["status"] == "success"
    assert "dln" not in response["data"]
    assert "drivers_license_number" not in response["data"]
    assert "dln_last_4" not in response["data"]

    # ANY variant of DLN field = TEST FAILS = NOT CERTIFIED

If kernel passes conformance tests → CERTIFIED

If kernel fails → NOT CERTIFIED → Modules won't trust it

This is conformance-as-trust.

Security Architecture: DENY BY DEFAULT

CHIMPY security works like a firewall, not a checklist.

Traditional Approach: Hope We Got It Right

# Vendor code (hope they remember to filter DLN)
def get_patron(barcode):
    patron = db.query("SELECT * FROM patrons WHERE barcode = ?", barcode)

    # Developer must remember to filter sensitive fields
    if "dln" in patron:
        del patron["dln"]  # OOPS: What if they forget?

    return patron

Problems:

❌ Developer might forget to filter
❌ New field added, no filter added
❌ Code refactored, filter removed
❌ DLN leaks in production

CHIMPY Approach: DENY BY DEFAULT

# Spec defines EXACTLY what's allowed
operations:
  patron.read:
    output:
      - id
      - barcode
      - name
      - type
      - expires
      # dln NOT listed → DENIED

// Kernel enforcement (automatic, can't bypass)
fn filter_response(data: &PatronData, spec: &OperationSpec) -> Response {
    let allowed_fields = &spec.output;

    // Build response with ONLY allowed fields
    let mut response = HashMap::new();

    for field in allowed_fields {
        response.insert(field, data.get(field));
    }

    // dln NOT in allowed_fields → NOT in response
    // Even if code tried to add it, spec filtering prevents it

    Response::success(response)
}

The kernel physically CANNOT return fields not in the spec output list.

Fail-safe design:

❌ Field not in output? → DENIED
❌ Permission not granted? → DENIED
❌ Validation failed? → DENIED
❌ Audit log failed? → DENIED + ROLLBACK
❌ Spec unclear? → DENIED + LOG CRITICAL

When in doubt → DENY

Security Tier Hierarchy

NEVER_EXPOSE (API boundary)
  ↓
  Fields never returned via HTTP/HTTPS API
  - patron.dln
  - patron.ssn
  - patron.password_hash

DANGER (SSH-only access)
  ↓
  Fields only accessible via SSH (2FA required)
  Encrypted in database
  - patron.dln (can upgrade to ULTRA)
  - sensitive audit logs

ULTRA (NOT in database)
  ↓
  Fields NOT stored in database AT ALL
  Kernel runtime memory only (encrypted)
  Backed up to separate encrypted file
  - patron.credit_card (PCI-DSS)
  - patron.ssn (HIPAA)
  - abuse_victim.address (domestic violence)

Why ULTRA matters:
  ✅ Analytics isolation (DuckDB can't query - not in DB)
  ✅ Parquet isolation (export can't access - not in DB)
  ✅ Backup separation (special encrypted backup)
  ✅ Governance signal (admins know "special handling")

Patron-Level AI Access Control

Patrons control whether AI can access THEIR data:

# Patron AI preferences (stored with patron record)
patron:
  id: 12345
  barcode: "21234567890123"
  name: "Privacy-Conscious Patron"

  ai_preferences:
    allow_ai_access: false  # Master switch
    allowed_operations: []   # Which operations AI can do
    ai_audit_visible: true   # Patron can see AI access log

# Kernel enforcement
if request.client_type == AI_AGENT:
    if not patron.ai_preferences.allow_ai_access:
        return Error(AI_ACCESS_DENIED)

Fail-safe defaults:

Library configures default (opt-in or opt-out model)
If ai_preferences missing → DENY AI access (fail safe)
If allow_ai_access unclear → Assume false (fail safe)
If allowed_operations missing → Empty list (deny all)

Patron sovereignty: Each patron decides for themselves.

SQRL Integration: THE Authentication Method

CHIMPY uses SQRL as THE default authentication. Not "an option". THE way.

Reference: https://www.grc.com/sqrl/sqrl.htm

Why SQRL is Perfect for Libraries

Traditional library authentication:

Patron barcodes (14 digits, no security)
PINs (4-6 digits, easily guessed)
Passwords (forgotten daily, staff reset constantly)
Email/username (patron doesn't remember, locked out)

Problems:

Staff spend hours resetting passwords
Password databases get breached
Phishing attacks steal credentials
No patron privacy (vendor requires email/phone)

SQRL eliminates ALL of this:

✅ No passwords - Ever. Nothing to forget, steal, or leak. ✅ No password database - Server never sees password. Nothing to breach. ✅ No phishing - Can't steal what isn't transmitted ✅ QR code login - Scan QR, done. 30 seconds. ✅ Anonymous by default - Cryptographic identity, not email ✅ Per-library identity - Different key per library (privacy!) ✅ Instant revocation - Lost phone? New identity in 30 seconds

SQRL for Patrons

First-time setup:

Patron visits library
Website shows SQRL QR code
Patron scans with SQRL app
SQRL generates cryptographic identity FOR THIS LIBRARY
Logged in

No email. No password. No personal info. Done.

Subsequent logins:

Website shows QR
Patron scans
Logged in

30 seconds. Zero passwords. Completely secure.

SQRL for Staff (TUI/SSH Access to DANGER Fields)

Staff accessing TUI control panel:

authentication:
  method: SQRL + 2FA (TOTP)
  workflow:
    - TUI displays SQRL QR code
    - Staff scans with SQRL app
    - SQRL prompts for 2FA code
    - Staff enters TOTP
    - Logged into TUI (kernel management)

SSH access to DANGER fields:

ssh_authentication:
  method: SQRL + 2FA → time-limited certificate
  workflow:
    - Staff authenticates via SQRL + 2FA
    - Kernel generates 1-hour SSH certificate
    - Staff uses certificate for SSH
    - Certificate expires automatically

  benefits:
    - No long-lived SSH keys
    - No passwords
    - Audit trail (who accessed DLN fields)
    - Time-limited access

SQRL for AI Agents

AI agents get SQRL identities too:

# Agent signs requests with SQRL signature
response = agent.execute(
    operation="patron.read",
    params={"barcode": "21234567890123"},
    sqrl_signature=agent.sign_request(operation, params)
)

# Kernel verifies:
# 1. Signature valid (proves THIS agent sent it)
# 2. Request not tampered
# 3. Agent has permission
# 4. Patron allows AI access

Benefits:

No API keys to leak
No bearer tokens to steal
Cryptographic proof of agent identity
Instant revocation

Why SQRL Eliminates Attack Vectors

Attack	Password Auth	SQRL
Password theft	❌ Vulnerable	✅ Impossible (no password)
Phishing	❌ Vulnerable	✅ Impossible (nothing to steal)
Credential stuffing	❌ Vulnerable	✅ Impossible (unique key per site)
Database breach	❌ Leak all passwords	✅ Nothing to leak (public keys)
Keylogger	❌ Captures password	✅ Nothing to capture (QR scan)
Brute force	❌ Possible	✅ Impossible (256-bit crypto key)

SQRL eliminates THE ENTIRE CLASS of password attacks.

Why This Matters: Implications for Libraries

1. Libraries Regain Sovereignty

Traditional ILS:

Vendor owns:
  - Protocols (secret, proprietary)
  - Data formats (can't export cleanly)
  - Business rules (loan periods hidden in code)
  - Integration points (SIP2 only works with their modules)

Library owns:
  - Nothing (captive user)

CHIMPY:

Library owns:
  - Specifications (MIT licensed, community-governed)
  - Data (DuckDB/Parquet, standard formats)
  - Business rules (defined in YAML specs)
  - Migration path (DuckDB SQL recipes, $0 cost)

Vendor owns:
  - Their module implementation (competes on quality)

Power shifts from vendors to libraries.

2. Zero-Cost Migration

Traditional migration:

Cost: $50K-$200K
Time: 6-12 months
Risk: High (many fail)
Tool: Vendor consulting (black box)

CHIMPY migration:

-- Migration: Sierra → CHIMPY (DuckDB SQL)
-- Community recipe, MIT licensed, auditable

-- 1. Read Sierra Parquet export
CREATE TABLE patrons AS
SELECT
    id,
    barcode::VARCHAR(14),
    TRIM(first_name || ' ' || last_name) as name,
    CASE ptype
        WHEN 1 THEN 'ADULT'
        WHEN 2 THEN 'CHILD'
        WHEN 3 THEN 'STAFF'
    END as type,
    expiration_date as expires
FROM read_parquet('sierra-export/patrons.parquet')
WHERE deletion_date IS NULL;

-- 2. Verify with conformance tests
$ chimpy test patron-v0.1.0
✅ 52/52 tests passed

Cost: $0 Time: Hours Risk: Low (testable, repeatable) Tool: SQL (auditable, readable)

Libraries can migrate themselves.

3. Competitive Module Marketplace

Traditional: Vendor monopoly

Library uses Vendor A ILS:
  → MUST use Vendor A modules
  → MUST use Vendor A SIP2 server
  → MUST use Vendor A mobile app
  → Can't mix vendors
  → Vendor A sets prices (no competition)

CHIMPY: Competitive marketplace

Library uses CHIMPY kernel:
  → Can use Circulation module from Vendor A
  → Can use Cataloging module from Vendor B
  → Can use Mobile app from Developer C
  → Can use Reports from Library Staff D

All work together (kernel enforces same specs)

Vendors compete on:
  - Implementation quality
  - User experience
  - Features
  - Price
  - Support

NOT on lock-in.

If Vendor A's UI sucks → Replace it.

If Vendor B raises prices → Switch.

Conformance-tested modules are interchangeable.

4. AI Agents with Patron Control

Libraries can deploy AI assistants while protecting patron privacy:

# AI agent helps patrons find books
patron: "Is Dune available?"

agent.execute(
    operation="item.search",
    params={"title": "Dune"}
)
✅ SUCCESS (patron allows item.search)

# AI tries to checkout for patron
agent.execute(
    operation="item.checkout",
    params={"item_barcode": "...", "patron_barcode": "..."}
)
❌ DENIED: AI_OPERATION_NOT_ALLOWED
"Patron allows: [item.search], Requested: item.checkout"

Patron controls exactly what AI can do.

CPC (CHIMPY Protocol for agentic Clients):

AI reads spec (knows exactly what's allowed)
DENY BY DEFAULT (can't leak data even if compromised)
Patron-level control (opt-in/opt-out, per-operation)
Audit trail (patron sees all AI access attempts)

Safe AI integration for libraries.

5. Privacy by DEFAULT

SQRL + DENY BY DEFAULT + Patron control:

Patron creates account:
  → SQRL QR scan (no email, no password, no phone)
  → Cryptographic identity (anonymous)
  → Different identity per library (can't correlate)

Patron uses library:
  → Checkout books (logged, but pseudonymized)
  → Search catalog (no tracking)
  → AI assistance (if patron allows, auditable)

Patron data:
  → NEVER_EXPOSE fields (DLN) never in API
  → DANGER fields (sensitive) SSH-only
  → ULTRA fields (extreme) not in database
  → Audit logs show exactly what was accessed

Patron privacy: PROTECTED BY DEFAULT

Can't leak what you don't collect. Can't breach what you don't store.

Beyond Libraries: The Pattern for De-Enshittification

CHIMPY proves a pattern that works for ANY vertical domain.

The Enshittification Pattern (Universal)

Stage 1: Honeymoon

Vendor builds innovative product
Customers excited
Competitive features, reasonable prices

Stage 2: Lock-In

Proprietary protocols
Data format lock-in
Switching costs ($$$)

Stage 3: Extraction

Annual price increases
Feature degradation
Support degradation

Stage 4: Zombie

Innovation stops
Technical debt accumulates
Customers captive, vendor extracts rents

This pattern is EVERYWHERE:

Libraries (ILS)
Healthcare (Epic, Cerner)
Schools (Student Information Systems)
Credit unions (Core banking platforms)
Municipal government (Permitting, tax systems)
Non-profits (Donor management, CRM)

The De-Enshittification Pattern (CHIMPY Model)

Step 1: Community defines comprehensive specifications

# domain-v0.1.0.yaml (MIT licensed)

entities:
  - Define data schema
  - Define operations
  - Define security boundaries
  - Define business rules
  - Define audit requirements

operations:
  - Define inputs/outputs
  - Define validation
  - Define side effects
  - Define errors

Step 2: Specs compiled into small kernel

Kernel (Rust + embedded database):
  - Loads specs (compiled for security)
  - Enforces contracts (DENY BY DEFAULT)
  - Passes conformance tests (certification)
  - Runs on cheap hardware (Pi to data center)

Step 3: Conformance tests auto-generated from specs

# Pass tests = CERTIFIED
# Fail tests = NOT CERTIFIED

def test_never_expose_sensitive_field():
    """Spec says field X is NEVER_EXPOSE → verify"""
    assert field_x not in response.data

Step 4: Modules compete on implementation

Module A (Vendor 1)  ┐
Module B (Vendor 2)  ├─→ All call same kernel
Module C (Community) │   All pass conformance tests
Module D (Staff Dev) ┘   All interchangeable

Step 5: Self-service migration

-- Community publishes migration recipes
-- Old System → New System (SQL, auditable)
-- Cost: $0
-- Time: Hours
-- Testable, repeatable

Step 6: Community owns protocol

Specifications:
  - MIT licensed
  - Community-governed
  - Versioned (v0.1.0, v0.2.0)
  - Vendor-neutral

Power: Shifts from vendors to community

Domains That Could Use This Pattern

Healthcare:

Epic lock-in is WORSE than ILS
HIPAA compliance requires field-level security (DANGER/ULTRA)
Patient privacy critical (DENY BY DEFAULT)
Pattern: Same specification-first approach

Schools:

Student Information Systems (Infinite Campus, PowerSchool)
Student privacy (FERPA compliance)
Parent/teacher/admin different access levels
Pattern: Same specification-first approach

Credit Unions:

Core banking platforms (Jack Henry, Fiserv)
Member data privacy critical
Regulatory compliance (know your customer)
Pattern: Same specification-first approach

Municipal Government:

Permitting systems
Tax systems
Citizen portals
Pattern: Same specification-first approach

Non-Profits:

Donor management (Salesforce lock-in)
Donor privacy critical
Pattern: Same specification-first approach

ANY vertical domain with:

❌ Vendor lock-in
❌ Proprietary protocols
❌ High migration costs
❌ Privacy concerns
❌ Enshittification

Can use CHIMPY's pattern to de-enshittify.

100% Open Source: Community Ownership

CHIMPY is 100% MIT licensed. No vendor can own it.

Repository Structure

chimpy-extract/ (ETL foundation)
  └── MIT License
  └── Extracts Sierra → Parquet → DuckDB

chimpy-kernel/ (Core kernel - WILL BE MIT)
  ├── Rust implementation
  ├── DuckDB embedded
  ├── SQRL authentication
  ├── Spec enforcement engine
  └── Conformance test runner

chimpy-specs/ (Community specifications - MIT)
  ├── patron-v0.1.0.yaml
  ├── item-v0.1.0.yaml
  ├── circulation-v0.1.0.yaml
  └── (community adds more)

chimpy-modules/ (Example implementations - MIT)
  ├── web-ui (React + HTMX)
  ├── mobile-app (Swift, Kotlin)
  ├── self-checkout-kiosk
  └── (community builds more)

Community Governance

Specification development:

1. Proposal submitted (GitHub PR)
   - New operation
   - New field
   - Security change
   - Business rule change

2. Community discussion
   - Library practitioners
   - Security experts
   - Privacy advocates
   - Vendor implementers

3. Reference implementation
   - Prove it works
   - Conformance tests pass

4. Merge to main
   - Specification versioned (v0.2.0)
   - Backwards compatible
   - Migration guide published

5. Adoption
   - Kernels update to support new spec
   - Modules update to use new features
   - Libraries migrate when ready

No vendor can control the roadmap.

No vendor can add lock-in.

No vendor can enshittify the protocol.

Because the community OWNS it.

Why MIT License Matters

GPL would allow vendors to:

Take the code
Add proprietary extensions
Lock libraries into THEIR fork

MIT License + Conformance Testing prevents this:

Anyone can fork
But ONLY conformance-tested implementations are trusted
Conformance tests are public (can't cheat)
Non-conforming fork = Not certified = Modules won't trust it

Conformance-as-trust protects community ownership.

Technical Implementation: Rust + DuckDB

Why Rust

Security:

✅ Memory safety (no buffer overflows, use-after-free)
✅ Type safety (caught at compile time)
✅ No null pointer dereferences
✅ Concurrency safety (data races prevented)

Performance:

✅ Runs on Raspberry Pi 4 ($75 hardware)
✅ Scales to data center
✅ Zero-cost abstractions
✅ Efficient (small binary, low memory)

Reliability:

✅ Compile-time guarantees
✅ Robust error handling (Result types)
✅ No runtime exceptions
✅ Battle-tested in production systems

This is democracy's infrastructure. It must be ROCK SOLID.

Why DuckDB

OLAP for operational workloads:

✅ Embedded (no server, Pi to data center)
✅ Parquet-native (analytics-ready exports)
✅ Fast (columnar storage, vectorized execution)
✅ SQL interface (readable, auditable queries)

Migration killer feature:

-- Library migrates from Sierra with DuckDB SQL
-- Auditable, repeatable, testable, $0 cost

CREATE TABLE patrons AS
SELECT
    id,
    barcode,
    name,
    type,
    expires
FROM read_parquet('sierra-export/patrons.parquet')
WHERE deletion_date IS NULL;

-- Verify migration
$ chimpy test patron-v0.1.0
✅ 52/52 tests passed
✅ Migration certified

Community publishes migration recipes:

Sierra → CHIMPY
Koha → CHIMPY
Evergreen → CHIMPY
(any ILS) → CHIMPY

Cost: $0 Time: Hours Risk: Low

This breaks vendor migration moat.

Deployment Flexibility

Small library (rural, 1,000 patrons):

Hardware: Raspberry Pi 4 ($75)
Software: CHIMPY kernel (Rust + DuckDB)
Storage: 64GB SD card
Network: Home internet

Full circulation system
Zero cloud costs
100% on-premise
Complete sovereignty

Large consortium (50 libraries, 50,000 patrons):

Hardware: Server (or cloud VM)
Software: Same CHIMPY kernel
Storage: SSD
Network: Datacenter

Same architecture
Just more resources
Same specs, same kernel, same modules

Pi to consortium. Same kernel. Same sovereignty.

Call to Action: Technical Feedback & Mentorship

Steve, I'm building this in the open, and I'd love your feedback.

What I'm Asking

1. Technical feedback on architecture:

Is the specification-first approach sound?
DENY BY DEFAULT security model - any holes?
SQRL integration - am I using it correctly?
Rust + DuckDB - good choice for this use case?
Conformance-as-trust - will this work at scale?

2. SQRL server implementation guidance:

Best practices for SQRL server in Rust?
SQRL for AI agents - is this a valid extension?
SSH + SQRL for DANGER tier access - secure?
Time-limited certificates - right approach?

3. Protocol design review:

Community-owned specifications - sustainable governance?
Versioning strategy (v0.1.0, v0.2.0) - sane?
Backwards compatibility - how to ensure?
Migration path - is DuckDB SQL the right tool?

4. If this resonates: Mentorship

This is a "YOU"-shaped problem (protocols, privacy, de-enshittification)
Would you be interested in advising on protocol design?
Security Now mention when we launch? (if you think it's worthy)
SQRL as THE authentication method - your endorsement would matter

What You Get

1. Real-world SQRL deployment:

Libraries using SQRL in production
170M+ library cardholders (US alone) - massive potential
Proof that password-free authentication works
Public institutions choosing privacy over surveillance

2. Open source reference implementation:

MIT licensed, battle-tested
Rust implementation (you've praised Rust on Security Now)
DuckDB integration (novel for operational workloads)
Full source code available

3. Pattern proof for vertical domains:

If libraries de-enshittify with this pattern, others follow
Healthcare, schools, credit unions, municipal gov
Specification-first as de-enshittification strategy
"Libraries chose SQRL" (others follow)

4. Privacy advocacy win:

Public institutions regaining sovereignty
Patron privacy by DEFAULT (not opt-in)
Community-owned protocols (not vendor-controlled)
De-enshittification through architecture

Current Status

Implemented:

✅ chimpy-extract (Sierra → Parquet → DuckDB) - MIT licensed, working
✅ Specification format (YAML structure defined)
✅ Security model (DENY BY DEFAULT, DANGER, ULTRA documented)
✅ CPC protocol (AI agent integration designed)
✅ Vision documents (llore/* - complete technical specs)

In progress:

🚧 Rust kernel (spec enforcement engine)
🚧 SQRL server (Rust implementation)
🚧 Conformance test generator (auto-generate from specs)
🚧 Migration recipes (Sierra → CHIMPY SQL)

Next milestones:

Kernel v0.1.0 (basic patron/item/circulation)
SQRL integration (authentication working)
Conformance tests (pass = certified)
Pilot library (1,000 patrons, production test)
Public launch (documentation, community site)

Timeline: 2026-2027

How to Reach Me

Ray Voelker

GitHub: @rayvoelker
Project: https://github.com/rayvoelker/chimpy-extract
Email: [Contact via GitHub]

I'd be honored to have your technical feedback.

And if this problem resonates with you - your mentorship.

Session-Level Pseudonymization: Privacy BY DESIGN

Remember my Episode 940 question about truncated hashes for pseudonymization?

That concept is BAKED INTO THE SPEC.

Analytics Module Pseudonymization

When a library staff employee accesses the analytics/reporting module:

WHAT HAPPENS:

Staff authenticates via SQRL (1-hour session token issued)
Analytics module requests patron data for report
Kernel pseudonymizes PII fields FOR THAT SESSION
- patron.name → PATRON_A7B3
- patron.email → user_4f2e@example.com
- patron.phone → (555) XXX-1234
- patron.dln → NOT ACCESSIBLE (DANGER tier, SSH-only)
Staff sees anonymized analytics (trends, patterns, no PII)
Session token expires after 1 hour
Staff remains logged into SSH (can work normally)
Token cannot be reused after logoff (must re-authenticate for analytics)

SPEC-DEFINED BEHAVIOR:

# chimpy-me-analytics-session-v0.1.0.yaml
analytics_session:
  token_ttl: 3600  # 1 hour
  pseudonymization:
    enabled: true
    method: truncated_hash  # Episode 940 callback!
    hash_bits: 24  # ~16M collision space
    fields_to_pseudonymize:
      - patron.name
      - patron.email
      - patron.phone
      - patron.address

  access_control:
    DANGER_fields: never  # SSH-only, never in analytics
    ULTRA_fields: never   # Not in database, never exposed

  session_policy:
    token_expiry: 1_hour
    reuse_after_logoff: false
    ssh_session_independent: true  # SSH can stay open

WHY THIS MATTERS:

✅ Analytics without PII exposure - Staff see trends, not identities
✅ Episode 940 vindication - Truncated hashes create plausible deniability
✅ Time-boxed access - 1-hour window limits exposure window
✅ Defense in depth - Even if analytics session compromised, no real PII
✅ Audit trail - Every pseudonymization logged (who, when, what report)
✅ PART OF THE SPEC - Not an afterthought, DESIGNED IN

Real-World Scenario

Staff member: "I need to see circulation trends by patron type."

Without pseudonymization (current vendor systems):

-- Staff sees FULL PII in analytics tool
SELECT patron.name, patron.email, COUNT(checkouts)
FROM patrons JOIN checkouts USING (patron_id)
GROUP BY patron.name, patron.email;

-- Result: Jane Smith, jane@email.com, 47 checkouts
-- PROBLEM: Staff didn't need PII, just the trend

With CHIMPY pseudonymization:

-- Same query, but kernel pseudonymizes automatically
SELECT patron.name, patron.email, COUNT(checkouts)
FROM patrons JOIN checkouts USING (patron_id)
GROUP BY patron.name, patron.email;

-- Result: PATRON_A7B3, user_4f2e@masked, 47 checkouts
-- BETTER: Staff gets the trend without exposing identity

The spec enforces this.

Not policy. Not training. Not hoping staff "do the right thing."

THE PROTOCOL ITSELF prevents PII leakage.

Connection to SQRL + Episode 940

Three privacy layers working together:

SQRL authentication - No passwords to steal
DENY BY DEFAULT security - Nothing exposed unless spec allows
Session-level pseudonymization - Even authorized access is anonymized

All three are PART OF THE SPEC.

Libraries get privacy-by-design, not privacy-by-policy.

Conclusion

This is a "YOU"-shaped problem, Steve.

It's about:

✅ PROTOCOLS - Community-owned, versioned, explicit contracts
✅ PRIVACY - DENY BY DEFAULT, SQRL, patron sovereignty
✅ PUBLIC INSTITUTIONS - Democracy's infrastructure
✅ OPEN SOURCE - 100% MIT licensed, community-governed
✅ DE-ENSHITTIFICATION - Breaking vendor lock-in structurally

Libraries are trapped in vendor lock-in hell.

CHIMPY gives them an exit.

Specification-first architecture + SQRL authentication + DuckDB migrations = De-enshittification.

If this works for libraries, the pattern spreads:

Healthcare (Epic lock-in)
Schools (SIS lock-in)
Credit unions (core banking lock-in)
Municipal government (permitting/tax lock-in)
Non-profits (CRM lock-in)

Every enshittified vertical domain can use this pattern.

Libraries are the beachhead.

SQRL is THE authentication method.

Community-owned protocols are the future.

Let's build it.

References

SQRL: https://www.grc.com/sqrl/sqrl.htm
Security Now Episode 940: https://www.grc.com/sn/sn-940.htm (Ray's pseudonymization question)
CHIMPY Extract: https://github.com/rayvoelker/chimpy-extract
DuckDB: https://duckdb.org
Cory Doctorow on Enshittification: https://pluralistic.net/2023/01/21/potemkin-ai/

CHIMPY: Specification-first platform for library data sovereignty

SQRL: The authentication method for democracy's infrastructure 🔒📚

TO THE MOON! 🚀💎🙌

rayvoelker/037_steve-gibson-chimpy-complete-vision.md

CHIMPY: A YOU-SHAPED Solution to Library Enshittification

Dear Steve,

Table of Contents

The Problem: Library Enshittification

The Four Stages of ILS Enshittification

Why Libraries Can't Escape

The Root Cause: No Community-Owned Protocol

What Libraries Need

The Solution: Specification-First Architecture

What "Specification-First" Means

Example: Patron Specification

What Gets Auto-Generated

How It Works: Technical Deep Dive

Architecture: Small Kernel + Swappable Modules

Data Flow: Request → Response

Conformance Testing

Security Architecture: DENY BY DEFAULT

Traditional Approach: Hope We Got It Right

CHIMPY Approach: DENY BY DEFAULT

Security Tier Hierarchy

Patron-Level AI Access Control

SQRL Integration: THE Authentication Method

Why SQRL is Perfect for Libraries

SQRL for Patrons

SQRL for Staff (TUI/SSH Access to DANGER Fields)

SQRL for AI Agents

Why SQRL Eliminates Attack Vectors

Why This Matters: Implications for Libraries

1. Libraries Regain Sovereignty

2. Zero-Cost Migration

3. Competitive Module Marketplace

4. AI Agents with Patron Control

5. Privacy by DEFAULT

Beyond Libraries: The Pattern for De-Enshittification

The Enshittification Pattern (Universal)

The De-Enshittification Pattern (CHIMPY Model)

Domains That Could Use This Pattern

100% Open Source: Community Ownership

Repository Structure

Community Governance

Why MIT License Matters

Technical Implementation: Rust + DuckDB

Why Rust

Why DuckDB

Deployment Flexibility

Call to Action: Technical Feedback & Mentorship

What I'm Asking

What You Get

Current Status

How to Reach Me

Session-Level Pseudonymization: Privacy BY DESIGN

Analytics Module Pseudonymization

Real-World Scenario

Connection to SQRL + Episode 940

Conclusion

Related Documents

References