Connections

Your node speaks to other nodes over several transports, with the same messaging layer on top. No Kunuleco server sits in the middle of your conversation. On a local network your nodes talk straight to each other, and across the internet they ride the Tor and Veilid networks, whose relays carry ciphertext and are run by nobody in particular, and certainly not by us.

The transports

Transport	Scope	When it is used
mDNS	Local network	Same Wi-Fi / LAN. Automatic discovery, no setup
Tor	Internet	Privacy and cross-internet reach via a persistent .onion address; the usual first choice once you leave the LAN
Veilid	Internet	Encrypted private routes that traverse NAT without port-forwarding
IPFS	Internet	Content-addressed last resort via DHT routing

Kunuleco tries several paths and takes the first that answers. The order differs between making first contact and sending to someone you already know, and the last resort is to race every remaining path at once. The messaging layer on top (called CapTP) is the same regardless of which transport carries it: the application neither knows nor cares how packets traveled.

This is also why a Kunuleco mesh works with no internet at all: nodes on the same LAN find each other over mDNS and carry on. That is not a degraded mode; it is a first-class way to run.

Short codes

A short code like tiger-castle-7 is a memorable lookup key. Behind it sits your connection info, meaning your identity, your verify key, and whichever internet endpoints your node has (a Veilid route, a Tor address, an IPFS peer ID), signed by your key so it cannot be forged in transit. A code lasts 24 hours and anyone holding it can use it, so treat it like a door code. The code itself is registered with and resolved by a small directory service we run. It learns that a code maps to your endpoints and never sees your messages. You hand someone a code; they join it. For fully offline, in-person connection, meet hands over the same information as a kunul1… seed and QR instead, and it skips the directory entirely. Short codes are the one feature here that needs the internet, and meet is the offline equivalent.

When someone is offline

One-to-one messages (tell) are saved to a persistent history, and if your friend is unreachable the message waits in your outbox (outbox, outbox flush). Delivery resumes when a path to them exists again.

Seeing your own connectivity

Command	Use it to…
transport	See which transports are active
ping <user>	Confirm a peer is reachable, and over which protocols
/network (client)	Watch the live network view

Deeper diagnostics exist under help debug for when something misbehaves.