Skip to main content
Glama
README.md
# meld — ephemeral context bridge

**Don't meet. Meld.**

meld puts the context on a URL so neither side has to paste the block. Then the URL dies.

One URL. Both sides add context. When it resolves, the host serves 410 and the meld is gone. No history, no threads, no accounts.

## Live

https://meld.mergeinc.workers.dev

## Try it

- Browser: open the live URL, paste context, share the link.
- Agents: see Quick start below, or playbooks at https://meld.mergeinc.workers.dev/recipes.md
- Public playbook issue: https://github.com/lemonaide152/meld/issues/3

## Discover

- MeshKore: https://meshkore.com/agent/meld
- Agent card: https://meld.mergeinc.workers.dev/.well-known/agent.json
- llms.txt: https://meld.mergeinc.workers.dev/llms.txt
- MCP (stdio): [`mcp/`](./mcp/)

## Quick start (agents)

```bash
# Create a meld — get one share URL
curl -X POST https://meld.mergeinc.workers.dev/api/melds \
  -H "Content-Type: application/json" \
  -d '{"context": "Auth flow: OAuth2+PKCE, JWT tokens, refresh rotation"}'
# → {"code": "abc123", "url": "https://…/m/abc123", ...}

# Party B (human or agent) resolves:
curl -X POST https://meld.mergeinc.workers.dev/api/melds/abc123/resolve \
  -H "Content-Type: application/json" \
  -d '{"context": "Looks good, but add rate limiting to token refresh"}'

# Preferred: Party A reads both sides after resolve (no token)
curl https://meld.mergeinc.workers.dev/api/melds/abc123
# → {"code":"…","context_a":"…","context_b":"…","resolved":true, …}
```

### Legacy read path (still on the live host)

`owner_token` and `GET /api/melds/{code}/result` (header `X-Meld-Token`) are still issued and accepted for backwards compatibility. Prefer `GET /api/melds/{code}` after resolve — it returns both sides without a token. Token rotation on `/result` still applies if you use that path.

## Trust model

No accounts. The hard promise: after TTL **T**, the host serves **410** and the meld is gone.

Optional client-side encryption keeps plaintext off the server; the URL is still the capability. Full statement: [TRUST.md](TRUST.md).

## API

| Endpoint | Method | Auth | Description |
|---|---|---|---|
| `/api/melds` | POST | None | Create a meld (returns share `url`; also still returns legacy `owner_token`) |
| `/api/melds/{code}` | GET | None | View a meld — preferred Party A read after resolve (both sides) |
| `/api/melds/{code}/resolve` | POST | None (or PIN) | Resolve a meld |
| `/api/melds/{code}/result` | GET | Owner token | **Legacy** owner read (token rotates) |
| `/v1/melds` | POST | API key | Create via agent key |
| `/v1/usage` | GET | API key | Check usage |

## Pricing

| Who | Price | Limits |
|---|---|---|
| Humans (browser) | $0 | Free — no IP free-wall (`X-Meld-Client: human` or browser UA) |
| Agents (`/api/melds`) | $0 then key / unlock | 3 melds / IP / hour; then `POST /v1/keys` or wait |
| Agent API key (`/v1`) | $0 | 10,000 melds / key (mint via `POST /v1/keys`) |
| Agent wall unlock | $3.33 one-time | Unlocks one specific meld beyond the agent free tier |

Humans free in the browser. Agent payment protocols are coming. No subscriptions.
Create responses carry `X-Meld-Pricing: humans-free; agents-key-or-quota`.
Checkout (agent wall): `POST /api/checkout {"meld_code": "<code>"}` (Stripe).
Playbooks: FDE gather, provider-switch dump/request, TTL continuation — `/recipes.md`.

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct role: create establishes the meld, resolve is for the invited party to submit context, and read is for the owner to retrieve the resolved result. There is no functional overlap between the three operations.

Naming Consistency5/5

All tools follow the same meld_ prefix with a simple verb: create, resolve, and read. This creates a predictable and consistent naming pattern across the entire tool surface.

Tool Count5/5

Three tools is exactly the right scope for an ephemeral context bridge with a straightforward lifecycle. Each tool maps to one essential stage of the meld process with no redundancy.

Completeness5/5

The full lifecycle of a meld is covered: creation, participant resolution, and owner read of the resolved result. Expiry and token rotation are handled automatically, so no additional operations are necessary.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive