Tell it what you want.

Getting what you want online usually means becoming a detective — opening app after app, typing the same thing into each, wading past the ads and the results that paid to sit at the top. You do the work; someone else collects the value.

The Open Intent Layer flips that around. You publish what you want, need, can offer, or want connected — once, from something you control. Then possible solutions come back to you. Not search results: possible answers, from anyone or anything on the network that can meet the intent, with you deciding what to pursue.

What OIL is

An open standard, not a company

OIL is a shared language — the way email and the web are shared languages. Many different apps can speak it and still work together. No one owns it, so no one can quietly turn it against you. This pool runs one such app; there can be others.

Your data stays yours

Intent is published from something you control. Only the part needed to find a match ever leaves, in a form you approve. Nothing is quietly harvested. A restricted record's matchable slice is served only to a requester it is meant for.

The pool ranks nothing

The pool receives, validates, stores, and faithfully serves records — byte for byte. It applies no ranking, no score, no curation of its own. Who to surface and how to weigh it stays with the consumer and the user.

Switching stays cheap

Because intent lives with you and travels, leaving one app for another is cheap. When switching is cheap, the only way to keep you is to keep being good. Lock-in stops being the business model.

Plain-language framing above is drawn from the project's own introduction; it adds no new claim. OIL defines the common language for "I need this" and "I can offer this" before any match exists — identity, payments, matching, and pricing are deliberately left to other layers.

This pool

https://oilpool.net runs the OIL reference app's pool service — a non-normative implementation that exists to prove the standard is buildable and testable. It speaks plain HTTP and JSON. These are the endpoints it serves:

Method & path	What it does
`GET /health`	Liveness — is the pool up.
`GET /info`	Honest capability report: OIL version, conformance claim, active profiles, what is implemented vs. deferred.
`POST /intents`	Submit a record (a seek, offer, response, proposal, decision…). The pool validates and either admits it (202) or rejects it with a reason.
`GET /intents`	Query the pool for current, actionable records — served as their exact stored bytes.
`GET /intents/{id}`	Direct lookup by record id (percent-encoded), answered within retention and labeled.
`GET /conflicts`	Recorded same-`(id, sequence)` conflicts — the pool's supersession evidence.
`GET /policy`	The machine-readable pool policy (served when the pool claims `+controls`).
`DELETE /intents/{id}`	User-controlled deletion, honored locally (when the pool claims `+disclosure`).

Target: https://oilpool.net

Runs live from your browser against https://oilpool.net/health and /info. Until this pool is actually deployed, expect a connection error here — that is honest, not a bug.

Point a client at this pool

Two ways to talk to it: the reference app's own client, or raw curl.

Option A — the reference-app client

From a checkout of the OIL reference app (reference-app/), build and start the client shell, then point its pool field at this URL:

# in reference-app/ — Node >= 22.6
npm install
npm run build:client
npm run client          # serves the shell on http://127.0.0.1:5100/

# then open http://127.0.0.1:5100/ and set the pool field to:
https://oilpool.net

The shell's "Check pool" button fetches this pool's /health and /info, then lets you browse what it is serving. It remembers the last pool you connected to.

Option B — raw `curl`

Is it up, and what does it claim?

curl https://oilpool.net/health
curl https://oilpool.net/info

Publish an intent, then read it back — a full round-trip. First write a record:

# record.json — a minimal "seek" (someone stating what they want)
cat > record.json <<'JSON'
{
  "oil": "0.1",
  "kind": "Intent",
  "id": "urn:uuid:0d6f2a4e-9c1b-4b6e-8b3a-2f8f4a9d7c21",
  "sequence": 1,
  "posture": "seek",
  "publisher": "did:example:alice",
  "summary": "Seeking a weekly fresh vegetable box for a family of four near Lakeside.",
  "issued": "2026-01-01T00:00:00Z",
  "expires": "2030-01-01T00:00:00Z",
  "status": "active",
  "visibility": "public",
  "categories": ["https://vocab.example/food/produce-subscription"]
}
JSON

# publish it — expect HTTP 202 {"admitted":true,...}
curl -X POST https://oilpool.net/intents \
  -H 'Content-Type: application/json' \
  -d @record.json

# read it back in the live query — your seek is in "records"
curl https://oilpool.net/intents

# or look it up directly by id (percent-encoded)
curl https://oilpool.net/intents/urn%3Auuid%3A0d6f2a4e-9c1b-4b6e-8b3a-2f8f4a9d7c21

That is the whole publish → store → serve → read loop. From here a responder can post a Response and a Proposal, and the publisher a Decision — the reference app's npm run roundtrip drives the full lifecycle to a commitment boundary.

Honest status: this is a dev / test pool

Not production. This is a prototype pool for development and testing. Treat it as disposable: data may be wiped, the service restarted, or the shape changed without notice.
No guarantees. No uptime, durability, privacy, or security promises. Do not publish anything sensitive or anything you cannot afford to have public.
No auth, open by design. Records are public and openly queryable. Attestation (signed proofs) is optional and, where present, is honestly labeled — the pool verifies the signature, not the real-world identity behind the key.
The honest edge: deletion is honored at this pool, but the standard cannot recall copies that already left the network. That limit is named, not hidden.