Releases

Fast code index for C# and TypeScript codebases -- map, find, refs, impact from the CLI.

Fork of deno_snapshots 0.74.0 maintained for oj: the v8 snapshot can be consumed from a prebuilt per-target bundle (OJ_SNAPSHOT_ARCHIVE) for reproducible builds. Use upstream deno_snapshots unless you need this.

Fork of deno_napi 0.190.0 maintained for oj, carrying oj's finalizer-registry performance patch (Vec -> BTreeMap). Use upstream deno_napi unless you need this patch.

oj's fork of deno_process: child process groups + spawn hook

Stack-agnostic version PRs from Changesets-format fragments

DuckDB adapter for the Quarb query engine

Filter pipeline engine and built-in filters for Praxis

HTTP, TCP, and protocol adapters for Praxis

Configuration, error types, and server factory for Praxis

Heddle's CLI verb catalog, schemas, help, and recovery contract.

Embeddable HTTP web monitor for Cobble databases

Collection of server APIs

bevy zeroverse synthetic dataset rust generator

Oxen is a fast data version control system, built with machine learning training data in mind. Designed to handle terabytes of data with ease, using a workflow similar to git. Version both structured and unstructured data of any modality: text, images, video, audio, CSV, Parquet, JSONL, model checkpoints, and more. liboxen is the embeddable core library behind the oxen CLI and server, which power fine tuning and inference pipelines for multimodal LLMs, image models, and video models on Oxen.ai.

deCDN sponsorship daemon: signs capped, expiring capabilities against a PaymentPool and keeps it topped up

Oxen server is a fast data version control backend, supporting local disk and S3. Self host your repositories on your own storage, or use the hosted platform on Oxen.ai. Stores, syncs, and serves versioned datasets, model checkpoints, game assets, studio media, and any large data. Use the oxen CLI to push and pull from the oxen server.

Library core of sponsord, deCDN's sponsored on-ramp: capability signing and pool top-ups, for embedding

One-dependency front door to the Trust Tasks framework: re-exports trust-tasks-rs plus the transport, proof, ceremony and capability crates behind Cargo features.

The core bridge of bevy-react (drive bevy_ui from React over an embedded V8 runtime). Apps depend on the `bevy-react` crate.

Opinionated Arora runtime: an engine pre-wired with the native behavior-tree core nodes and the Semio backend.

Pluggable ProofVerifier implementations for the Trust Tasks framework. Backends are gated by Cargo features; ships with an Affinidi Data Integrity backend (EdDSA suites) by default.

ToIP Trust Spanning Protocol (TSP) transport binding for the Trust Tasks framework, built on affinidi-tsp. Provides pack/unpack helpers and a TransportHandler that maps the authenticated VID sender into the framework's §4.8.1 precedence.

The Arora behavior tree: Groot-compatible trees ticking Arora modules.

HTTPS transport binding for the Trust Tasks framework — typed client + axum-based server with bearer-auth identity, suitable for demos, mockups, and end-to-end testing.

DIDComm v2.1 transport binding for the Trust Tasks framework, built on affinidi-messaging-didcomm. Provides pack/unpack helpers and a TransportHandler that maps the verified envelope sender into the framework's §4.8.1 precedence.

Client-side wire helpers for the capability Trust Task families (governance/capability/*, git-trust/*): document builders, envelope parsing, reply classification. Shared by capability producers (community services) and management UIs so the two cannot drift.

DIDComm v1 transport binding for the Trust Tasks framework, built on affinidi-messaging-didcomm-v1. Carries Trust Task documents to Aries-lineage agents, which speak v1 only, and maps the connection's theirDid into the framework's §4.8.1 precedence.

Reference Rust library for the Trust Tasks framework — transport-agnostic, JSON-based descriptions of verifiable work between parties.

The intray as a tuplespace: urn:space:{name} — Sink drops a tuple (out), Source lists/reads/filters (rd), Delete atomically takes one (in), associative match via SPARQL ASK. A physical, capability-gated space; later slices add the reactive engine and encrypt-on-drop.

In-process transport: composes a kernel directly in the host process.