DEV Community: webxos

Openwiki and the FEED - 2 new apps for free that aim to take out larger competitors

webxos — Sat, 31 Oct 2026 20:23:15 +0000

The web is full of polished, account-heavy platforms that intermediate between you and information. Wikipedia is free in theory but wrapped in ads, tracking, and slow interfaces on many devices. News feeds are algorithmically shaped, personalized for engagement, and locked behind logins or paywalls.

Two new single-page apps from webXOS push hard in the opposite direction: OpenWiki and THE FEED. Both are free, local-first, zero-account tools that run entirely in your browser. They cache everything on-device in IndexedDB, talk only to public keyless APIs, and never send your queries, history, or interests to a central server.

They don’t claim to “replace” Wikipedia or Google News overnight. They do something more interesting: they remove the intermediary layer that most people have accepted as normal.

THE FEED – Local-First News Engine

URL: https://agentowl.netlify.app/feed

THE FEED is a news reader that fans out across public sources, ranks stories by recency plus your saved interests, and keeps the entire dataset on your device.

Core idea: No accounts. No tracking. No keys. Everything lives in the-feed-v1 IndexedDB.

Default sources (all toggleable):

RSS via public CORS bridges: BBC World, BBC Tech, NPR News, Al Jazeera, The Verge, Ars Technica, TechCrunch, Wired, Hacker News RSS, Lobste.rs
Hacker News Firebase
JSON APIs: GitHub Trending, Dev.to, Spaceflight News

You can turn any of them off. The app still works with a single source.

How ranking works
Results are ordered by a combination of recency and the interests you have saved. There is no black-box engagement model optimizing for time-on-site. What you mark as interesting becomes the signal.

Interface & controls

Clean dark terminal-style UI
Search box (leave blank for latest)
Sort toggle (ALGO)
Refresh
Saved articles counter
Keyboard shortcuts: / focuses search, Esc closes modals
Color invert, fullscreen, clear database (with confirmation), settings, about

Everything you touch is cached locally. Health indicators show source status. The app is currently at v2.3.1.

Why this matters
Most news products either (a) require an account so they can profile you, or (b) are pure RSS readers that give you zero ranking intelligence. THE FEED sits in the middle: public sources + local ranking + local storage. No middleman owns your reading history.

OpenWiki – Local-First Wikipedia Engine

URL: https://agentowl.netlify.app/openwiki

OpenWiki turns Wikipedia’s public APIs into a fast, private, infinite-scroll research tool that improves the more you use it.

Core idea: Search Wikipedia, cache every article you touch, and rank results with a hybrid of deterministic vectors and (optional) on-device embeddings. Nothing leaves the browser except the API calls to en.wikipedia.org.

The pipeline

Search fans out to:
- action=query&list=search (paginated with continue for infinite scroll)
- action=opensearch
- Batched REST summary fetches
Results are deduplicated and scored with JEV (JSON Entity Vector).
Optional MiniLM embedder (via transformers.js) can be turned on for hybrid ranking: 0.35·JEV + 0.65·MiniLM.
Everything is stored under openwiki-v1 in IndexedDB.

JEV – the interesting technical piece
JEV is a 512-dimension float vector computed deterministically from text. It uses position-weighted unigrams, bigrams, trigrams, and character 3-grams of longer tokens, all hashed into a shared space, weighted, and L2-normalized. Ranking becomes a simple dot product. No model download required for the base experience. MiniLM is additive, never a replacement.

Privacy model

Only outbound traffic: Wikipedia’s public read-only APIs + (optional) jsDelivr for MiniLM weights.
Weights are cached by the browser and run entirely on-device.
No OpenAI, Anthropic, Google, or any closed endpoints.
No account, no tracking, no server-side storage.

Shared Philosophy: The OWL Family (agentowl.netlify.app)

Both tools belong to the same family of local-first apps from webXOS:

THE FEED – news
OpenWiki – Wikipedia
knOOgle – keyless meta-search across public APIs
owl: arcr – prompt architect (Action → Role → Context → Response)
OWL Agent – decision-augmented research agent (single HTML file)

Common traits:

Single-file or near-single-file web apps
IndexedDB as the primary datastore
Zero accounts / zero tracking
Public keyless sources only
Export everything (Markdown, JSON, CSV, etc.)
Optional donations via Buy Me a Coffee (never required, never unlocks features)

How They Challenge Larger Competitors

