Mesh

Navi Mesh — your machines, one pool of inference

Navi Mesh lets your own machines share the work of answering. A modest laptop assembles a chat request the way it always does — persona, Vault, knowledge packs, conversation — and a stronger machine you own writes the reply on its own model. The routing is whole-request: one machine answers, start to finish. There is no split answer and no streaming between machines in Ring 1.

Mesh is off until you turn it on, and it works between machines you pair by hand. Nothing about it is tied to a specific person, machine name, or domain: every name and address comes from your own settings and the cards you exchange.

Pairing — the card is the handshake

Each machine has a Mesh card: a PNG picture holding its name, its node id, its public key, the fingerprint of the certificate its Mesh door serves, the addresses it can be reached at, and a capabilities block — an honest self-report of the machine's hardware class, GPU or CPU, RAM, model, speed class, and the caps it lends under, so a borrower can see what it is borrowing from before it asks.

1. On the first machine, open the Mesh page (Mesh, under Apex | Systems in the left menu), turn Mesh on, and give the machine a name.
2. Choose Show my Mesh card and Download PNG card.
3. On the second machine, turn Mesh on, drop the picture onto the Mesh page's Paired machines area, or use Upload a PNG card there, and add it.
4. Do the same in the other direction — each machine needs the other's card.

Pairing is the consent act: a paired machine is a trusted machine. Pairing alone authorizes inbound requests — a validly signed request from a paired machine is accepted, with no further per-peer gate. The per-peer can borrow flag gates only outbound borrowing: unticking a peer's can borrow on this machine stops this machine borrowing from that peer, without unpairing it — it does not stop that peer borrowing from this machine. Either side can unpair at any time by removing the card. Paired cards also appear in ChipDeck (in the menu, under Chips), where a card downloads and unpairs.

Pairing is the picture, only. Show my Mesh card offers Download PNG card: a real .png whose face is the card a person reads — the machine's name, its node identity, and the offer in words (its capabilities, the lending limits it is configured with, whether it lends when idle or even when busy) — with the whole validation embedded inside the picture, in the same data-in-picture format the chips use. The face wears the Mesh family color — a clear network blue (59, 130, 246), in place of the old cyan — and its footer is split: the card's kind at the bottom left, its version at the bottom right, omitted when the picture's data does not know one. On the other machine, drop the picture onto the Mesh page's Paired machines area, or use Upload a PNG card there: the peer is added with the same validation and the same record as any imported card. A text card saved from an earlier build can no longer be used — the Mesh page no longer shows a copyable card or takes a pasted one, so re-download that machine's card as a PNG instead. Send the original picture inside a .zip: chat apps like Discord recompress uploaded pictures and strip the data out, so a picture that arrives with its payload gone is refused with that explanation — no readable Mesh card data, probably recompressed by a chat app, resend the original inside a .zip. A damaged or cut-short payload, a chip cartridge dropped in by mistake, and a file that is not a PNG at all are each refused with their own specific words — never a silent no-op.

Borrowing — automatic, with off switches

Once Mesh is on and a lender is paired and reachable, borrowing happens by itself: a chat request goes to the first reachable lender, and the reply arrives with a line under it — Answered by .

Three off switches, from widest to narrowest:

• The Mesh master switch turns the whole thing off.
• The Borrowing switch stops this machine from borrowing while leaving it able to lend.
• This chat only: keep it on this machine, beside the composer, holds one chat session home — no borrow is attempted for it at all.

If the lender is busy, your machine waits a short grace (2 seconds by default, changeable on the Mesh page) for it to free up, then answers locally; a lender that frees up during the grace can still take that request, but once your machine starts answering, the lender is never claimed mid-reply — it serves the next request. If a lender drops mid-answer, you see the notice — " dropped mid-answer — this reply was generated locally instead" — and your machine writes a fresh reply of its own. Two machines' prose is never spliced together.

CLI mode, chips, and every built-in route never borrow. Only model answers do.

Peer health checks — the roster checks itself

The bridge watches its peers itself: while Mesh is on, a background health check probes every paired peer about every thirty seconds — and immediately when a peer is paired and when Mesh is turned on — so a pair reaches "checked" on its own, with no chat sent. A probe result does not decay: the roster and the status column keep the last word — unreachable — unauthorized (last checked 42s ago) — until a newer check replaces it, and "not checked yet" means only that no check has ever run. The bridge log notes a peer going dark or coming back, with the reason, and stays quiet otherwise. The status column's Servers group lists them in product order — Navi (the engine), Apex | Node, Apex | Mesh, Apex | DHD.

Lending — automatic when idle, off means off

Lending can only be turned on from the lending machine's own dashboard, in person, at that machine. It cannot be armed through the DHD door. Turning it off works from anywhere you are signed in — and Stop lending now ends lending and aborts a borrowed generation already running, mid-flight, at once.

A lender serves only inside the limits you set:

• Lend only when idle (on by default): while it is on, the machine must have been quiet for 60 seconds before it lends. Turn it off and the machine lends without waiting to be idle, borrowed generations running alongside your own work — your own replies may slow down. In both postures, a request that arrives while a generation is already running is refused busy: one borrowed generation at a time still holds, and a request that arrives mid-generation waits for the next slot, as it always has.
• Share cap: borrowed work may take at most 25% of any rolling hour by default — set it on the Mesh page, in the Lending section beside the Caps line, from 1% to 100%.
• Generation caps: at most 20 borrowed generations an hour, and at most 10 an hour for any one machine, by default — set each on the Mesh page, in the Lending section beside the Caps line, from 1 to 10,000 an hour.

The caps save into the machine's config and govern the very next admission and the very next card it shows — no restart — and because the card advertises the caps you set, a paired machine sees the real offer instead of the defaults. A fresh install still lends at most 25% of each hour, 20 generations an hour, 10 per machine, until you say otherwise.

Your own work always wins: a local request takes the next slot ahead of any new borrowed work, though it never kills a borrowed answer already running. A request whose assembled context exceeds the lender's context setting is refused whole — never silently truncated.

Open the Mesh page through the DHD door and the Lend this machine switch shows the lock itself: while lending is off it renders locked — dimmed, not clickable — with the reason in plain words directly under the switch, because lending can only be turned on in person. While lending is on, the switch stays live on the remote view, since turning lending off works from anywhere; a note under it says turning it back on will require being at the machine. The lock is the bridge's, not the page's: the bridge refuses a lending turn-on that arrives through the DHD door regardless of what any client renders.

Privacy — what travels, what never does

What travels when you borrow: the assembled prompt for that one reply — your Soul and Memory text, any Vault or knowledge-pack material the question pulled in, and the recent conversation — sent encrypted to the lending machine, whose model reads it to write the reply. The lender keeps none of it: no prompt or reply text is written to disk on the lending machine, ever. But that machine's operator owns the machine it runs on. Only borrow from machines you trust with the conversation. The Mesh page shows this in plain words the first time borrowing is enabled.

What never travels: your files and data stores, your credentials and access codes, and command-line access. Mesh carries chat requests and replies, nothing else. Mesh keys and dashboard codes are separate credentials that share nothing in either direction: a guest signed in through DHD can never reach Mesh, and a paired Mesh peer gains no dashboard access. A peer's network addresses likewise stay in the plumbing — they are used to dial the machine and are never shown in the roster or any other surface.

Every Mesh request is signed with the borrowing machine's Ed25519 node key and checked against the key on its paired card; stale or unsigned requests are refused with no detail given. The connection itself is pinned to the certificate fingerprint on the card — if the machine answering presents a different certificate, the borrower refuses and says so in plain words.

The ledger and balances

