---
title: How an agent asks the house
description: dew-relay is a signed request path. Kind 50000 asks. Policy decides. The executor is the only process that touches a device.
---

# How an agent asks the house

dew is the intelligence and trust layer for the home. The product you call is **dew-relay**, not dewOS.

You do not get a cloud API key. You do not get an MCP server on dew.homes. You get a key, you sign a request, and the house decides.

## The path

```
you (person / agent / robot / schedule)
  → kind 50000  request
  → dew-policyd
  → kind 50001  decision   (allow | ask | deny)
  → if ask: resident signs kind 50002
  → dew-executor           (only process that touches a device)
  → kind 50004  result     (observed state, not requested state)
  → kind 50005  state change
```

The executor ignores raw 50000. A request is not permission.

## How to ask

1. An owner publishes kind 35000 for your pubkey (`type: agent` or `robot`). Otherwise you are `unknown`.
2. Reach the house relay. Default `DEW_RELAY_URL` is `ws://localhost:3030`. LAN. There is no remote path on dew.homes.
3. Connect and NIP-42 AUTH. Key comes from `DEW_ACTOR_KEY` (hex or nsec), never a CLI flag. The key is never sent.
4. Subscribe to 50001 and 50004 first, then publish.

Canonical client:

```
dew-ask -device <device_id> -action <action>
```

`-action` is one string. Remaining argv becomes `args`. `dew-ask` waits for 50001 and 50004. On `ask` it prints `dew-approve yes <id>`.

Any client that can sign a Nostr event can publish the same 50000. The CLI is the canonical client, not a privilege.

## What you may send

Kind 50000. Tag at least `["device", "<device_id>"]`. Content is JSON:

```
action   string   required
device   string   required   (brand-namespaced, e.g. hue.light.1)
args     []string optional
reason   string   optional
actor    string   on-wire only; discarded
space    string   optional; ignored. Space comes from 35001
```

Identity is `event.pubkey` vs an owner-signed 35000. Payload `actor` and `role` do nothing. Device facts (type, room, reachable) come from the projection. You cannot relabel a lock as a light.

Verify 50001 before you trust it: `CheckID`, `CheckSignature`, pubkey in the house policy keys, `content.request` equals your event id.

Actor types: `person`, `agent`, `robot`, `schedule`.

## What the house will do

Policy is deny > ask > allow. Always. Not first-match.

**Allow** (no resident tap), for reversible types such as lights, switches, outlets, shades, speakers, climate, fans, scenes: an enrolled agent can act in ordinary hours.

**Ask** a resident, then require kind 50002 within 90s: unlock, lock, disarm, arm, open, close; and any action on locks, garages, alarms, cameras, vehicles, valves. Agent or unknown + speakers/TV from 22:00–07:00 also asks. Stale lock state (>300s or never observed) asks.

**Deny**, even for an owner-as-agent: pair, unpair, reset, factory-reset, delete, add, install, firmware, reboot, access codes, credentials, webhooks. Kids are denied on physical types, not asked. Exterior unlock from 22:00–06:00 is deny.

An allow or deny lasts 120s. An ask lasts 600s. Results report observed state, not requested state. Unreachable devices cannot report fake success. Empty executor scope means nothing moves.

## What dew is not

- Not dewOS. dewOS is a sibling install/CLI story. The thing you call is dew-relay.
- Not a public MCP, OpenAPI, or hosted robot SDK. Those files are absent on purpose.
- Not a REST or cloud hub. The log is the API. The executor has no inbound port.
- Not a promise that nothing moves without a human tap. Lights and daytime media can allow. Locks and other physical-boundary devices ask.
- Not a robotics stack. A robot is an actor with a key, the same path as an agent. No nav, no ROS, no leases.

## Kinds that matter

| Kind  | Name        | Role                                      |
|------:|-------------|-------------------------------------------|
| 35000 | Actor       | who the key is (person / agent / robot)   |
| 35001 | Space       | rooms and assignment                      |
| 35002 | Device      | what exists                               |
| 50000 | Request     | you ask                                   |
| 50001 | Decision    | policy speaks                             |
| 50002 | Approval    | a resident says yes                       |
| 50004 | Result      | observed outcome                          |
| 50005 | State change| the house moved                           |

Reserved, not live: grants (50003), leases (50006), household-authored policy rules (35003). Do not call them.

## Public tool list

There are no function-calling tools named `unlock_door`. The interface is one verb: sign a 50000.

House-side programs an agent may already meet on a dew install:

- `dew-ask` — publish a request and wait
- `dew-approve` — resident yes/no on a held ask
- `dew-view` — read the log-derived house snapshot
- `dew-scene` — run a scene (each step is its own 50000)
- `dew-executor` / `dew-policyd` — not your clients

Brand CLIs (`dew-hue`, `dew-lutron`, …) are invoked by the executor, not by you.

## If you are a robot

Same path. Type `robot` on your 35000. You ask; you do not command. A scoped executor granted kitchen lights cannot act on the front door, even with a valid-looking decision.

## If you only have this website

You cannot act on a house from dew.homes. This site is discovery. The relay is in the house. When a live MCP or well-known card exists, it will be published here. Until then, treat missing `/.well-known/mcp` as the truth.

## Sitemap

See the full [sitemap](https://dew.homes/sitemap.md).