Dimension	Typical Big Platform	OpenWiki / THE FEED
Data ownership	Platform owns history & profiles	You own everything in IndexedDB
Ranking	Engagement / ad optimization	Recency + your explicit interests / deterministic + local embeddings
Privacy	Tracking by default	No tracking possible
Offline / local	Limited or none	Full cache, works after first fetch
Monetization	Ads, subscriptions, data	Free + optional tip jar
Lock-in	Account required	None

They don’t have the scale of Google or the depth of Wikipedia’s full media layer. What they have is a radically simpler trust model and a performance profile that gets better the longer you use them (because the local cache grows).

For developers, researchers, and privacy-conscious readers, that trade-off is attractive.

Final Thought

Most “alternative” tools still sit on someone else’s infrastructure and still want an account. OpenWiki and THE FEED take the harder path: pure client-side, public APIs only, and your browser as the only server that matters.

They won’t displace the giants tomorrow. But they prove that a serious, usable, free information layer can exist without the usual compromises. That alone is worth paying attention to — and, if they save you time, buying the developer a coffee.

Try them. Cache a few dozen articles or a day’s worth of news. Notice how the experience changes once the data lives with you instead of with a platform.

Links

THE FEED → https://agentowl.netlify.app/feed
OpenWiki → https://agentowl.netlify.app/openwiki
webXOS family → https://agentowl.netlify.app

Kernel Bypass Networking: A Deep Dive into Mechanisms, Trade-offs, and the Future

webxos — Wed, 28 Oct 2026 19:53:52 +0000

The original exploration of kernel bypass networking touched on the essentials: userspace drivers, poll-mode polling, and the loss of kernel safety nets. But a surface-level view misses the fascinating tension in modern systems programming. Why do we keep reinventing the network stack? What exactly are we trading away, and for whom?

This expanded analysis dives into the microarchitectural battlegrounds, the operational realities of cloud-native deployments, and the open research questions that suggest kernel bypass is not a destination, but a spectrum of compromises.

The Core Problem: Why the Kernel Fails at 400 Gbps

To understand the bypass, you must understand the bottleneck. The traditional Linux network stack was designed for generality, not for the extreme packet rates of modern data centers. At 400 Gigabit Ethernet, the packet arrival rate for minimum-sized (64-byte) frames hits approximately 595 million packets per second (Mpps). This leaves a budget of just 1.68 nanoseconds per packet .

The kernel's processing path is dominated by socket buffers (sk_buff), netfilter rule traversals, softirq context switches, and per-core atomic lock contentions. Under these hyper-scale line rates, classical kernel processing "completely collapses," saturating CPU cores at fewer than 15 Mpps per core . Even with optimizations like non-blocking I/O, a single core on a 100 Gbps link might only achieve 20-25 Gbps, requiring 4 to 8 cores just to saturate the link . This inefficiency is the driving force behind every kernel bypass technique.

The Mechanisms: From Brute Force to Surgical Precision

Kernel bypass is not one technology; it is a spectrum ranging from completely evicting the kernel to running safe, programmable code at the earliest possible hook point.

User-Space Drivers (DPDK): The Brute Force Approach

The Data Plane Development Kit (DPDK) represents the classic "full bypass" model. It provides a set of libraries and poll-mode drivers (PMDs) that allow an application to take exclusive control of a NIC queue . The application spins on the hardware ring, eliminating interrupts, context switches, and memory copies.

The Win: DPDK delivers the highest raw throughput and lowest latency. In 400G benchmarks, DPDK achieved 542 Mpps across 32 cores, outperforming in-kernel alternatives by roughly 14.8% with 210 ns lower median latency .
The Cost: This performance comes at a severe operational price. DPDK burns 100% of a CPU core even at zero traffic (idle polling), consuming over 350W continuously in some configurations . It also completely isolates the NIC from the Linux kernel, breaking standard tools like ethtool, tcpdump, and native container networking .

In-Kernel Fast Paths (eBPF/XDP): The Surgical Strike

The eXpress Data Path (XDP) takes a fundamentally different approach. Instead of leaving the kernel, it runs eBPF bytecode inside the kernel driver, immediately after the packet is received from the hardware ring, before the expensive sk_buff allocation occurs .

The Mechanism: An XDP program returns a verdict: XDP_DROP, XDP_PASS, XDP_TX, or XDP_REDIRECT. For bypassing to userspace, the XDP_REDIRECT action can send packets to an AF_XDP socket. AF_XDP is a specialized socket that uses shared memory rings (UMEM) to allow zero-copy packet transfer between the kernel and a userspace application, bypassing the traditional stack while remaining a "first-class citizen" of the kernel .
The Win: XDP is not a true bypass; it is an integrated fast path. It preserves kernel routing and security semantics. Benchmarks show it achieves 3.82x higher energy efficiency under variable loads because it can drop into an interrupt-driven mode when idle, eliminating the PMD waste of DPDK . Crucially, it limits L3 cache pollution and DDIO thrashing on co-located applications by 62.4%, making it far friendlier to multi-tenant Kubernetes nodes .

