Skip to main content
libmoss is the native C library at the core of Moss. It exposes the same API surface as the Python moss-session and Elixir moss_session packages through a plain C ABI, so you can embed real-time semantic search directly into C, C++, or any language with a C FFI. It provides two handles:
  • MossClient - the entry point. Construct it with your credentials, manage cloud indexes, load an index for querying, and open sessions.
  • MossSession - a local index. Add and query documents on the same machine with no per-query network calls, then push to the cloud or pull an existing cloud index in.

Install

libmoss ships as prebuilt binary release tarballs on GitHub, one per target triple. Download the tarball for your platform from the releases page and extract it:
The release tag is c-sdk-v<version>; the tarballs inside it are named libmoss-v<version>-<target>.tar.gz. Each tarball contains:
  • lib/libmoss.dylib (macOS) / lib/libmoss.so (Linux) / lib/moss.dll (Windows) - the shared library
  • include/libmoss.h - the C header
Windows tarballs also contain the DLL import library lib/moss.dll.lib. The tarballs hold no static library (libmoss.a or moss.lib), so link against the shared library. The Linux builds need glibc 2.35 or newer on x86_64 and glibc 2.39 or newer on arm64.
libmoss is distributed only as GitHub binary releases. It is not published to crates.io.
Point your compiler at the extracted include/ directory for the header (-I) and lib/ for the shared library (-L). On macOS the library’s install name is @rpath/libmoss.dylib, so also pass an -rpath that resolves to lib/. Without one, the program stops at launch with Library not loaded: @rpath/libmoss.dylib.
To ship libmoss.dylib in a lib/ folder next to your program, use -Wl,-rpath,@loader_path/lib instead of the absolute path. On Linux the dynamic loader needs to find the shared library at runtime:

Quick start

Open a session, add documents (embedded locally with the built-in model), query, and push the index to the cloud:
To query a cloud index from a MossClient instead, load it into memory first with moss_client_load_index and then call moss_client_query. A MossClient query always runs against a loaded index, so the load step is required.
Every fallible call returns a MossResult code. The quick start omits the checks for brevity; production code should inspect the return value and call moss_last_error() on failure. See the examples for the full pattern.

Embedding models

Pass the model via MossSessionOptions.model_id when opening a session. The default (NULL) uses the built-in model and embeds documents and queries locally. Loading a built-in model downloads it from the Moss cloud, so it needs network access to Moss. The custom model downloads nothing.

Next steps

  • API reference - every MossClient and MossSession function, memory-management rules, error handling, and the metadata-filter format.
  • Examples - runnable session, cloud CRUD, and metadata-filtering programs.