The Precursor Has Arrived

Why This Matters

Your smartphone tracks everything. Your laptop phones home to Cupertino or Redmond. Every IoT device is a surveillance endpoint. Cloud services own your data.

In 2026, truly private computing is nearly extinct.

The Precursor is different. It's the first mobile computing platform designed from silicon up to be auditable, trustworthy, and owned by you.

What Makes Precursor Different

• FPGA-based processor — No proprietary CPU microcode. Every transistor is documented and auditable.
• Xous OS — Microkernel operating system designed for security. Open source. No hidden services.
• LCD display — 336x536 monochrome LCD, backlit for night use, 100% inspectable.
• Physical keyboard — No touchscreen tracking or gesture recognition.
• PDDB storage — Plausibly Deniable DataBase with encrypted, deniable volumes.
• Zero cloud dependencies — Works completely offline. No telemetry. No phoning home.

This is the platform I've been waiting for. The one where software can be truly private.

What We Built (January 2026)

Four production applications. One comprehensive development toolkit. All open source. All offline-first. Zero analytics, zero tracking, zero cloud lock-in.

By the Numbers

Apps shipped: 4
Lines of Rust: ~8,500
Development time: 28 days (Dec 28, 2025 → Jan 25, 2026)
Cloud dependencies: 0
Analytics added: 0
User tracking: 0
GitHub repos: 5 (4 apps + toolkit)
Screenshots captured: 47
Coffee consumed: Immeasurable

Platform: 100% offline-capable
Security model: Zero-trust
Data ownership: User (not vendor)

App #1: Writer — The Unified Writing Suite

GitHub: precursor-writer

Three Writing Modes, One App

Writer combines three distinct writing workflows optimized for the Precursor's 336x536 monochrome display and physical keyboard.

Markdown Editor

Multi-document text editing with line-level markdown styling. Not a full renderer—a practical editor for monochrome LCD constraints.

Features:
- Multi-document management (create, open, delete)
- Line-level syntax styling:
  - Headings → Large/Bold GlyphStyle
  - Code blocks → Monospace
  - Block quotes → Indented with left bar
  - Lists → Preserved prefixes
  - Horizontal rules → Drawn lines
- Preview mode (rendered markdown, stripped prefixes)
- Word/character count in status bar
- Export via TCP (port 7879) or USB keyboard autotype
- Auto-save on exit and focus loss

The editor handles documents up to 32KB—sufficient for blog posts, documentation, notes. Larger documents can be split across files.

Journal Mode

One entry per day, automatically keyed by date. No manual file management. Just write.

Controls:
- Auto-creates today's entry on open
- Date navigation: Esc+[ / Esc+] (previous/next day)
- Jump to today: Esc+t
- Search across all entries: Esc+/ (substring match)
- Auto-saves on date change or exit

Uses device RTC (llio::LocalTime) for date sourcing—no NTP, no internet dependency.

Typewriter Mode

Distraction-free writing. Forward-only. No backspace, no cursor movement. Just type.

Philosophy:
- Prevents editing anxiety
- Encourages flow state
- Mimics actual typewriter constraints
- Session-based: fresh start each time
- Live word counter
- Save to editor documents when done (optional)

Inspired by apps like iA Writer's Focus Mode and Cold Turkey Writer, but running on hardware designed for privacy.

Export: TCP Push, Not Cloud Upload

No cloud sync. No account creation. No vendor lock-in. Export documents via network or USB keyboard:

# TCP export (device listens on port 7879)
nc  7879 > document.md

# USB keyboard autotype
# Device types document character-by-character into active window
# Works with any text editor on connected computer

Why TCP instead of file sharing? Because Precursor doesn't expose USB mass storage by default—security by design. Data leaves the device only when you explicitly tell it to.

PDDB Storage

All documents encrypted in the Plausibly Deniable DataBase. If coerced to unlock the device, you can provide a duress password that reveals a different set of documents.

Dictionary: writer.docs
Keys: md:, journal:, typewriter:session
Format: UTF-8 text, direct storage (no serialization overhead)

Encryption: AES-256-GCM-SIV (provided by PDDB layer)
Deniability: Multi-basis support (separate password → different documents)

App #2: Flashcards — Network-Imported, Offline Study

GitHub: precursor-flashcards

The Problem with Existing Flashcard Apps