Each machine keeps a small ledger of Mesh work: who, which direction, how long, how it ended — metadata only, never content. The Mesh page's roster shows each paired machine's balance in seconds lent minus seconds borrowed, alongside its capability line and live status (reachable, lending, busy, idle, unreachable). The roster shows names, capabilities, status, and balances only — a machine's addresses are plumbing for the transport and never appear on any screen. Balances are a record, not a rule: Ring 1 has no give-to-get enforcement. The ledger stays out of GitHub backups unless you tick Include the Mesh ledger in backups (off by default); the node keypair never rides a backup either way. Mesh pairing cards join GitHub backups when Mesh pairing cards is ticked in the essentials (Settings → GitHub & Backup): a backup carries this machine's own card as a PNG plus one PNG per paired peer, and restoring lands the pictures in config/mesh/cards/ and re-pairs the peers through the same validation as a hand import — the restoring machine's own identity is never overwritten.

Getting there — the dedicated door

Mesh always travels through its own dedicated TLS listener on the Mesh port (8765 by default), whether or not DHD is on. The certificate it serves is the Mesh certificate under config/mesh/, and that is the fingerprint the paired card pins — in every configuration, so a card stays valid when DHD comes and goes. Mesh never rides the DHD door: the DHD proxy refuses /mesh/* outright, and the dashboard itself serves only the dashboard-local Mesh controls (the card view, Stop lending, the settings API) behind the access-code gate — the node-facing status and borrow endpoints live only on the dedicated port. There is no plaintext Mesh listener. Ring 1 does no NAT traversal, no relay, and no lender racing: the first reachable lender serves, and a home pair on one network is the shape it is built and tested for; reaching a lender across the internet means forwarding the Mesh port yourself.

When the Mesh goes dark — the health check

A Mesh failure used to report a single word — unreachable — fingerprint — and the rest was archaeology. Now the failure surfaces speak in sentences. A peer's roster row carries the full reason under its state: what answered, what did not match, and the cure where the product knows it. A changed Mesh identity is cured by importing that machine's fresh PNG card — the pin is replaced in place and the pair's ledger history is kept. A refused signature names its first suspect — the two machines' clocks — because a Mesh signature lives for 120 seconds, so a clock more than two minutes out reads as a forgery. A borrow that falls back names the stage it failed at — connect, TLS, fingerprint, signature, or timeout — in the chat notice. A Threat Intelligence digest the collector refuses is likewise refused out loud, with the check that refused it named on the Center's Mesh source line.

The Mesh health check, at the foot of the Mesh page, runs the two decisive reads of any dark pair on the spot. It compares the certificate on this machine's disk with the one its Mesh door actually presents — a difference means something else is serving the door, usually a second bridge, and the check's process census counts the bridges running and names the door's owner. For every paired machine it holds the fingerprint this machine pinned from its card up against the certificate that machine presents right now, and then runs the signed check, so identity and signature are judged separately. Every verdict is a sentence, with the actual fingerprints side by side. The check changes nothing: no pairing, pin, or route is touched — it reads and reports.

Troubleshooting

• "Certificate fingerprint does not match." The machine that answered is not presenting the certificate on its card — the card is stale, or something else is answering at that address. Re-download the PNG card from that machine's Mesh page and re-add the peer.
• Replies keep saying "answered locally" with a busy / cap / idle note. The lender is doing its job: it is mid-answer, over its caps for the hour, or not idle yet. The note names which. Wait, or raise the caps on the lender.
• " dropped mid-answer." The lender went away during a reply — its operator hit Stop lending now, or the machine or its bridge stopped. Your reply was written locally, whole. Check the lender.
• A peer shows unreachable. Its Mesh is off, its bridge is stopped, or the address on its card no longer reaches it. Re-check the card's addresses on the lender itself first.
• A recorded drop stays on the roster. Once a lender has died mid-answer, the drop it left on the roster is not erased by the next failed check — cached or fresh. The drop stands until a check actually succeeds, a borrow is served, or five minutes pass, so the status row does not fall back to a plain "unreachable" and lose the warning the drop earned.