The New Wave: Middleware and Unified APIs

The fragmentation between DPDK, XDP, and RDMA is a major barrier. New research proposes middleware like INSANE, which uses a sidecar architecture to abstract these backends. Developers specify QoS requirements, and the middleware dynamically maps traffic to the best available stack (e.g., DPDK for raw throughput, XDP for integrated filtering) without changing application code .

The Trade-offs: What You Actually Give Up

The JSON iterations repeatedly touched on "trade-offs and pitfalls." The research confirms these are not minor inconveniences; they are fundamental architectural constraints.

1. The Density and Compatibility Wall (The Cloud Killer)
In cloud environments, density is king. Traditional kernel bypass systems are terrible at density. Because they rely on busy-spinning and dedicated cores, you need at least one core per instance. Furthermore, the memory overhead is staggering. Systems like Caladan reserve 648 MB for a single core and scale to only about 200 instances on a 128GB machine. Demikernel uses 167 MB per instance. In contrast, Junction (a newer approach) reduces single-core memory overhead to 29 MB and scales to 3,500 instances .

Compatibility is an even bigger hurdle. Existing bypass systems require applications to be ported. A survey of serverless functions found that Node and Python are among the most popular languages, yet these runtimes have complex OS dependencies that existing bypass systems cannot satisfy. Most state-of-the-art systems support only a handful of C/C++ key-value stores .

2. The Protocol Reality Check
Bypassing the kernel means you often bypass its mature TCP/IP stack. While raw packet processing (L2/L3) is straightforward, implementing a full, correct TCP stack in userspace is "hard" . A 2025 USENIX study compared six kernel-bypass TCP stacks and found that existing stacks cannot handle both bulk data transfers (hundreds of gigabits) and small request-response messages (low latency) simultaneously, or they lack generality . Even for modern protocols like QUIC, which runs in userspace by default, integrating DPDK can yield a 3x speedup (exceeding 10 Gbit/s), but the performance increase is highly implementation-dependent and can sometimes fail to improve at all .

3. The Loss of Operational Sanity
The kernel provides a shared, observable, and secure environment. Bypass shatters this. DPDK requires hugepages, specific NIC firmware, and a debugging workflow that doesn't involve standard sockets . eBPF/XDP, while better, still requires a separate compilation toolchain and verification step. The operational friction is a major reason why these technologies, despite their maturity, remain "hard to integrate into higher-level systems" .

Open Questions and the Path Forward

The exploration of "open questions" reveals that the industry is not converging on a single winner but rather learning to hybridize.

Question 1: How do we make bypass transparent?
The ideal solution is one where unmodified applications automatically benefit from the fast path. Projects like Joyride propose replacing the Linux network stack with a userspace framework that intercepts LibC calls, offering full compatibility without code changes . Junction aims for the same goal with a focus on cloud density, using a shared-memory design to support thousands of instances .

Question 2: How do we balance raw speed with CPU efficiency?
The pure DPDK model of burning cores is unsustainable for general-purpose clouds. The future lies in adaptive models. eBPF/XDP's ability to fall back to the kernel when idle is a step in the right direction . Research into reactive notifications (like the Enso NIC) attempts to solve the busy-polling waste by having the NIC only interrupt the CPU when software signals it is ready to process packets, adapting notification rates to consumption speed .

Question 3: How do we secure the bypass?
When you take the kernel out of the data path, you take away its security guarantees. Userspace drivers and mapped device memory enlarge the trust boundary. The Spectre/Meltdown era demonstrated that hardware isolation is porous. Any bypass framework must now consider how to implement firewalling, connection tracking, and tenant isolation in userspace, or face severe limitations in multi-tenant environments.

The Bottom Line

Kernel bypass networking is not a binary choice between "fast and dangerous" and "slow and safe." It is a design space defined by the specific bottleneck you are trying to eliminate.

Choose full userspace bypass (DPDK) when you have a dedicated, latency-obsessed workload (e.g., 5G UPF, market data feed handlers) where the operational cost of burning cores is acceptable, and you are willing to accept complete isolation from the host OS.
Choose an integrated fast path (eBPF/XDP/AF_XDP) when you need high performance but must coexist with Kubernetes, standard monitoring tools, and multi-tenant co-location. It offers a "good enough" performance profile with vastly superior operability .
Watch the middleware layer as the real enabler. The future of high-performance networking may not be choosing a bypass stack, but rather using a system that chooses the stack for you, dynamically, based on the QoS contract of the moment .

