MOSIS local-first

Your devices, talking directly. No cloud in the path.

Pair once with a 6-digit code and a word pair. After that, any two of your devices move files, clipboard, input and screens over a pinned mutual-TLS link on your own network.

How pairing works

this mac 418 302 otter · maple
iphone 418 302 otter · maple

unpaired — nothing trusted yet one side confirmed — waiting for the other paired — pinned mutual TLS from here on

It does not have to be your device. Anyone in the room can pair, because the trust is the code on both screens — walk up to the conference Mac, compare six digits, present.

Pairing is the handshake. This is the point.

Screens, clipboard, files and input, in both directions, over one link. Each card carries its macOS evidence tag, pulled from the same data the matrix is built from.

Every capability on every platform →

Verified on an iPhone and a Mac. We need everyone else.

15 cells are device-verified on real hardware — pairing, files, clipboard, the phone driving the Mac as a trackpad, screen sharing both ways, and the browser watch page. Five columns have never run on a device, and that is not a code problem but a hardware one, which makes it the thing an outsider can actually fix.

  • macOS Device-verified: 7 cells
  • iPhone Device-verified: 6 cells
  • Browser Device-verified: watch page, real HTTP
  • iPad Never tried — should behave like iPhone I have one →
  • Android Has never completed a pairing I have one →
  • Linux Cross-compiles; never executed on Linux I have one →
  • tvOS Builds; never run on an Apple TV I have one →
  • Windows Deliberately on hold — plan 08

The scripted session to run →

Four things make this worth a look.

  1. 01

    An open protocol, not an app.

    The wire format is documented well enough to implement from scratch. A fourth client is a reading exercise, not a reverse engineering project.

  2. 02

    Proven three ways, byte for byte.

    Swift, Go and Kotlin each implement the protocol independently and produce identical bytes against one frozen golden vector set. A live Swift↔Go session runs over real TLS.

  3. 03

    Local-first, absolutely.

    There is no cloud path to switch off, because none was ever built. Cut the internet and your own devices still find each other.

  4. 04

    Honest by construction.

    Every capability carries the strongest evidence that actually exists — E2E down to bld. CI fails if this site's matrix and the repo's ever disagree.

Why peer-to-peer is worth the trouble →

105 cells, each with its receipt.

15 capabilities across 7 columns, each cell naming the strongest evidence that exists for it and footnoted with what was actually run — including 15 now marked dev, which means verified on hardware.

E2E
automated end-to-end over real TLS sockets, same host (loopback)
E2E*
E2E with a fake at the hardware seam (fake injector / synthetic capturer)
smoke
Kotlin/JVM in-process session smoke (real crypto, no Android)
bld
compiles / APK assembles — no runtime evidence
wall
the platform forbids it (documented, not a TODO)
dev
device-verified on real hardware — see ¹⁵ for what was run

Read the full matrix →

Prove the core yourself, one command each.

All three run on one machine against the same frozen vectors, with nothing to install but a toolchain and nothing to sign up for. Every command below ran on 2026-07-26 (macOS 26.5, Xcode 26.6, Go 1.26.5).

Swift 126 tests

cd apple/ConduitKit
swift test --disable-sandbox

The flag is required: the macOS sandbox hangs the Network and VideoToolbox paths rather than failing them.

Go 52 vectors

cd core
go test ./...
go run ./cmd/conformance ../proto/vectors

Same golden vectors as Swift and Kotlin. The set is append-only, so a passing run stays passing.

Kotlin 70 vectors

cd android/core
kotlinc $(find src/main/kotlin -name '*.kt') \
  -include-runtime -d /tmp/conduit-core.jar
java -cp /tmp/conduit-core.jar \
  org.conduit.core.Conformance ../../proto/vectors

Pure JVM, no Android SDK. Needs any JDK 17 or newer on the path.

Full quickstart, every platform →