Anki requires an account. Quizlet tracks you. Mobile apps sync through the cloud. Study data becomes vendor property.

The Precursor Approach

Import decks from your computer. Study offline. Zero telemetry. Your quiz performance stays on your device, encrypted.

Features

- Multiple decks with persistent PDDB storage
- TCP import: author .tsv files on computer, push to device
- Built-in demo deck on first launch
- Flip cards with Space/Enter
- Navigate: arrow keys or n/p
- Deck management (delete support)
- Scrollable deck list
- Up to 500 cards per deck
- Duplicate deck name handling

Deck Import Format

Create flashcards in a simple tab-separated format:

#name:Spanish Vocab
hola\thello
gato\tcat
perro\tdog
casa\thouse
libro\tbook

Then push to the device:

# From deck list, press 'i' to start listener
# Device shows "Listening on port 7878..."

# From computer:
cat spanish.tsv | nc  7878

# Deck appears instantly in deck list, ready to study

Why TSV, Not JSON or XML?

Parsing JSON on a 100MHz CPU is noticeable. TSV is trivial to parse, trivial to author, and human-readable. Complexity budget spent on UX, not data formats.

PDDB Storage Architecture

Dictionary: flashcards
Index key: deck_index (binary-serialized Vec)
Deck keys: deck_0, deck_1, ... deck_N (binary-serialized Vec)

DeckMeta: name, card_count, created timestamp
Card: front (String), back (String)

Max deck size: 500 cards (fits in 64KB PDDB value limit)
Import protocol: TCP on port 7878, one connection per deck

Future: Spaced Repetition

Current version: basic flashcards, no SRS algorithm. Next version will track review history and implement SM-2 or similar for optimal retention scheduling.

App #3: C64 Emulator — Retro Gaming on Auditable Hardware

GitHub: precursor-c64

Why Emulate a 1982 Computer in 2026?

Because Commodore 64 games are fun, and they work beautifully on a 1-bit display.

Board games. Text adventures. Roguelikes. Puzzle games. Strategy games. Wireframe 3D. The entire C64 library designed around high-contrast visuals renders perfectly on Precursor's monochrome LCD.

What We Implemented

CPU: Full MOS 6502
- All 151 legal opcodes
- Proper flag handling (N,V,Z,C)
- BCD arithmetic
- Interrupt support (IRQ, NMI, RESET)

Video: VIC-II essentials
- Text mode (40x25 characters)
- Standard bitmap mode (320x200 hi-res)
- Bank switching for character ROM
- Monochrome rendering (luminance threshold)

Memory: 64KB RAM + ROM banking
- BASIC ROM (optional, 8KB at $A000-$BFFF)
- KERNAL ROM (optional, 8KB at $E000-$FFFF)
- Character ROM (minimal built-in, 4KB)
- I/O area ($D000-$DFFF): VIC, SID stub, CIA, color RAM

Input: CIA1 keyboard matrix
- 8x8 matrix scanning
- Precursor key mapping (A-Z, 0-9, arrows, etc.)
- RUN/STOP → Esc, RETURN → Enter

Storage: PDDB + TCP import
- .PRG files stored encrypted
- Load via: (echo "gamename"; cat game.prg) | nc  6464

What's Not Implemented (v1)

• SID audio — Precursor has piezo speaker only. Returns 0 for SID reads, ignores writes. Focus on visual gameplay.
• Sprites — Not needed for target games (board, text, wireframe).
• Raster interrupts — CIA timer IRQ works. Raster IRQ used for split-screen effects not common in monochrome games.
• Illegal opcodes — Treated as NOP. Few games rely on them.
• Smooth scrolling — Not needed for turn-based/puzzle games.
• Multicolor bitmap — Incompatible with 1-bit display.
• Disk drive (.D64) — Use .PRG for now. Disk support planned for v2.

Target Game Library

Games that work beautifully on monochrome:

Board Games:
- Othello, Chess, Checkers, Go
- Archon (character sprites high-contrast)

Text Adventures:
- Zork I-III
- Hitchhiker's Guide to the Galaxy
- Planetfall, Suspended

Roguelikes:
- Rogue, Nethack, Moria
- Angband (if ported)

Puzzle:
- Boulder Dash (monochrome original)
- Sokoban
- Tetris clones