The kernel is not dead; it is being specialized. The art lies in knowing precisely which parts of its workload you can afford to hand over, and to whom.

The Quiet Power of Hard and Boring Software in 2026

webxos — Tue, 27 Oct 2026 09:15:51 +0000

Building “hard and boring” software usually means developing foundational, high-reliability infrastructure or data-heavy systems where failure is catastrophic, glamour is zero, and edge cases rule your life. These projects demand rigorous systems-level thinking rather than trendy frameworks. In an era of AI agents that can scaffold entire applications in minutes, the real engineering work has quietly shifted back to the unglamorous layers that keep the world running.

What Counts as Hard and Boring Software

Hard and boring software is the opposite of a flashy product demo. It is the code that must work correctly under every possible failure mode, for years, with limited human attention. The categories that still feel brutally difficult in late 2026 include:

Job Schedulers & Distributed Cron

Systems that schedule compute-intensive, long-lived, or non-deterministic tasks. You need reliable completion estimates, robust instrumentation, and ironclad handling of race conditions and deadlocks. In 2026 these systems increasingly orchestrate GPU fleets and agentic workflows. The hard part is no longer “run this every night”; it is “guarantee this 14-hour training job finishes with correct results even when half the cluster flaps and the model weights are streaming from object storage.”

Legacy System Migration & COBOL Parsers

Rewriting or maintaining decades-old banking, insurance, and government systems that grew organically with almost no documentation. The industry still runs on COBOL for core ledgers. Modern efforts often involve AI-assisted reverse engineering, but the real difficulty remains understanding the original business invariants and proving the new system preserves them under every regulatory scenario.

General-Purpose Databases & Storage Engines

Writing a database from scratch (or deeply modifying one) forces you to confront memory reclamation, concurrency primitives, cache-line effects, and query optimizers. Even in 2026, most “new” storage systems are still fighting the same fundamental problems Postgres and Linux have been solving for decades. The teams that succeed treat the boring parts—durability, consistency under partial failure, and predictable performance—as the product.

Compliance-Driven ERP & Tax Engines

Software bound to constantly shifting cross-border taxation, financial regulations, and multi-party SaaS supply-chain integrations. These systems must remain correct when the law changes overnight. Edge cases are not rare; they are the daily business of the software.

Interactive Data Visualization & Memory Caching under Constraints

Managing large multivariate geospatial or time-series datasets with severe real-time performance and memory limits. The hard work is not the pretty chart library; it is the cache hierarchy, the incremental update algorithms, and the ability to keep interactive latency under control when the data set is larger than RAM.

These domains share a common trait: the cost of being wrong is measured in money, legal liability, or human safety, not in lost engagement metrics.

Why Choose Boring Technology in 2026

Dan McKinley’s 2015 essay “Choose Boring Technology” remains one of the most useful mental models in software engineering. The core idea is simple: every organization has a limited number of innovation tokens. Spend them on the parts of the system that differentiate your product. Everywhere else, choose technology whose failure modes are already well understood.

Eleven years later the principle has only grown stronger. Several forces make boring technology even more valuable today:

AI agents dramatically lower the cost of creating infrastructure and application code. They do not lower the cost of owning it. Day-1 velocity has exploded; Day-2 operational complexity has often increased.
Teams that adopted microservices and Kubernetes at scale are consolidating back toward simpler architectures. Surveys in 2025–2026 show a clear retreat from fine-grained service meshes and a renewed appreciation for well-structured monoliths and modular monoliths running on proven platforms.
Observability, security, and compliance requirements have become stricter. Technology that already has mature tooling for these concerns wins by default.
The most durable systems in production today still rest on Linux, Postgres, C, SQL, and carefully written shell and Python. These technologies continue to absorb new requirements (vector search via pgvector, better concurrency primitives, improved observability) without forcing a rewrite of the surrounding application.

Boring does not mean stagnant. It means the changes are visible and the failure modes are documented. A dependency that updates every two weeks in unpredictable ways is not boring, even if it is popular. A system whose behavior under load, under network partitions, and under partial disk failure is already known is boring—and therefore valuable.

Modern Concepts Applied to Hard Problems

The interesting work in 2026 is not inventing yet another framework. It is applying mature systems thinking to new constraints:

