Partner backend

​

Mount the proxy

import { createServer } from "node:http";
import {
  createInteropProxy,
  hubTransport,
  toNodeListener,
} from "@c8ntinuum/infinity-interop-sdk/server";

const transport = hubTransport({
  baseUrl: process.env.HUB_BASE_URL!, // the hub's origin: https://proxy-api.infinimesh.net
  apiKey: process.env.HUB_API_KEY!, // c8n_sk_…, made for your project in the hub dashboard
});

const proxy = createInteropProxy({
  transport,
  basePath: "/api/interop",
  userScope: "subject", // the hub keeps each user apart, by X-Infinity-Subject (default: "ownership")
  resolveUser: async (request) => {
    const session = await yourSessionFrom(request); // your cookie, JWT…
    if (session === null) return null; // → 401
    return { id: session.userId, wallets: session.verifiedWallets };
  },
  onError: (error, context) => alertOperators(error, context?.route),
});

const handle = toNodeListener(proxy);
createServer((request, response) => {
  if (request.url?.startsWith("/api/interop")) return handle(request, response);
  // …the rest of your server
}).listen(8787);

​

What it does on every call

​

The user and their wallets

​

Keeping your users apart

• the subject is your stable id for the person, never reused for someone else, in the hub’s alphabet (^[A-Za-z0-9._@+~-]{1,128}$); a subjectOf that returns anything else is a misconfiguration (PXY0500, and onError);
• before it serves any history the proxy runs the subject canary: it lists orders for a subject none of your users has, which must come back empty and echo that subject. While the canary fails it refuses history (PXY0503), reports it to onError, and tries again at most once a minute. Run it yourself at start-up with proxy.checkSubjectScoping(), or with verifySubjectScoping(client.api) (from /server) on a client over hubTransport;
• every history page must echo the user’s subject (data.subject), or the proxy refuses it (PXY0502);
• GET /status/{orderId}, which the hub does not scope by subject, is still answered for the user’s own orders only, from the proxy’s records.

​

Relaying RPC calls

// POST /api/rpc/<chainDomain> → your RPC for that chain
const upstreams = { "eip155-1": process.env.RPC_EIP155_1!, "eip155-8888": process.env.RPC_EIP155_8888! };

​

Hardening

• beforeForward(context): your last word before a call is forwarded. Return a Response to answer it yourself (a per-user rate limit, a deny list), or nothing to continue. Every user of your backend shares your organization’s pool at the gateway and its buckets at the hub, so meter them here.
• onError(error, context): a key the gateway refused, misconfiguration, a failed subject canary and proxy bugs land here: page an operator. Users only ever see a generic “temporarily unavailable”.
• Timeouts: hubTransport waits a little longer than the gateway (25 s on quotes, 12 s on reads, 15 s on submissions), so the gateway’s own answer ends a slow call; change them with timeouts only upwards.
• Pages on other origins: answer CORS for exactly those origins, never *: your backend spends your API key. From an https page your backend must be https too (or on the user’s own computer, http://localhost): browsers block other http:// calls from https pages, bare IPs included. The example sets this with CORS_ORIGINS.
• The example has no login: examples/proxy-server believes whatever user id and wallets the page sends, so anyone who can reach it spends your key and can read any of your users’ history through it. It listens on 127.0.0.1 unless HOST says otherwise, and warns at start-up once HOST or CORS_ORIGINS opens it up. Put your own authentication in resolveUser before anyone else can reach it. It keeps users apart by subject unless HUB_USER_SCOPE=ownership, and runs the subject canary at start-up.

​

Keys