Skip to content
/
    How it works
    Offline by design

    Offline by design

    Most cross-device spatial anchoring today is cloud-VPS-first (VPS: visual positioning service): the client uploads camera images to a server, which matches them against a stored map. This project’s pipeline never does that. The anchor payload (mesh features, no images) is the only thing that ever crosses devices. Even that transfer is the caller’s choice, not a built-in service.

    Fully offline by design: scanning, anchor creation, and localization all run on-device. There is no cloud service: not as a tier, not as an architecture. That last part matters. “Offline” in this market usually means less than it sounds. The offline modes VPS vendors advertise cover localization only: creating the map still means uploading camera images to their cloud. Or, offline is an enterprise-only deployment model with no public documentation or price. Offline map creation, at any tier, is something no VPS alternative currently offers. Here it is simply how the product works.

    No images leave the device
    No camera image ever leaves the device. Anchors are computed from geometry alone (positions and normals).
    Designed to work where cameras can't
    Depth-sensor capture in the dark or IR-only conditions is a first-class scenario, because the pipeline never uses color or lighting.
    No service dependency for matching
    Registration is a local computation. Finding the anchor never calls out to a server.

    Your anchors are a file you own

    Share it over any channel you already trust, typically 2-5 MB. Pick any of them: AirDrop, MDM (mobile device management), your own backend, or sneakernet (physically carrying a drive between devices). The payload is a file of geometry features (positions, normals, scalars), not an account-bound upload sitting in someone else’s map dashboard. There is no vendor-side copy in existence, no per-map hosting fee, and no query quota metering how often your devices find it.

    The trade-off, honestly

    We are not the vendor with a global VPS fleet and a status page to match. We are the vendor whose SDK works in your customer’s basement, on their yacht mid-Atlantic, and after your funding runs out. That is a real trade-off, not a marketing angle. A cloud-VPS competitor can ship features this pipeline structurally cannot (server-side map merging across many users, for one). What it cannot do is keep working when the network doesn’t work, or when the room has no signal. It also cannot keep working when the vendor behind it shuts the service down. Azure Spatial Anchors did exactly that this year. If you built on it, see migrating from ASA. This pipeline has no service to shut down.

    For the compliance buyer

    If no data leaves the device, there is no data processing to have an agreement about. Camera images, room geometry, anchor payloads: none of it is ever uploaded, logged, or transmitted to this project’s infrastructure. That holds for both matching and finding an anchor. For teams in GDPR-sensitive, defense, healthcare, or fully airgapped environments, that changes the shape of the compliance conversation. There is no data-processing agreement to negotiate, no third-party sub-processor to list, and no cross-border transfer question to answer. The pipeline that does the matching never sees a network at all.

    Check it yourself

    The shipped win-x64 native binary imports no network API. You can check this yourself: run dumpbin /imports LansAnchor.AnchorSystem.Native.dll on Windows. The import table lists KERNEL32, ADVAPI32, ole32, bcrypt, ncrypt, CRYPT32, and the api-ms-win-crt-* runtime shims: no ws2_32, no winhttp, no wininet, no iphlpapi. The crypto DLLs (bcrypt, ncrypt, CRYPT32) are the offline license signature check, not network code. NativeAOT compiles this binary as a single statically linked native library. Nothing in the binary can open a network connection through any imported API. A runtime-loaded networking DLL would still need its name and function names somewhere in the binary. A strings scan finds none: no ws2_32, no WSAStartup, no InternetOpen. The only URLs anywhere in the binary’s strings are two aka.ms links inside stock .NET runtime error-message text, not requests the code makes.

    This audit covers the win-x64 native binary specifically, the one we pulled apart with dumpbin. The macOS dylib and the managed assemblies used in Mono and IL2CPP builds are compiled from the same network-free source. We have not run the same binary audit on those yet.

    See how it works end to end, or how every match gets verified in how it knows it’s right.

    The pipeline, technically