Lace-000 · Goal

Tags: overview, non-normative

Lace enables applications to describe a record set and converge on locally validated records without inventing a new command protocol for each exchange. This document is a short non-normative overview of why Lace is shaped around records, lacegrams, and interlace. Protocol requirements live in the numbered specs that follow.

This document is for new readers, contributors, and library designers. After reading it, a reader should understand the core model well enough to place the numbered specs and avoid push/pull or command-protocol framing.

Goal

Lace is a substrate for local-first record sets. It should let applications store signed or unsigned record bytes, describe which records belong in a local context, and exchange those records with other laces without inventing a new command protocol for every app.

The core goal is not “push this” or “pull that”. The core goal is:

describe a record set, then interlace with another lace until the current
fixed point of that set is locally available as validated records.

Records are the durable unit

A record is canonical bytes with a stable hash. In the public mental model, validated records are immutable rows and fields are columns. A projection, or table view, chooses field names and displays one row per record hash with those fields as columns.

Some records carry coordinates:

Group: the community, namespace, device, or local scope;
App: the application or app-defined contract inside that group;
Name: an app-local hierarchical name.

The record hash is identity. Group, App, and Name are indexed fields for selection; many records may share the same coordinate. Extra headers let applications attach small indexed facts without changing the record format.

Laces describe record sets

A lace is a record-set machine. It has validated record facts, runtime facts, peer advertisement facts during exchange, and lacegrams. A lacegram is a Datalog program used to describe record membership: app views, support closures, membership evidence, cache contents, outboxes, temporary operation sets, or exchange rules.

The preferred mental model is symmetric and set-oriented:

these records belong in this context

Interlace normally begins by compiling one selector operand from each lace into a faceted exchange plan. A selector module describes record-set criteria with SelectHave(P) and SelectAdvertised(P,S), while local query views control which record facts peer-authored rules may inspect. The exchange plan binary-merges the operands and lowers them to local enforcement predicates MaySend(P) and MayRequest(P) for discovery and transfer. The directional predicates are exchange mechanics, not the primary application model.

Interlace is the primitive exchange

Interlace is the one exchange mechanism. Two laces advertise relevant validated records, request missing records admitted by their rules, validate received bytes, and repeat until a fixed point or close condition.

This replaces separate primitive commands such as remote list, get, write, push, or pull. Public operations such as get, list, and store are local wrappers that create temporary operation laces and run ordinary interlace.

This frames an app’s relationship with other nodes primarily as record-set convergence, not as a growing matrix of directional commands and permissions. In normal application design, “should this record belong here?” should be the main question; “who initiated the transfer?” should usually be an implementation detail.

Dynamic closures are first-class

Many useful record sets are recursive or evidence-dependent. A record may link to support records; a chat message may belong only when its signer has member evidence; a view may become visible only after authority records arrive.

Datalog gives Lace a compact way to express these closures. New validated records become new facts, which may cause later interlace rounds to admit more records, until the current fixed point is reached.

Identity and authority are record-set problems

Cryptographic verifiers are useful, but applications often need higher-level identity: membership, delegation, key rotation, names, and authority paths. Lace intends these to be represented as ordinary records plus lacegram/profile rules, not as hidden transport assumptions.

A transport may prove a peer verifier, but record membership and app authority should be explainable from validated record facts and explicit runtime facts.

Developer API direction

Developer APIs should preserve the same model:

open_interlace: keep a merged record set synchronized over time;
bounded_interlace: run the same algorithm with a close condition;
get / list: temporary wrappers that add constraints to a local selector operand and return one-result or many-result local shapes;
store: a temporary wrapper that adds local record bytes and selector constraints to a local selector operand.

Execution style — blocking, async, or callback — is a runtime choice over the same interlace state machine.

What Lace tries to avoid

Lace avoids making these core protocol concepts:

push vs pull as a primary model;
app-specific command surfaces for every exchange shape;
trusting peer-advertised metadata before record validation;
hidden wall-clock or transport identity assumptions inside rule evaluation.

The result should be a small protocol where records are durable, lacegrams describe record sets, and interlace is the general way those sets converge.