47 lines
2.2 KiB
Markdown
47 lines
2.2 KiB
Markdown
---
|
|
date: 2026-10-09
|
|
tags:
|
|
- question
|
|
hubs:
|
|
- "[[nostr]]"
|
|
- "[[protocols]]"
|
|
urls:
|
|
- https://github.com/nostr-protocol/nips/blob/master/01.md
|
|
- https://github.com/nostr-protocol/nips/blob/master/46.md
|
|
- https://github.com/nostr-protocol/nips/blob/master/47.md
|
|
- https://github.com/nostr-protocol/nips/blob/master/90.md
|
|
---
|
|
|
|
# Nostr request/response and delivery guarantees
|
|
|
|
Open question: how does Nostr handle request/response when a machine
|
|
*needs* to know its message was received? Nostr is publish/subscribe with
|
|
no end-to-end delivery receipt, so every "RPC over Nostr" NIP builds its
|
|
own correlation on top.
|
|
|
|
What exists today (to verify and expand):
|
|
|
|
- **Relay-level ack only.** NIP-01 `["OK", <event-id>, true|false, <msg>]`
|
|
tells the publisher the *relay* stored the event. Says nothing about the
|
|
recipient. Publishing to several relays gives several OKs.
|
|
- **Correlation by `e` tag.** Every request/response NIP has the responder
|
|
publish a new event that tags the request's id; the requester subscribes
|
|
with a `#e` filter (and usually `#p` on its own pubkey) and waits with a
|
|
timeout. No response within the timeout = treat as not delivered, retry
|
|
with the same request id (responders should be idempotent on it).
|
|
- **NIP-46 (remote signing, nsecbunkerd):** kind 24133, encrypted JSON-RPC
|
|
`{id, method, params}` → `{id, result, error}`. The `id` in the payload
|
|
is the correlation key, the event `e`/`p` tags are routing.
|
|
- **NIP-47 (Nostr Wallet Connect):** kind 23194 request → 23195 response,
|
|
same pattern, plus 23196 notifications. Also `expiration` tag so a stale
|
|
request is dropped rather than executed late.
|
|
- **NIP-90 (DVMs):** kinds 5xxx request, 6xxx result, 7000 job feedback
|
|
with `status` (payment-required, processing, error, success). This is the
|
|
closest thing to a progress/ack channel in the protocol.
|
|
- **NIP-17 DMs:** no read receipts by design.
|
|
|
|
Our own use: lnbits ↔ nsecbunkerd over NIP-46, and anything the bots do
|
|
over Nostr. The practical answer is: own correlation id, subscribe before
|
|
publishing, bounded timeout, idempotent retry, and treat relay OK as "sent"
|
|
not "received". Worth a reference note once the pattern is written down
|
|
with code pointers (nsecbunkerd client, nostrclient).
|