Private AI inference,
among friends.

Tailscale‑style trust, Tor‑style routing — for LLMs

Commercial decentralized‑inference networks route encrypted prompts to anonymous, hardware‑attested strangers and pay them. WeAI replaces that anonymous marketplace with a trust graph of friends: you invite people you already trust with a signed link, lend your node's compute, and borrow theirs. No money, no strangers, no account. The social graph is the trust layer.

One app. Every privacy model.

Every other tool forces a single trade‑off — convenient cloud or private local, anonymous marketplace or nothing. WeAI is the layer that lets you pick the right backend per request, so it checks every box — and adds rows the others don't even have.

Four moving parts

A node identity, a signed invite, an onion‑routing layer, and a (planned) transport. Here's how they fit — and exactly which parts execute today.

Every primitive, and why

WeAI uses only vetted, standardized primitives from Apple's CryptoKit — constant‑time, hardware‑accelerated, and widely reviewed. No custom crypto.

SecureChannel — the mutual‑auth, PQ‑hybrid session

When you borrow a friend's node, the two machines first run an IK‑style handshake (the pattern Noise calls IK: the initiator already knows the responder's static key — it came in the invite). Both ends are mutually authenticated to the exact X25519 keys exchanged in the signed invite, and the session is post‑quantum hybridized with an ephemeral X‑Wing KEM. Three messages, then encrypted data:

1. msg 1 → initiator sends its ephemeral key and its encrypted static key (identity‑hiding: the static is sealed under a key derived from the first es DH, so a passive observer never sees who is dialing), plus an X‑Wing ciphertext encapsulated to the responder.
2. msg 2 → responder replies with its ephemeral key. Both sides now mix four DHs — es · ss · ee · se — and the X‑Wing shared secret into one input keying material.
3. Derive — HKDF‑SHA256(ikm, salt = SHA‑256(transcript), info = "reai/i2r" | "reai/r2i") yields two directional keys. The transcript hash binds every public value (context, both statics, both ephemerals, the X‑Wing pub & ciphertext) so nothing can be swapped.
4. msg 3 → key confirmation — each side sends an HMAC‑SHA256 over the transcript under a derived "reai/confirm" key. If it doesn't verify, the channel is torn down before a single prompt byte is sent.
5. Data — every frame is ChaCha20‑Poly1305 with an 8‑byte big‑endian sequence number prefixed and bound as associated data, so replays and reordering are rejected.

Onion routing — how a layer is sealed and peeled

Invite — signing & verification flow

1. Build payload — node ID, display name, Ed25519 + X25519 public keys, a 16‑byte random nonce, issued/expiry timestamps.
2. Canonicalize — encode as JSON with sorted keys so the bytes are deterministic across encode/decode.
3. Sign — Ed25519 over the canonical bytes; pack as reai://invite/<base64url>.
4. Verify on accept — decode, check the Ed25519 signature against the embedded key, reject if tampered (.badSignature) or expired (.expired).

What holds today

• Mutually‑authenticated sessions. A channel only completes between the exact X25519 keys exchanged in the signed invite. An unknown or wrong initiator is rejected at the first handshake message.
• Key confirmation before data. An HMAC‑SHA256 over the transcript must verify on both ends, or the channel is torn down before any prompt is sent — no half‑open or mismatched sessions.
• Replay & reorder protection. Every frame carries a sequence number bound as associated data; duplicated or out‑of‑order frames fail authentication.
• Keys never leave the device or the user's hands. The identity keypair is generated on first launch and stored in the macOS Keychain — zero manual key management, nothing to copy or paste.
• Signature verification on invites. A tampered invite is rejected before any peer is added.
• Authenticated encryption everywhere. Flip a single byte of a handshake message, a channel frame, or an onion layer and the Poly1305/HMAC tag fails — no silent tampering.
• Outbound‑only relay. Nodes dial out to the rendezvous relay — no open ports, no port‑forwarding — and the relay only ever sees ciphertext plus a routing ID.
• Post‑quantum hybrid. Session & layer keys resist a future quantum adversary recording traffic today.
• Local‑first. Inference stays on‑device unless you explicitly borrow a friend's node.
• Attestation is checked before plaintext, and failure means refuse. A TDX quote is chained to Intel's root, graded against Intel's current TCB levels and checked for revocation — so a platform that is genuinely behind on microcode grades as out‑of‑date rather than simply "attested". The measured OS and container images are read, not just hashed; an image nobody can identify is shown as unidentified.
• Nothing is written to disk unless you turn it on. Conversation history is off by default; with it off, threads live in memory and are gone at quit. Turning it on is a disclosed trade, never made for you by an upgrade — and it needs both a device key held in the Keychain and, if you set one, your passphrase. Neither alone opens anything.

What is not secured yet

A documentation page that only lists strengths is marketing. Here is the honest gap analysis — these are the things to fix before WeAI is something you'd trust with sensitive prompts across machines.

• The exit node sees the prompt in plaintext. The SecureChannel protects data in transit; the friend whose node runs the model necessarily sees the prompt. Onion routing hides who asked from who answered — it does not make the operator blind. Trust here is social, not zero‑trust. Since 2026‑08‑06 the app states this rather than implying otherwise: nothing is transmitted until the answering node has described how it would run the prompt and WeAI has checked that description, the borrower consents once per conversation with the verdict in front of them, and only the last few turns travel — attachments stay home unless explicitly included.
• The relay learns routing metadata. It carries only ciphertext, but it sees which node‑IDs talk to which and when. Mitigation: run the relay over TLS, and the in‑app onion (already implemented) belongs over the wire across multiple relays so no single one sees both ends.
• Single‑hop today. The mutual‑auth channel is verified end‑to‑end, but the multi‑hop onion currently runs in‑process for the visualization rather than across separate relay machines. Real sender‑anonymity needs the layered route deployed over independent hops.
• A hosted relay is still needed for the open internet. The transport is proven over loopback today; reaching friends on other networks needs a deployed (ideally community‑run, stateless) rendezvous relay.
• Invites are bearer tokens. The one‑time nonce and out‑of‑band verify code exist but aren't yet enforced/consumed; no revocation.
• A network replica cannot be recalled. Pushing a conversation or a file to 0G publishes bytes that are permanent and public. They are unreadable without your passphrase, and that is the whole protection — deleting locally does nothing to the replica. The transaction, its size, its timing and the paying address are public too. The app says all of this before the first push, not after.
• A receipt proves existence, not retention. An anchor proves the bytes existed and hash to that root. It does not prove anyone will keep serving them — 0G has a real pruned state. And no attestation covers a model's weights: a verified enclave proves where the computation ran, not what was computed.
• "Locked" means the archive is locked, not that open threads are scrubbed. A thread you are reading lives in memory as plain text for as long as it is open, exactly as the live conversation always has. History does not make that worse — but it does not fix it either.
• The 0G write path has never spent a real token. Every layer beneath the transaction is built and tested against mainnet — including reproducing a live file's on‑chain merkle root — but the first payable write is waiting on a funded wallet. Removing a member from a shared vault is advisory until key rotation ships: they keep what they could already decrypt.
• No rate‑limit / sandbox on borrowed compute yet. Authorization now exists — lending is off until you enable it, and each incoming borrow is held for an explicit yes (auto‑declined after 90s) — but per‑peer quotas, resource caps, and prompt isolation still come before exposing a node widely.

The path to production‑secure