LINKSPREED Begins Development of Wisp, a Sandboxed Configuration and Automation Language
The Web4 company moves down the stack, from decentralized social infrastructure into language and runtime engineering, with a deterministic, capability-secured scripting language designed to safely execute untrusted code inside host applications.
Albuquerque, New Mexico, September 19, 2026 — LINKSPREED LLC today announced that it has begun development of Wisp, a minimal, deterministic, sandboxed programming language and embeddable runtime designed to execute untrusted code safely inside host applications. Wisp is the first programming language in the company’s history, and the company was direct in framing it as the opening move of a longer program rather than a one-off artifact.
The announcement marks a deliberate shift in where LINKSPREED invests its engineering effort. The company, founded in 2020 in Bavaria and today headquartered in Albuquerque, New Mexico as LINKSPREED LLC, has built its public identity on Web4 — a community-based, decentralized model of the internet — and on Social Networks as a Service, which lets individuals and organizations stand up their own social platforms without technical expertise. Its product surface spans instant community creation, a decentralized identity system, cloud services, and an integrated AI application layer. Wisp sits underneath all of it.
“Every platform we have shipped has eventually run into the same wall,” said Marc Herdina, founder of LINKSPREED. “Our users want to express logic. Not settings — logic. Who gets notified, under what conditions, with what exceptions. Today the industry offers you two bad answers to that question, and we have used both of them, and we have been unhappy with both of them. Wisp is us refusing to keep choosing between them.”
The problem Wisp exists to solve
The problem is old, well understood, and almost universally solved badly.
Software frequently needs to run logic that was authored by someone other than the team that shipped the software. A community administrator defining moderation rules. A platform operator describing a deployment. An integrator transforming an inbound payload. In each case the logic belongs to the user, but the execution happens inside the provider’s process, on the provider’s infrastructure, next to other tenants’ data.
The first conventional answer is a configuration file. YAML, JSON, TOML. These formats are perfectly safe for the obvious reason that they are inert — they describe data and can do nothing else. That safety is also their hard ceiling. A configuration file cannot branch. It cannot iterate. It cannot compute a derived value or express a condition.
What follows is a decay pattern the industry has watched play out hundreds of times. Templating gets bolted onto the format. Templating grows conditionals. Conditionals grow loops. Within a year the organization is maintaining an accidental, undocumented, untestable programming language implemented in string substitution, with no meaningful error reporting and no way to test a rule in isolation. It is a programming language that nobody designed, nobody specified, and nobody can debug.
The second conventional answer is to embed a real interpreter — Python, JavaScript, Lua — and let users write actual code. This solves expressiveness completely, and introduces a risk surface that is difficult to overstate. A script in a general-purpose language can read the host filesystem, including credentials and the data of other tenants. It can open outbound network connections, turning the host into an exfiltration channel or an attack relay. It can spawn processes and escape the interpreter entirely. It can consume unbounded CPU or memory and deny service to every other workload on the machine. And it can behave non-deterministically — reading the clock, generating randomness, depending on ambient environment state — which makes its results impossible to cache, reproduce, or audit after the fact.
Retrofitting a sandbox onto a general-purpose language is a known-hard problem, and the history of such attempts is substantially a history of escapes. The attack surface is the entire standard library plus every reflective capability the language offers. Removing dangerous functions from a table is a game the defender has to win every single time and the attacker has to win once.
Wisp takes the third path: start from a language that never had those capabilities to begin with.
What Wisp is
Wisp is a small, statically-scoped, deterministic scripting language with Python-like indentation syntax, shipped as an embeddable library rather than as a standalone tool. It is written in Rust, and it is designed from the first line to be handed source code written by an adversary.
The design precedent is real and proven. Google built Starlark for its Bazel build system on exactly this principle — a Python-derived, deterministic, side-effect-free configuration language — and it has since been adopted well beyond its original context. Wisp applies the same philosophy in a deliberately leaner form, optimized for embedding into other people’s software rather than for serving one build tool.
Five properties define it, and LINKSPREED describes all five as non-negotiable:
One — no dangerous capability exists in the core. No file I/O. No network access. No process spawning. No reflection. No dynamic code loading. These are not features that ship disabled behind a flag; they are absent from the implementation. There is no code path to re-enable, which means there is no code path to exploit.
Two — every side effect passes through an explicit capability grant. A Wisp script that needs to affect the outside world calls a host function: a native function that the embedding application wrote and deliberately registered. Nothing else is reachable.
Three — every execution is bounded. Three independent limits govern each evaluation: an instruction budget, a memory ceiling, and a call-stack depth limit. All three are configurable by the host. All three terminate execution with a structured, typed error — never a crash, never an unbounded allocation.
Four — execution is deterministic. The same source with the same inputs produces the same output, every time, on every machine, in every timezone. There is no clock, no ambient randomness, no environment access, and no non-deterministic iteration order. This is what makes a result cacheable, reproducible, and defensible in an audit.
Five — it never panics on untrusted input. Malformed source produces a located diagnostic in the form file:line:column: description. Internal invariant violations are converted into typed errors at the API boundary. A script cannot crash its host by being badly written or deliberately malicious.
Deep dive: how Wisp is built
Workspace architecture
Wisp is structured as a Rust workspace of focused crates, with a strictly acyclic dependency graph. This is not organizational tidiness for its own sake — it is a security property. A small, clearly identified security-relevant surface is a surface that can actually be audited.
| Component | Responsibility |
|---|---|
wisp-lexer | Hand-written tokenizer with line/column tracking and indentation handling |
wisp-parser | Recursive Pratt parser producing a typed AST; located syntax diagnostics |
wisp-interpreter | Tree-walking evaluation, resource accounting, capability enforcement, host API |
wisp-stdlib | Purely functional standard library — strings, lists, dicts, math, JSON |
wisp-cli | run, fmt, lint, repl |
wisp-lsp | Language Server Protocol implementation |
wisp-ffi | Stable C ABI boundary |
bindings/node, bindings/python | Native bindings for the two largest embedding ecosystems |
Notably, the interpreter does not depend on the standard library. The standard library registers itself through the same public host API that any third-party integrator would use — which means the API is dogfooded by the project’s own components before anyone outside ever touches it.
Rust was chosen deliberately. A component whose entire job is executing hostile input is precisely the component where memory-safety bugs become sandbox escapes. unsafe code is forbidden across the workspace, with a single narrow exception at the C ABI boundary where it is unavoidable, and every such site carries a written safety justification.
The capability model
Host functions are registered into one of three categories, and the embedding application constructs each runtime with the set of categories it is willing to permit.
| Category | Definition | Examples |
|---|---|---|
| ReadOnly | No observable side effect outside the evaluation | Reading a configuration value, looking up reference data |
| Effectful | Bounded, auditable side effects | Emitting a log line, recording a metric, appending to a host-owned buffer |
| Privileged | Sensitive or irreversible operations | Never granted by default; requires deliberate, documented opt-in |
The default for a runtime constructed without explicit configuration is ReadOnly only. Privileged is never granted implicitly. A script calling a function outside the permitted set fails at the moment of invocation with a distinct capability error, and evaluation halts — it does not continue in a partially-executed state.
The practical consequence is that reviewing a third-party Wisp script reduces to a tractable question: which capabilities was it granted? That is a question a security reviewer can answer in minutes. Auditing arbitrary Python is not.
Resource governance
| Limit | Default | Behavior on breach |
|---|---|---|
| Instruction budget | 1,000,000 evaluated nodes | Halts with a budget-exhausted error carrying the source location reached |
| Memory ceiling | 16 MB | Allocation refused; halts with a memory-limit error |
| Call-stack depth | 256 frames | Call refused; halts with a stack-depth error including the call chain |
| Per-loop iterations | 100,000 | Halts with a loop-limit error, independent of the global budget |
Recursion depth is tracked independently of the operating system stack, so deeply nested input cannot trigger a native stack overflow — a real and frequently overlooked attack vector in tree-walking interpreters. All arithmetic on resource counters uses checked operations, closing integer overflow as an escape route.
LINKSPREED has committed to publishing a measured behavior table documenting observed outcomes at 50%, 100%, and 150% of each configured limit, with real numbers from real measurement runs. The company’s stated reasoning: adopters should be able to reason about margin, not take an assertion on faith.
Language surface
Bindings are immutable by default; mutability requires an explicit var declaration, making accidental mutation a syntax-level decision rather than a runtime surprise. Function parameters and return values carry mandatory type annotations, checked at call time with located errors. Integer overflow is an error rather than a silent wrap-around. Division by zero is an error rather than infinity. Dictionaries preserve insertion order, because deterministic iteration is not optional when determinism is the product.
A representative sketch of the intended surface:
var threshold = 5000
def requires_second_approval(amount: int, region: string) -> bool:
if region == "EU":
return amount > threshold
return amount > threshold * 2
def route(request: dict) -> string:
if requires_second_approval(request["amount"], request["region"]):
log("escalating request at {request['amount']}")
return "senior_approver"
return "standard_approver"log is not part of the language. It is a host function, registered by the embedding application in the Effectful category. If the host never registered it — or did not permit Effectful capabilities for this evaluation — the call fails at that line and the script does not continue.
Verification
A runtime that asks to be trusted with hostile input carries a proportionate burden of proof. LINKSPREED has specified a four-layer verification program:
- Unit and integration testing — a minimum of 80 cases, including at least 15 parser edge cases, 10 resource-limit cases, 10 capability-enforcement cases, and 20 or more standard library cases, with every resource limit covered by its own dedicated named test.
- Coverage-guided fuzzing — a
cargo-fuzzharness over lexer and parser, with duration and findings documented in the repository. Every crash discovered becomes a permanent regression test. - Differential fuzzing — a second, independently written reference implementation of a grammar subset, built using a deliberately different parsing approach, compared against the main parser across at least 20 targeted cases aimed at known interpreter weak points: operator precedence, right-associativity, unary operators before exponentiation, integer boundaries, float formatting, negative modulo, indentation ambiguity, deep nesting. Any divergence is treated as a defect to fix, not a difference to document away.
- Mutation testing — a
cargo-mutantsrun against the interpreter core, with the achieved kill rate published, including an explanation of surviving mutants. This measures whether the test suite actually detects injected faults, as opposed to merely executing code.
Where Wisp fits, and where it does not
LINKSPREED was unusually explicit about scope limits, publishing its non-goals alongside its goals:
| Not in the first release | Reasoning |
|---|---|
| Concurrency, threading, async | Determinism is a hard requirement and concurrency is in direct tension with it |
| Bytecode VM or JIT | A tree-walker is simpler to audit and fast enough for the workload profile |
| Classes and inheritance | First-class functions and dictionaries cover the modeling needs at a fraction of the semantic cost |
| Exceptions | Errors surface as typed results to the host; guest-level exception handling complicates resource accounting |
| Package registry | Module resolution belongs to the host, which knows its own trust boundaries |
The company was equally direct about what Wisp is not, in a passage that stands out for its plainness: Wisp confines the guest, not the host. It is not a defense against a host process that is already compromised, and it is not a defense against a host that registers a Privileged function which itself does something unsafe. That responsibility sits with the embedding application, and the documentation will say so.
On the comparison to prior art, the company declined the obvious marketing move. Against Starlark, Lua, and embedded Python, Wisp’s design position is stronger on memory ceilings, built-in instruction budgets, and explicit capability categories. On track record it is empty. “Starlark has a decade of adversarial exposure behind it and we have zero,” Herdina said. “Design intent is not evidence. That is exactly why the verification program is scoped the way it is, and why we are publishing the mutation kill rate even if the number is not flattering.”
Use cases
The target applications extend well past LINKSPREED’s own stack:
- Community and moderation rules in multi-tenant platforms. Administrators define escalation paths, visibility rules, and automated moderation logic through a product interface. Containment means one community’s rule cannot reach another’s data; the instruction budget means a badly written rule degrades only its own request rather than stalling a shared worker pool.
- Build and release pipelines. The original Starlark case. Build definitions that branch and compute while remaining reproducible — which is what makes build caching sound in the first place.
- Infrastructure configuration. One script generating twenty environment variants from a shared base, with errors caught at evaluation time with a file, line, and column, instead of at deployment time as a malformed manifest.
- Plugin and extension systems. A curated host function set plus an explicit capability allow-list turns plugin review into a bounded problem.
- Policy-as-code and compliance gates. Rules non-specialists can read, versioned in Git, evaluated in CI — and, because evaluation is deterministic and side-effect-free, re-runnable later to reproduce and justify a historical verdict.
- Data filtering and transformation at volume. Per-record predicates where the worst case must be predictable.
- Simulation and game logic. Deterministic scripting is a precondition for lockstep networking, replay systems, and regression-testable simulation.
Roadmap and development posture
Development is planned across seven milestone gates over roughly 28 weeks: specification and grammar freeze; lexer and parser; interpreter core and resource limits; standard library and host API; bindings and CLI; language server and editor tooling; and a dedicated hardening and verification phase before release readiness. Each gate carries binary exit criteria, and partial completion does not open the next gate.
The repository will remain private throughout the build phase. LINKSPREED framed this as a considered decision rather than a default: a foundational project is judged by its first public impression, security review benefits from completing before adversarial attention arrives rather than during it, and public iteration on an unstable grammar generates breakage for early adopters with no compensating benefit. Publication will be a single, gated event following a formal release decision.
At first publication, Wisp will ship under the LINKSPREED Source License (LSL) — full source visibility, free use, modification, self-hosting, and embedding, with a carve-out requiring a separate agreement for offering Wisp itself as a competing hosted commercial service. The company has committed publicly, in advance, to relicensing under Apache-2.0 at the stable 1.0 release or within 24 months of first publication, whichever comes first.
Herdina addressed the predictable criticism directly: “Source-available licenses get a rough reception in open source communities, and we are not pretending otherwise. The house license covers the window where we are most exposed — API stabilizing, no security track record, a hosted fork would be genuinely damaging. The dated, public transition commitment is how we are handling that, and people should hold us to the date.”
The first language, not the last
LINKSPREED positioned Wisp as the opening entry in a deliberate move down the stack. The company’s recent public activity already shows work at the protocol and infrastructure layer, including a web4:// protocol and a decentralized identity system it has rebuilt for scale. A language and runtime is the logical continuation of that trajectory.
“There is a difference between building applications and building the things applications are built on,” Herdina said. “Go and TypeScript and Starlark exist because organizations decided at some point that they were going to be a foundations company, not only a products company. That decision is the interesting one. Wisp is us making it.”
“It is the first language we have built. I want to be very clear that it is not the last one. There are at least two more problems in our stack that want a purpose-built language rather than a library, and we intend to build those too. What we are not going to do is announce them before we have earned the right to.”
The company also acknowledged the asymmetric risk it is accepting. Foundational work is judged harshly and permanently: a runtime that ships half-finished, or that documents behavior it does not have, damages credibility more than never publishing would have. LINKSPREED’s stated response is a release gate that blocks publication on demonstrated evidence rather than assertions, and a standing internal rule that scope will be cut before quality is.
About LINKSPREED
LINKSPREED LLC is a technology company headquartered in Albuquerque, New Mexico, founded in 2025 as the successor to Linkspreed UG. The company originated in Bavaria, Germany in August 2020, founded by Marc Herdina.
LINKSPREED is building Web4, a community-based, decentralized model of the internet in which users and organizations own their data and control their digital presence. Through its Web4 Social Networks as a Service offering, individuals and businesses can create and operate custom social networks independent of large centralized platforms. The company’s portfolio includes instant community-building tools, the Universal Integrated Identity Decoupled (UIID) system for decentralized user identity, cloud services, and an integrated AI application layer. LINKSPREED operates as a distributed, international team.
More at linkspreed.com.