Strategy:
- Ultima I-V (primarily text/tile-based)
- Pirates! (wireframe ship combat)
- M.U.L.E. (economic strategy)

Wireframe 3D:
- Elite (vector graphics, perfect for 1-bit)
- Mercenary
- Star Wars (Atari wireframe arcade port)

Performance: 50K Cycles Per Frame

C64 runs at ~1 MHz. Emulating that on Precursor's 100 MHz RISC-V means each instruction costs ~100 CPU cycles.

At 50,000 C64 cycles per frame (PAL ~50 fps → ~20 fps emulated), turn-based and puzzle games are perfectly playable.

Monochrome Rendering: Luminance Threshold

// C64's 16 colors mapped to black/white by brightness
const LUMINANCE: [u8; 16] = [
    0,   // Black → 0
    255, // White → 255
    68,  // Red → dark
    188, // Cyan → light
    98,  // Purple → dark
    139, // Green → medium
    51,  // Blue → dark
    208, // Yellow → light
    98,  // Orange → dark
    68,  // Brown → dark
    137, // Light red → medium
    68,  // Dark gray → dark
    137, // Medium gray → medium
    196, // Light green → light
    137, // Light blue → medium
    196, // Light gray → light
];

fn color_to_mono(c64_color: u8) -> bool {
    LUMINANCE[c64_color as usize & 0x0F] >= 128
}

Games designed with high-contrast palettes (most pre-1985 titles) render cleanly.

No Dependency on Copyrighted ROMs

The emulator ships with a minimal built-in character ROM (generated font) and a boot stub. Original C64 BASIC/KERNAL ROMs are optional for full compatibility.

Users can add original ROMs to the PDDB if they own them. Without ROMs, the emulator still runs .PRG files that don't depend on BASIC interpreter.

Future: Maelee's Game Development Project ❤️

My daughter Maelee and I are collaborating on original C64 games designed for Precursor's display. She's learning game design, I'm learning to be patient with sprite placement bugs.

Planned games:

• "Hexmaze" — Procedurally generated hex-tile dungeon crawler. Monochrome-first design.
• "Starport" — Text-based space trading game. Inspired by Elite but entirely menu-driven.
• "Tower of Glyphs" — Puzzle game using C64 PETSCII characters as game pieces.

These will be the first C64 games designed specifically for a monochrome LCD display. Development starts February 2026. Open source when complete.

App #4: Timers — Pomodoro, Stopwatch, Countdown

(GitHub repo in progress—integrating F1/F4 keyboard standard updates)

Unified Timer Suite

Three timing modes in one app:

Pomodoro Timer

Default intervals (configurable):
- Work: 25 minutes
- Short break: 5 minutes
- Long break: 15 minutes (every 4th break)

Features:
- Audio alert on completion (piezo beep)
- PDDB persistence for interval settings
- Session counter (tracks completed pomodoros)
- Auto-start next interval (optional)

Stopwatch

Features:
- Lap tracking (up to 50 laps)
- Display: current time, lap time, total time
- Export lap times via TCP or USB autotype
- Millisecond precision (RTC-backed)

Countdown Collection

Features:
- Multiple named countdown timers
- Quick presets (5m, 10m, 15m, 30m, 60m)
- Custom durations (up to 24 hours)
- Simultaneous countdowns (visual queue management)
- Persistent across app restarts

Why Timers on Secure Hardware?

Because your productivity data is private. Web-based Pomodoro apps track your work patterns, sell your focus hours to advertisers. Precursor timers work offline, store nothing in the cloud.

The Development Toolkit That Made This Possible

GitHub: xous-dev-toolkit

The macOS ARM64 Problem

Developing for Precursor requires Renode (an open-source hardware emulator). Renode's GUI uses XWT/GTK, which doesn't work on macOS ARM64.

Without the GUI, you lose:

• Display preview (can't see what your app renders)
• Interactive keyboard input (can't test UI flows)
• Screenshot capture (can't document your work)

The Solution: Headless Renode + Telnet Automation

Renode supports a telnet monitor protocol. I built Python scripts to automate the entire development workflow without GUI dependency.

Headless Renode Startup

# Start emulator with telnet access on port 4567
renode --disable-xwt -P 4567 \\
  -e 'path add @/path/to/xous-core;
      i @emulation/xous-release.resc;
      start'

Python Automation Scripts

# Take screenshot of emulated display
python3 scripts/renode_interact.py screenshot output.png

# Initialize PDDB (handles full PIN entry sequence)
python3 scripts/renode_interact.py init-pddb a

# Launch app via menu system
python3 scripts/renode_interact.py launch-app Flashcards 1

# Full boot sequence: wait + PDDB + app launch
python3 scripts/renode_interact.py full-init 90

Critical Discovery: Keyboard Hold Timing

This was the hardest problem to solve. Renode keyboard emulation has timing-dependent behavior that's CPU-load-sensitive.

The 500ms Hold Threshold: Xous keyboard service triggers "hold" variants if emulated time between keypress and release exceeds 500ms. Many navigation keys (arrows, Home, Space) have hold: None—they produce NOTHING when held too long.

Initial attempts: send Press, sleep 50ms, send Release. Failed unpredictably. When CPU is idle, emulated time runs faster than wall-clock time. 50ms real time could be 600ms emulated time.

The Fix

# WRONG - may exceed 500ms emulated time
sock.sendall(b'sysbus.keyboard Press Home\\n')
time.sleep(0.05)  # Unreliable!
sock.sendall(b'sysbus.keyboard Release Home\\n')

# CORRECT - single write, minimal emulated gap
sock.sendall(b'sysbus.keyboard Press Home\\n'
             b'sysbus.keyboard Release Home\\n')

This single discovery unlocked reliable keyboard automation. Every screenshot, every PDDB init, every app launch depends on this timing pattern.

PDDB Initialization Automation

First-boot Precursor requires:

1. Format PDDB confirmation (navigate dialog with Down, Down, Enter)
2. Enter PIN (hardcoded 'a' in Renode keybox)
3. Confirm PIN (enter again)
4. Wait ~6 minutes for format completion
5. Unlock PDDB (enter PIN third time)
6. Dismiss mount notification

Manual process: tedious, error-prone. Automated script: reliable, repeatable.

def init_pddb(pin='a'):
    # Navigate format confirmation dialog
    send_keys(['Down', 'Down', 'Return'])
    
    # Enter PIN (with InjectLine to avoid hold timing issues)
    send_command(f'sysbus.keyboard InjectLine "{pin}"')
    time.sleep(1)
    
    # Dismiss password prompt, re-enter PIN
    send_keys(['Return'])
    send_command(f'sysbus.keyboard InjectLine "{pin}"')
    
    # Wait for format (progress bar visible for ~6 minutes)
    print("Formatting PDDB... (~6 minutes)")
    wait_for_format_complete()
    
    # Unlock post-format
    send_command(f'sysbus.keyboard InjectLine "{pin}"')
    time.sleep(2)
    
    print("PDDB initialized and mounted")

Screenshot Capture Pipeline

# Query display framebuffer from emulator
(monitor) sysbus.memlcd ReadAllLines

# Returns: base64-encoded 1-bit bitmap (336x536)
# Convert to PNG with PIL:
img = Image.frombytes('1', (336, 536), decoded_bytes, 'raw', '1;I')
img.save('screenshot.png')

Automated screenshot workflow:

1. Boot emulator (headless)
2. Initialize PDDB
3. Launch app
4. Navigate to each screen/mode
5. Capture screenshot at each state
6. Save to screenshots/ directory

Result: Complete screenshot documentation generated automatically. Every README screenshot created by automation. No manual GUI interaction required.

LLM-Assisted Development with CLAUDE.md

The toolkit includes CLAUDE.md—a comprehensive guide for using LLMs (Claude Code) as a development agent for Precursor apps.

It covers:

• Xous OS architecture and APIs
• Hardware constraints (100 MHz RISC-V, 336x536 1-bit display)
• GAM (Graphics Abstraction Manager) patterns
• PDDB storage APIs
• Network and TLS usage
• Complete app template with boilerplate
• Debugging strategies for headless development
• Hard-won API discoveries

This file is placed at the repository root and used as context for LLM sessions. Result: faster iteration, fewer API misunderstandings, working code on first compile.

Discoveries Document

The discoveries.md file captures hard-won knowledge:

Confirmed patterns:
- Do NOT depend on ux-api or blitstr2 directly
  Use gam::menu::* (re-exports ux_api::minigfx::*)
  
- Point coordinates are isize, not i16
  (important for layout arithmetic)
  
- std::net works directly (TcpListener, TcpStream, UdpSocket)
  Xous routes std::net to net service via IPC automatically
  
- PDDB get() returns PddbKey implementing Read/Write/Seek
  Always Seek(Start(0)) before reading
  
- GAM rate limits redraws to ~30fps (33ms minimum between flushes)

- Server names must be globally unique across all processes

- main() -> ! pattern mandatory
  Use xous::terminate_process(0) to exit
  
- Apps must handle FocusChange to avoid CPU waste when backgrounded

API quirks:
- APP_NAME must match context_name in apps/manifest.json
- Modal radiobuttons: Enter at item index selects payload
  Enter at items.len() confirms dialog
- Menu key is '∴' (U+2234) for BOTH opening AND selecting
- Arrow keys: '→' '←' '↑' '↓' (Unicode, NOT Apple PUA codes)

This document evolves with each app built. Every mistake documented. Every workaround captured. Shared openly so others don't repeat the same debugging sessions.

Future: LoRa Expansion Module

The apps we've built prove Precursor's software capability. Next challenge: wireless communication that maintains zero-trust security model.

Why Not WiFi or Bluetooth?

WiFi has an IP stack. Bluetooth has a complex protocol stack. Both have decades of CVEs. Both phone home. Both enable remote exploitation.

LoRa is different. No IP stack. No automatic routing. No internet dependency. Just RF packets between devices you explicitly trust.

LoRa Expansion for Precursor: The Plan

I've applied for the NextPCB Accelerator #5 campaign (RAK3172 LoRa module sponsorship). Goal: build the first wireless expansion for Precursor that maintains its security philosophy.

Technical Design

Module: RAK3172 (STM32WLE5CC + LoRa PHY)
Power: 3.3V LDO from Precursor battery
Interface: 8-pin connector to iCE40 UP5K FPGA GPIOs
Protocol: UART at 115200 baud (AT command interface)
Antenna: External SMA via U.FL pigtail
Placement: Fits in Precursor battery compartment

LoRa capabilities:
- Class A/B/C LoRaWAN support
- P2P mode (no infrastructure needed)
- Ultra-low power sleep (< 2µA)
- Range: 2-15 km line-of-sight

Use Cases

Off-Grid Personal Knowledge Management Sync

Scenario: Two Precursor devices within LoRa range (< 5 km)
App: Writer notes, Journal entries, Flashcard decks

Flow:
1. Device A: Export → LoRa broadcast
2. LoRa module sends encrypted packet (ChaCha20-Poly1305)
3. Device B: LoRa module receives, decrypts with pre-shared key
4. Device B: Import → Merge into PDDB

No internet. No server. No cloud sync service.
Just direct, encrypted, peer-to-peer data transfer.

Secure Messaging via Meshtastic Protocol

Meshtastic: Open-source mesh networking protocol for LoRa
- Multi-hop routing (messages relay through intermediate nodes)
- End-to-end encryption (AES-256)
- Works without infrastructure

Precursor + Meshtastic:
- Join existing Meshtastic networks
- Send encrypted messages to other devices
- No phone number, no SIM, no carrier
- No message stored on vendor servers

Perfect for: Hiking, protests, disaster response, off-grid communication

Sensor Data Collection Without Infrastructure

Scenario: Environmental monitoring, agriculture, remote telemetry

Setup:
- Arduino/ESP32 sensors → LoRa transmitter
- Precursor with LoRa expansion → receive sensor data
- Log to PDDB, graph on LCD display

No WiFi needed. No cloud upload. Data stays local, encrypted.

Example: Soil moisture sensors across farm
- 20 sensor nodes (solar + LoRa)
- 1 Precursor base station
- Collect readings, analyze trends, make irrigation decisions
- Zero monthly cloud service fees

Timeline

February 7, 2026: Schematic complete (KiCad)
February 14, 2026: Ready for prototype (PCB layout finalized)
March 2026: First prototype assembled and tested
April 2026: Xous LoRa driver development
May 2026: Meshtastic integration complete
June 2026: Open source release (hardware + firmware)

License: CERN-OHL-P (hardware), MIT (firmware)

Open Source, From Silicon to Software

The LoRa expansion will be fully documented:

• KiCad schematics and PCB layout on GitHub
• Bill of materials with supplier links
• Assembly instructions with photos
• Xous driver source code (Rust)
• AT command reference for RAK3172 integration
• Example apps (LoRa chat, file sync, sensor logger)
• Hackster.io project page with full tutorial

Anyone with a Precursor will be able to build their own. No proprietary modules. No vendor lock-in. No mandatory cloud services.

Precursor Keyboard Standard: F1/F4 Universal Navigation

While building these apps, I developed a keyboard standard for Precursor to improve discoverability and consistency.

The Standard

Universal Keys (all apps should implement):

F1: Menu / Help
- Opens context-sensitive menu
- First item is always "Help" (shows key bindings)
- Modal overlay, dismissible with F4
- Keyboard navigable (arrows + Enter)

F4: Exit / Back
- Consistent "back" or "out" behavior
- Confirms before data loss (unsaved changes, active timers)
- Hierarchical: exits current context, not necessarily whole app

F2/F3: App-specific
- Available for primary/secondary quick actions
- Examples:
  - Writer: F2 = Toggle Preview, F3 = Save
  - Timers: F2 = Start/Stop, F3 = Reset
  - Flashcards: F2 = Flip Card, F3 = Next Card

Why This Matters

Discoverability. New users press F1 in any app, see Help with full key bindings. Muscle memory. Same keys work the same way everywhere.

This standard has been adopted across all apps. Writer, Timers, Flashcards, and C64 emulator all implement F1/F4 navigation.

What We Learned

1. Constraints Enable Creativity

336x536 monochrome display. 100 MHz CPU. No touchscreen. Physical keyboard only.

These aren't limitations—they're design decisions that force clarity. No room for bloat. No temptation to add unnecessary animations. Every pixel intentional.

2. Offline-First is Liberating

No API rate limits. No OAuth flows. No network error handling for cloud services. No terms of service that change. No sunset announcements.

Apps that work offline work forever. The Writer app written today will run on Precursor hardware in 2036. Can you say that about your cloud-dependent software?

3. Zero Telemetry is Freedom

No analytics integration. No crash reporting service. No A/B testing framework. No user tracking.

Build. Ship. Done. No dashboard to check. No metrics to optimize. Just software that works, used by people who value privacy.

4. Open Source Hardware Changes Incentives

Closed platforms optimize for vendor revenue. Open platforms optimize for user value.

Precursor's schematics are public. Firmware is auditable. If the vendor disappears, the platform continues. Community can fork, extend, maintain.

This changes everything about long-term software investment.

5. LLMs Accelerate, But Don't Replace, Understanding

Claude Code wrote significant portions of these apps. But the toolkit, the discoveries document, the keyboard standard—those required human insight.

LLMs are force multipliers for people who know what to build and why. They don't replace domain expertise. They amplify it.

Development Stats

Timeline: December 28, 2025 → January 25, 2026 (28 days)

Apps completed: 4
- Writer (Markdown editor, Journal, Typewriter)
- Flashcards (Multi-deck, TCP import)
- C64 Emulator (Full 6502, VIC-II, CIA keyboard)
- Timers (Pomodoro, Stopwatch, Countdown)

Development toolkit: xous-dev-toolkit
- Python automation scripts
- CLAUDE.md (LLM development guide)
- discoveries.md (API documentation)
- Screenshot capture pipeline

Lines of code (apps only, excluding toolkit):
- Rust: ~8,500 lines
- Python (scripts): ~1,200 lines
- Markdown (docs): ~3,000 lines

GitHub repos: 5 public repositories
Commits: 247 across all repos
Issues opened/closed: 18/14
Coffee consumed: 1.2 kg beans

Development environment:
- MacBook Pro M2 Max (ARM64)
- macOS 15.2
- VS Code + rust-analyzer
- Renode 1.16.0 (headless)
- Rust 1.88.0 + custom Xous sysroot

Cloud services used: 0
Telemetry added: 0
User accounts created: 0
Terms of service written: 0

What's Next

February 2026: LoRa Hardware Development

• Complete schematic and PCB layout (KiCad)
• Order prototypes via NextPCB Accelerator
• Test RAK3172 AT command interface
• Validate power consumption from Precursor battery

March 2026: Xous LoRa Driver

• UART driver integration (talk to RAK3172)
• AT command parser (send/receive LoRa packets)
• Encryption layer (ChaCha20-Poly1305 for P2P mode)
• Key management (PDDB-stored pre-shared keys)

April-May 2026: Meshtastic Integration

• Implement Meshtastic protocol (message routing, mesh topology)
• Build chat app (encrypted messaging over LoRa mesh)
• File sync app (Writer notes, Journal, Flashcards over mesh)
• Sensor logger app (receive telemetry from IoT nodes)

June 2026: Maelee's C64 Games

• Collaborative game development (design with Maelee, implement together)
• First game: "Hexmaze" (procedural dungeon crawler, monochrome-first design)
• Learn sprite animation, collision detection, procedural generation
• Open source release with development journal

Ongoing: App Refinements

• Writer: Syntax highlighting improvements, export templates
• Flashcards: Spaced repetition algorithm (SM-2), statistics dashboard
• C64: SID audio stub improvements (beeper output), disk drive emulation
• Timers: Statistics tracking, weekly Pomodoro summaries

Why This Matters Beyond Precursor

Proof of Concept: Private Computing is Viable

The narrative says privacy requires sacrifice. Secure devices are unusable. Offline software is limited. Auditable hardware is impractical.

These apps prove otherwise. Writer is more focused than Google Docs. Flashcards is simpler than Anki. Timers work better offline than web alternatives.

Privacy and usability aren't trade-offs. They're complements.

Open Source Hardware Enables Long-Term Investment

I'm building for a platform I can audit, modify, and maintain indefinitely. No planned obsolescence. No vendor control. No forced upgrades.

Software written for Precursor in 2026 will run in 2036. The platform won't change underneath me. The APIs won't be deprecated. The cloud service won't be sunset.

This is what sustainable software development looks like.

LLM-Assisted Development Unlocks Niche Platforms

Before LLMs, developing for a niche platform required months of manual documentation reading, trial-and-error debugging, and community forum archaeology.

With LLM assistance and proper tooling (the development toolkit), that timeline collapsed to weeks. The barrier to entry dropped by an order of magnitude.

This will unlock innovation on platforms that couldn't sustain traditional development costs. Open hardware becomes viable for smaller ecosystems.

Explore the Apps

All code is open source. All apps are free. Zero telemetry. Zero tracking. Zero cloud dependencies.

GitHub Repositories

• precursor-writer — Unified writing suite (Markdown, Journal, Typewriter)
• precursor-flashcards — Multi-deck flashcards with TCP import
• precursor-c64 — Commodore 64 emulator (6502 CPU, VIC-II, CIA)
• xous-dev-toolkit — Development methodology and automation scripts
• precursor-timers — Coming soon (integrating keyboard standard updates)

Showcase Page

colbysdatamovers.com/precursor-apps.html

Join the Precursor Ecosystem

If you care about:

• Auditable hardware (no proprietary black boxes)
• Offline-first software (works without internet forever)
• Zero-telemetry apps (your data stays on your device)
• Open source everything (forkable, maintainable, trustworthy)

...then Precursor is the platform to watch.

Get a Precursor

crowdsupply.com/sutajio-kosagi/precursor

Hardware designed by bunnie (Andrew Huang) and xobs. Proven track record (Novena, Chumby). Community-driven development. Open schematics. Auditable from silicon to UI.

Contribute to Xous

github.com/betrusted-io/xous-core

Microkernel OS written in Rust. Active development. Welcoming to contributors. Excellent architecture documentation.

Build Your Own Apps

Use the xous-dev-toolkit methodology. Read CLAUDE.md for LLM-assisted development patterns. Check discoveries.md for API gotchas.

Headless development on macOS ARM64 is now practical. The toolkit proves it.

Final Thoughts

January 2026 started with an empty PDDB and a fresh Precursor device. Four weeks later: four production apps, one comprehensive development toolkit, and a roadmap for wireless expansion that maintains zero-trust security.

This is what happens when hardware and software align on privacy as a core principle, not an afterthought.

Your smartphone will never respect you. Your laptop will always phone home. Your smart devices will always spy.

But platforms like Precursor prove another way is possible. Auditable. Offline. Private. Owned by you.

The future of personal computing doesn't require sacrificing privacy. It requires choosing platforms that prioritize it.

Welcome to that future.

— Tyler Colby, January 25, 2026