Consume the network (ogong-connect)

There are two ways to send inference to OGONG, and they are different jobs:

• Point an app at the gateway directly. Any OpenAI-compatible client can call an ogong-gatewayd URL and request an ogong/<tier>/<maker>/<model> id. Simple, but the app has to know a gateway URL and it does the tier/E2EE handling itself.
• Run ogong-connect. A small local daemon that is the consumer: it figures out a gateway, verifies the provider’s attestation, establishes end-to-end encryption, dispatches your request, and opens the sealed reply. Any OpenAI or Ollama client points at http://127.0.0.1:PORT and gets verified, private remote inference without knowing anything about the network.

This page is about the second one.

ogong-connect is how you use the network. It is not the same as ogong-provider local, which runs a model on your own machine with no network, no account, and plaintext localhost (see Local mode). Use local to self-host; use connect to reach the network.

Run it

ogong-connect                          # zero-config: figures out a gateway, listens on 127.0.0.1:11435
ogong-connect --gateway https://my-gw  # pin a specific / self-hosted / local gateway
OGONG_GATEWAY=https://my-gw ogong-connect

Then point any client at it:

# OpenAI-compatible
curl http://127.0.0.1:11435/v1/chat/completions \
  -d '{"model":"ogong/verified/meta/llama-3.1-8b","messages":[{"role":"user","content":"hi"}]}'

# Ollama-compatible (set OLLAMA_HOST=http://127.0.0.1:11435)
curl http://127.0.0.1:11435/api/chat \
  -d '{"model":"ogong/tee/deepseek/deepseek-chat","messages":[{"role":"user","content":"hi"}]}'

The daemon serves /v1/chat/completions, /v1/models, and the Ollama surface (/api/chat, /api/generate, /api/tags, /api/version).

What it does per request

The model id’s tier decides how the provider is trusted before anything is sealed to it:

• ogong/verified/...: fetch the provider’s advertised X-Wing key, seal the request to it, POST it, and open the sealed reply. The GPU decapsulates; every relay in between sees only ciphertext.
• ogong/tee/...: first fetch a nonce-bound attestation, verify the TDX quote (trusted measurement, freshness, and that the serving key is bound in report_data) and that the attested key vouches for the encryption key, and only then seal to it. A mock or stale attestation is refused.

Either way the request never leaves your machine in the clear, and (for TEE) you never encrypt to a key that isn’t provably an approved enclave’s.

How it finds a gateway

You don’t have to know a gateway URL. Resolution order:

1. --gateway or OGONG_GATEWAY, if set.
2. Otherwise the client picks the first reachable gateway from the set it knows.

The known set starts from a small list of bootstrap gateways baked into the binary, plus a cache from previous runs (~/.ogong/gateways.json). On connect it gossips: it asks whatever gateway it reached for GET /v1/gateways (the HTTP mirror of the validator mesh’s peer-discovery) and merges the result into its set, persisting the union. So each run starts from a wider, self-healing view and depends less on the hardcoded seeds. Every running ogong-connect also serves /v1/gateways, so clients can discover the network through each other, not just through one central gateway.

The trustless endgame (in progress) is reading the on-chain provider/gateway registry directly, so the client never has to trust any single gateway or the baked-in seeds to learn the set.