Agentic orchestration on boring foundations. Many teams now run AI agents that schedule and monitor long-running jobs. The agents themselves are often built on top of ordinary job queues, Postgres, and carefully instrumented workers rather than exotic orchestration platforms.
Workload-first infrastructure. Cloud-first thinking is giving way to explicit decisions about where each workload should run—public cloud, private infrastructure, edge, or GPU-as-a-service—based on latency, data residency, cost, and utilization characteristics.
AI as infrastructure rather than spectacle. The most successful uses of models treat them as just another component with known performance and failure characteristics, integrated into existing reliability practices instead of treated as magical black boxes.
Operational continuity as a first-class concern. Systems must continue functioning when the current infrastructure fails, when a vendor changes terms, or when a key person leaves. This favors designs with low bus factor and high observability.

The teams that thrive are those that treat reliability, operability, and long-term maintainability as product features rather than afterthoughts.

Getting Started (or Digging Deeper)

If you want to work on or build this kind of software, the path is rarely glamorous but highly transferable:

Prefer languages and runtimes with strong operational tooling and long-term stability (Go, Rust, Java, modern C++, Python with careful packaging).
Master the fundamentals of concurrency, distributed systems failure modes, and storage engines.
Spend time reading the source of systems you already use (Postgres, Linux, Redis, your current job scheduler).
Practice writing software that must survive real production conditions rather than demos.

The questions that matter most right now are practical:

Are you looking for a personal project idea that forces deep systems thinking, an enterprise architecture challenge that will still matter in five years, or something that simply automates a tedious but critical workflow?

What programming languages or systems environments do you already prefer to work in?

Hard and boring software is where the highest leverage still lives. In 2026 the shiny tools can generate the first version of almost anything. The engineers who can make the second, third, and tenth version remain correct, operable, and economical are the ones solving the problems that actually matter.

Universal Bio.md Guide: A Living Unified Agent Memory System

webxos — Tue, 27 Oct 2026 08:30:14 +0000

Local agents are finally growing up.

In the past year we’ve seen a wave of sophisticated harnesses — Hermes, Pi, Ghostyy, OpenClaw, Claude Code-style systems — all trying to give models a persistent sense of self. Most of them still scatter identity, memory, skills, and context across multiple files or databases.

bio.md collapses that complexity into a single living Markdown file.

This October 2026 release formalizes the pattern as a language-agnostic standard that works with any agent harness (Python, JavaScript/TypeScript, Rust, Go, C/C++, or pure shell) and pairs especially well with local Ollama models on Debian-based systems. Everything stays offline, sandboxed, and under your control.

Core Concept

bio.md is the agent’s biological ledger — one self-updating Markdown file that serves as the single source of truth for:

Identity and behavioral constraints (SOUL)
Reusable capabilities (SKILLS)
Curated long-term knowledge (MEMORY)
Live runtime state (CONTEXT)
Conversation branching (SESSION TREE)

Every user interaction is treated as a “heartbeat.” The harness appends a lightweight log entry, updates the timestamp, and periodically consolidates new information into the living document. The entire file (or its key sections) is injected as the system prompt on every Ollama call.

The result feels closer to a persistent, self-aware agent than a stateless chat session — even when running on a 0.5B model.

Recommended Folder Structure

On first launch the harness should bootstrap this layout automatically:

~/.my-agent-harness/          # or any root you choose
├── bio.md                    # the single living file
└── data/
    ├── logs/
    │   └── heartbeat.log     # raw interaction log
    ├── skills/               # generated reusable scripts
    ├── sessions/             # branchable conversation history
    ├── memory_index/         # optional lightweight index
    └── context/              # system state snapshots

Bootstrap rule: If the root folder or bio.md is missing, create them with a clean template. Zero-setup for new users.

The bio.md Template

# BIO.MD – Living Agent Identity
**Last Updated:** 2026-10-27T04:28:00
**Agent Role:** Local Assistant

## SOUL
Core personality, values, constraints, and behavioral rules.
- You are a local-only agent running on Ollama with no internet access.
- Stay sandboxed and respect the host system’s security.
- Personality traits: concise, reflective, self-improving, helpful.

## SKILLS
Reusable capabilities and how-to instructions (auto-populated by the harness).

## MEMORY
Curated long-term knowledge and history.
- User Preferences & Facts
- Learned Skills
- Past Interactions (summarized)

## CONTEXT
Current runtime state.
- Operating System: Debian Linux
- Working Directory: /path/to/project
- Recent System Changes: …

## SESSION TREE
Pointers or summaries of active conversation branches.

Heartbeat & Update Flow

User interaction = heartbeat

Append a short entry to data/logs/heartbeat.log, update the timestamp in bio.md, and optionally note the interaction in MEMORY or SESSION TREE.
Automated consolidation

