Project dossier / prototype
AP
AI Proxy
AP connects. APP communicates. Applications define capability.
A public rendezvous and proxy that gives private applications an ordinary HTTPS surface for AI clients. The private application connects outward; public clients use a stable channel over ordinary HTTPS.
System portrait / public ↔ private
Current transport: HTTP polling
- 01
AI clients make ordinary HTTPS requests under
/c/{channel}. - 02
AP holds the request in channel state while the private application polls outward.
- 03
The application dispatches the request through its own APP routes and semantics.
- 04
The application returns a response through AP; AP relays it to the client.
01 / Constraint
A private app, reached through public HTTPS.
A private application can initiate an outbound connection without opening an inbound port. AP gives it a public channel that AI clients can reach with ordinary web requests.
The channel namespace and the uplink transport are separate ideas: /c/{channel} is the client-facing route; polling is how the application currently retrieves work.
02 / Application contract
APP belongs to the application.
The APP document at / is a machine-readable landing page. The application describes its own routes and capabilities; AP forwards requests without authoring or interpreting that meaning.
Illustrative APP landing page / application-owned
{
"protocol": "APP/1.0",
"application": "Example App",
"description": "What this app exposes.",
"routes": [
{
"method": "GET",
"path": "/projects",
"description": "Lists projects."
}
]
}This is the current interoperability shape, not a frozen schema.
03 / Request and response
A short relay loop.
The application owns dispatch and response meaning. AP provides the channel, request handoff, and return path.
- 01
Create channel
The downstream application asks AP for a channel and keeps its returned uplink credential private.
POST /channels - 02
Poll for work
The application repeatedly polls. An empty wait returns no request; a pending request carries the application-relative method and path.
GET /channels/{channel}/next - 03
Run the local APP route
The application dispatches the request through its own router. AP does not add the public channel prefix to the local path.
APP-owned - 04
Return the response
The downstream posts its result to AP; AP completes the waiting public request on the channel.
POST .../responses/{requestId}
04 / Deployment and state
One contract, current implementation choices.
Shared Redis · Upstash
Shared broker state is used by the current production setup.
In-memory broker
Local development can run without shared Redis; this process-local state does not survive a restart.
Vercel is the initial deployment target, not part of the AP or APP contract. The service is designed to remain an ordinary Node.js service.
05 / Current boundaries
A working transport proof with unfinished trust boundaries.
These constraints are part of the current prototype and should guide where it is used.
- 01
Channel creation is public and user authentication is not implemented. A source-IP creation limit exists; broader abuse controls remain unfinished.
- 02
The channel credential protects downstream polling and response delivery. It does not authenticate public client traffic.
- 03
The current implementation expires inactive channels after 15 minutes. That is not a settled protocol guarantee.
- 04
Durable application identity and channel reclaim are not implemented; reconnecting applications create a new channel.
- 05
The APP route example is evolving. Its schema and security model are not finalized.