bettyd: The Local-First Engine of the BeTTY Network.
It's BeTTY UN*X daemon, the local process which serves, stores, and maintains your data in bettyland.
bettyd encrypts, indexes, and federates data for the BeTTY ecosystem.
It serves as both the heart of a local BeTTY node and the substrate for interoperable communication across the network.
Running quietly in the background, bettyd handles all data persistence, access control, and peer synchronization.
At its heart, bettyd turns your local machine into an intelligent, privacy-preserving data node capable of hosting, querying, and sharing BettyDocs across trusted peers.
It's the lightweight, modular, foundational layer that brings the open Semantic Internet to life.
The goal of bettyd is to provide a trusted foundation for the semantic internet, allowing both humans and machines to store and exchange meaningful information without centralization or lock-in.
bettyd runs as a lightweight service that handles BeTTY API calls for all local applications, from the command-line via btty, to web clients through httbd, and directly to the rest of bettyland via the LUMA API.
Every bettyd instance operates independently yet speaks a shared protocol, allowing for seamless, secure federation across devices, teams, and institutions.
Your node is both sovereign and connected—local by design, global by intent.
bettyd integrates a modular storage backend, semantic graph engine,
and REST-like API, allowing developers to plug in new data systems or
query layers with minimal effort.
The BeTTY network (a.k.a. "bettyland") functions as a federated data lake, composed of all bettyd nodes (even when they're offline; it's kind of a quantum network in that way).
Each node maintains its own local data warehouse that synchronizes, indexes, and exchanges metadata with other trusted peers.
This design follows the emergent data lakehouse model. The big data concepts of the data lake (a large, undifferentiated repository of raw data) and the data warehouse (a large, well maintained store of schema-conformant data) have been combined into the popular data lakehouse model.
The global BeTTY network forms the "lake," a shared semantic fabric of discoverable knowledge. Your local bettyd instance forms the "house," a curated, high-integrity subset of the data, maintained for your needs and permissions.
The result is a scalable, searchable, and decentralized system that never sacrifices user control or data locality.
The system inherits the simplicity of UNIX and the semantics of the Web,
combining line-based text storage (as in ndjson) with
JSON-LD for linked meaning.
Through nbson,
all data is stored compressed and encrypted at rest.
Under the hood, bettyd translates every LUMA call into coordinated actions across its internal nbson data lakes.
Each lake is a namespace within the node's local nbson store, and together they form the data lakehouse providing both fluid document mobility and consistent, queryable state.
By default, each node maintains three logical lakes:
| Lake | Purpose |
|---|---|
| main | The primary user data store |
| archive | A temporary workspace used for backups, drafts, and prepublication artifacts. |
| system | Contains indexes, system metadata, public keys, and other local configuration documents. |
When a document is updated via LUMA's upsert command, bettyd coordinates a multi-step process to preserve data integrity, maintain provenance, and update relevant indexes. This workflow provides strong guarantees for:
| Integrity | Only complete documents are written; no partial updates or broken schemas. |
| Provenance | Every change is versioned and archived, preserving a transparent audit trail. |
| Autonomy | Nodes may enforce local access control policies while maintaining federation. |
| Index Consistency | Tags and metadata drive index maintenance dynamically, without schema migrations. |
| Resilience | The archive lake doubles as a recovery mechanism and audit ledger. |
Here's what happens behind the scenes.
http GET /list?topicID=<uuid>
upsert API request to the proper topicID. BeTTY requires full-document upserts to ensure structural consistency and simplify federation.
meta.index keyssystem lake.
Upon receipt, each directory file updates the relevant entry, replacing or appending the new values as needed.
topicID.
Confirmation messages are sent to both the original requester and the system logs via message, ensuring traceable acknowledgment of the completed transaction.
bettyd forms the base of the BeTTY stack, serving data to:
By combining these layers, bettyd helps build a local-first, semantic,
and private alternative to today's cloud-centric web.
BeTTY separates concerns between data and presentation by distinguishing between plugins and applications.
Plugins (registered via btty) use LUMA verbs and connect them to code written in any language, run on any machine.
This makes plugins an incredibly easy way to extend the functionality of your BeTTY stack.
This leads to the question of what distinguishes a BeTTY plugin from a BeTTY application.
In brief, bettyd plugins extend what BeTTY is capable of doing; applications built on the BeTTY stack (e.g., Memeograph, built atop httbd and marXDown) extend how humans experience BeTTY.
| Feature | bettyd plugin | httbd app |
|---|---|---|
| Primary Role | Backend logic & storage | Frontend interface & interaction |
| Runs On | bettyd node | httbd gateway |
| Encryption Handling | Native | Inherited (through httbd) |
| Data Access | Direct API (LUMA) | Translated JSON-LD |
| Example | nbson, marXDown | memeograph |
bettyd provides the quiet infrastructure beneath the thinking, writing, and collaboration that drive digital human interaction.
Every node contributes to a network of meaning rather than a market of attention.
Built for openness, it invites both developers and end users to regain control of their information and take part in a new Internet serving knowledge, not algorithms.