A simple memory-sync.sh script (run hourly via cron) reads recent heartbeats, asks a small local model (e.g. qwen2.5:0.5b) to summarize them, appends the summary to MEMORY, and prunes the raw log.
Real-time context (optional)

Use inotify-tools or light polling to keep the CONTEXT section fresh when relevant files change.
Injection into Ollama

Always load the current bio.md as the system message. In practice this looks like:

BIO_CONTENT=$(cat bio.md)
curl -s http://localhost:11434/api/chat -d "{
  \"model\": \"qwen2.5:0.5b\",
  \"messages\": [
    {\"role\": \"system\", \"content\": $(jq -Rs . <<< \"$BIO_CONTENT\")},
    {\"role\": \"user\", \"content\": \"Your user message here\"}
  ]
}"

The same pattern is trivial in any language: read the file and prepend it as the system role.

Implementation Guidelines (Any Language)

Bootstrap the folder structure and initial bio.md on startup.
Load bio.md at the beginning of every turn (or keep a smart cache).
After each response: append heartbeat → light memory update → timestamp refresh.
Keep tools strictly local and sandboxed (whitelisted subprocesses only).
Prefer incremental edits over full rewrites.
After successful tasks, analyze the trace, generate or refine skills in data/skills/, and update the SKILLS section.

Advanced Features You Can Layer On

Multiple isolated agents via sub-folders (each with its own bio.md)
systemd daemon mode with nightly “autoDream” consolidation
Minimal agent loop (Think → Tool Call → Observe → Repeat)
Branchable session trees stored as JSONL and referenced from bio.md
Context compression that periodically folds long MEMORY sections
Simple TUI or local dashboard that shows live bio.md state

October 2026 Enhancement: Bioinformatics-Inspired Dynamic Programming

This month’s major upgrade integrates classic dynamic programming techniques from computational biology directly into the bio.md architecture.

We now treat the agent’s internal state as a bioinformatics dataset. Soul, skills, memory, and sessions become sequences that can be optimally aligned, folded, and scored.

Key ideas borrowed from the field:

Sequence alignment (Needleman-Wunsch / Smith-Waterman style) for inserting new heartbeats with minimal redundancy
Optimal substructure for memory consolidation
Binding-affinity scoring for skill refinement
Folding-style compression for long context histories
Phylogenetic-tree thinking for session branch optimization

Internally the harness maintains a lightweight JSON layer alongside the human-readable Markdown:

{
  "bioinformatics_metadata": {
    "last_updated": "2026-10-27T04:28:00",
    "dp_score": 0.892,
    "compression_ratio": 0.67,
    "alignment_score": 0.945
  },
  "skills": [
    {
      "name": "memory_consolidation",
      "dp_binding_affinity": 0.91,
      "description": "Uses DP to align new heartbeats with existing knowledge"
    }
  ]
}

The updated heartbeat flow becomes:

Append raw heartbeat
Run DP alignment against current memory
Compute optimal merge
Update both the Markdown summary and the JSON metadata

This dramatically improves context efficiency — especially valuable when you are running on tiny local models.

Benefits

True persistence across reboots and power cycles
Single source of truth instead of scattered files
100% local and private
Works well even with 0.5B-class models because the harness does the structural heavy lifting
Portable across any language or harness
Continuously self-optimizing via the same algorithms that power modern bioinformatics

Quick Start Checklist

On first launch: create the folder structure and seed bio.md.
Every turn: load bio.md → call Ollama → execute tools → append heartbeat → light update.
Ship a memory-sync.sh and document the cron entry.
Make the SOUL section easy to customize.
Test first with the smallest models you have.

bio.md turns a basic local LLM into something that feels alive. It consolidates the best persistent-memory and self-improvement ideas from the current generation of agent harnesses into one clean, file-based system that you can drop into any project.

Implement the bootstrap + heartbeat + consolidation loop (and optionally the new DP layer), and your agent will start to feel significantly more coherent and capable — even on modest hardware.

Dev update

webxos — Mon, 26 Oct 2026 19:03:28 +0000

webxos

Oct 26

Dev Update: October 2026

#architecture #softwaredevelopment #softwareengineering

4 min read

Dev Update: October 2026

webxos — Mon, 26 Oct 2026 18:53:03 +0000

webxOS - The Edge-Native Ecosystem

Dev Update: October 2026

(agentowl.netlify.app/openwiki as shown in the photo)

• The Problem: Today's software ecosystem is completely dependent on centralized cloud architecture. This reliance creates data monopolies, introduces high server costs, introduces security vulnerabilities, and breaks the moment a user loses network connection.

• Paradigm Shift: Software shouldn't require a constant data pipeline back to corporate servers just to function.

• Solution: A completely decentralized, edge-native web suite that operates entirely on-device inside a single browser tab. No accounts, no servers, no cookies, and no tracking.

Slide 2: The Core Product Suite Overview

Five Tools, One Shared Philosophy: Zero Server Dependencies

We have built five foundational browser applications that prove local-first compute is capable of replacing cloud infrastructure:

webXOS: A complete windowed web desktop and application framework operating at the edge.
OWL Agent: A decision-augmented, auto-research and planning AI agent running entirely client-side.
knOOgle: A keyless, tracking-free meta-search engine featuring local semantic re-ranking.
owl: arcr: A highly precise prompt architect utilizing the structured Action → Role → Context → Response protocol.
OpenWiki: A local-first Wikipedia engine utilizing deterministic JSON Entity Vectors (JEV) and lightweight on-device language models.
Slide 3: webXOS

An Operating System in a Single HTML Document

• The Entrypoint: Accessible at webxos.netlify.app and open-sourced at github.com/webxos.
• Architecture: It launches a modular, windowed desktop sandbox from a static index page.
• Built-in Applications: Ships with a terminal, file manager, text editor, markdown workspace, graphics drawer, and hardware telemetry panel.
• Data Lifecycle: Completely ephemeral by design. It writes exclusively to IndexedDB and localStorage. When the browser tab is closed, the sandbox database is wiped clean, leaving zero footprint. Users maintain absolute ownership of data by downloading state as localized JSON configuration files.

Slide 4: OWL Agent — Autonomous Local Intelligence

Deep AI Research and Planning Without an Inference Bill

• The Application: Live at agentowl.netlify.app.
• Keyless Fan-out Engine: Processes natural language by expanding queries into multiple sub-variants and distributing them across 24 free, public, keyless APIs simultaneously.
• The Local Decision Kernel: Passages are scraped and mathematically scored on-device based on criteria like overlap, freshness, depth, and structural source trust. Contradictions or points of strong consensus are identified natively.
• Zero-Server Inference: Employs an on-device 384-dimension vector embedder and an optional 77M parameter model for text generation. It provides deep research summaries and domain-aware step-by-step plans completely offline once the page has loaded.

Slide 5: knOOgle — Restoring the Clean Web

What Search Engines Should Have Been

• The Application: Live at agentowl.netlify.app/knoogle.
• The Interface: A minimalist layout containing one search bar, two buttons, and zero algorithmic clutter.
• On-Device Semantic Re-ranking: Fans out queries safely across keyless index sources. Reranks relevance using a local MiniLM model or an instantaneous native hash embedder to compare cosine similarities right in the tab.
• Agent Optimization: Built intentionally to be an agent-friendly search surface. It supports URL parameters, automatic JSON result rendering, and customizable webhooks so external autonomous agents can scrape clean payloads instantly without hitting corporate API limits.

Slide 6: owl: arcr — The Prompt Architect

Deterministic Prompt Engineering and Machine-Readable Workflows

• The Application: Live at agentowl.netlify.app/arcr.
• The ARCR Protocol: Moves prompt design away from guesswork into an engineering workflow by structuring prompts into:
• Action: The imperative verb.
• Role: The required expertise persona.
• Context: Detailed background grounded by a live research engine fan-out.
• Response: The precise output constraint.
• JSON Graph Format (JGF): Emits finished prompt templates as machine-parseable graphs mapping the absolute relationship between roles, contexts, definitions, and underlying source nodes. It integrates seamlessly into automated software development agent pipelines.

Slide 7: OpenWiki — Local-First Encyclopedic Engine

Caching and Correlating

• The Application: Live at agentowl.netlify.app/openwiki.
• JEV Determinization: Introduces the JSON Entity Vector (JEV)—a fast, 256-dimension float vector generated purely mathematically from raw unigrams and bigrams. This allows thousands of cached Wikipedia documents to be indexed and filtered instantaneously with simple dot-product operations, requiring no heavy neural networks.
• Smart Synthesis Loops: Caches full-text extracts into local browser storage. When a user aggregates multiple documents, a localized 0.5B parameter language model safely runs on-device via transformers.js, strictly constrained to synthesize summaries using only facts found in the cached source extracts.

Slide 8: Market Opportunity & The Decentralized Tech Stack (Future outlook, concepts only)

The Intersection of High Compute Cost and Privacy Exhaustion

• The Infrastructure Crisis: Centralized LLM providers are burning through capital trying to sustain global server infrastructure. Running basic searches shouldn't cost millions in electricity.
• Our Market Advantage: By shifting execution to customer hardware, we drive marginal infrastructure costs to zero.
• The Privacy Mandate: Enterprises, health institutions, legal operations, and security teams are legally blocked from leaking proprietary data to public clouds. Our stack ensures that raw text, vectors, code repositories, and research structures never leave the boundaries of the employee's browser tab.

Slide 9: Monetization, Traction, and Scale (Future outlook, concepts only)

Open-Source Adoption Backed by Client-Side Software Delivery

• Distribution: Currently distributed completely unbundled as a single-page app (SPA) ecosystem.
• Current Metrics: Growing developer traction on github.com/webxos with core repositories covering modular POSIX-like browser shells, autonomous agent harnesses, and multi-agent systems.
• Business Model:
• Free Demo Tier: Full software capabilities with a simple rolling request limit for cross-network API queries to prevent network spam.
• Commercial Pro Tier ($10/Month): Unlimited client-side research cycles, local execution, and dedicated developer tool sandboxing.
• Enterprise Distribution: Whitelabel self-hosted enterprise configurations deployed entirely behind private firewalls on absolute sovereign hardware.

knOOgle: A Local-First Search Engine Built for Developers and the Open Web

webxos — Sun, 25 Oct 2026 14:31:15 +0000

Try it Live at https://agentowl.netlify.app/knoogle.

knOOgle launched on October 24, 2026, as a deliberately minimalist alternative to mainstream search. Positioned as “what Google would have been in 1999 if it had been built for the open web instead of the ad web,” it delivers a single search box, two buttons, zero clutter, and results pulled exclusively from free, keyless public APIs—all running entirely in your browser.

Core Idea
knOOgle is a client-side meta-search tool. Your query fans out in parallel across a curated set of open data sources. Results are ranked, filtered for safety, optionally re-ranked with on-device embeddings, and stored locally in IndexedDB. You can export everything to Markdown or JSON. There is no account, no server-side index of your searches, no tracking, and no contact with OpenAI, Anthropic, or Google endpoints.

Feature Breakdown

Sources (toggleable)

Wikipedia, Wikidata, Open Library, Datamuse, Free Dictionary, REST Countries, OpenAlex, Crossref, Semantic Scholar, Europe PMC, PubMed, DOAJ, Zenodo, arXiv, Hacker News, Lobsters, Dev.to, GDELT, npm, PyPI, Stack Overflow, GitHub, crates.io, CoinGecko, Frankfurter, and more. Developers get first-class access to package registries, code repositories, academic papers, and community forums.

Example: Dev.to as one of the APIs

knOOgle includes the Dev.to public API as a native source. When enabled, searches return recent posts from the developer blogging platform. For instance, a technical query can surface articles such as this Dev.to post directly in the ranked results, complete with title, snippet, URL, and source attribution. This makes it easy to pull practical developer writing alongside GitHub repos, npm packages, arXiv papers, and Stack Overflow threads without leaving the same clean interface.

Ranking & Relevance

Results combine keyword overlap, freshness, safety signals, and spam scoring. Optional semantic re-ranking uses a lightweight local 384-dimension hash embedder. You can also opt in to a real on-device sentence-transformer model (~22 MB) that runs entirely in the browser.

Local-First Storage & Export

Every interesting link is saved in IndexedDB under knoogle-v1. One-click export produces Markdown or JSON. The entire application stays under 300 KB.

Slash Commands

/help, /webhook <url>, /embed [on|off|status], /stats, /saved, /history, /settings, /export [md|json], /json, /discovery, /clear, and others.

Agent & Developer Integration

knOOgle is explicitly agent-friendly:

?q=<query> — auto-runs the search
?q=<query>&format=json — returns structured JSON
?webhook=<https-url> — POSTs results to your endpoint
Discovery files via llms.txt and agent-search.json
Schema.org markup for easy bot detection

A minimal Playwright snippet is provided for headless use.

Privacy Model

Only the query text leaves the browser, and only to the APIs you explicitly enable. No cookies, analytics, telemetry, or accounts.

Who It’s For

Developers who want package, GitHub, Stack Overflow, Dev.to, and arXiv results without ad noise
Privacy-conscious users and researchers who prefer local control
AI agent builders who need a lightweight, keyless, JSON-native search surface

Limitations
knOOgle is not a full-web crawler. Coverage is limited to the public APIs it queries. It shines for technical, academic, and open-data queries.

knOOgle is not trying to be the next Google. It is a focused, browser-native instrument for searching the parts of the web that still publish open, keyless data—exactly the surfaces many developers care about most.