aiolabs/chatelet
9
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: relay-transport (nostrclient) section + dependency note

Browse source 
Document the in-process nostrclient publish/subscribe path, the public-vs-
encrypted split (encrypted events await bunker/server-signing), and the
soft runtime dependency on the nostrclient extension.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019VUQCfdqiLSsFS2jcGnaFD
This commit is contained in:
Padreug 2026-07-19 18:09:35 +02:00
commit 7b8dd82a6e
2 changed files with 39 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

27
docs/event-flow.md
View file

@ -70,6 +70,33 @@ wallet, so the guest confirms by polling `chatelet_booking_get` until
| `1059` | 17/59 | both | Private booking DMs (request → quote → confirm → check-in) |
| `22000/22001` | aiolabs | guest/operator | Live availability query + response (ephemeral) |
## Relay transport — nostrclient (in-process)
Publishing app/discovery events and subscribing to inbound queries go through
the **`nostrclient` extension's** relay manager, imported in-process
(`nostr_client.relay_manager.publish_message(...)` / `.add_subscription(...)`),
the same pattern `spirekeeper`/`nostrmarket` use. This is separate from the
core kind-21000 RPC transport (Door 2): the core pool is RPC-only and can't
publish arbitrary kinds, so app events ride nostrclient. Adds a **soft runtime
dependency** on nostrclient — if it isn't installed, publish/subscribe skip
with a logged warning and the booking flow (HTTP/RPC) is unaffected.
`nostr/service.py` implements it:
- **Publish** (`_sign_and_publish`): sign as the operator (`resolve_signer`),
optionally NIP-44-encrypt, then `publish_message`.
- **Subscribe** (`subscribe_inbound`, a permanent task): register a
`kind:22000` subscription, poll `NostrRouter.received_subscription_events`,
answer each with a `kind:22001` reply.
**Public vs encrypted — what works pre-bunker:** a `LocalSigner` can
`sign_event` but its `nip44_encrypt` raises (bunker-forward by design, lnbits
#18). So **public** events (listing `30402`, calendar `31923`, availability
`22001` — availability is public info, so `22000/22001` are plaintext) publish
today; **encrypted** events (reservation `30078`, and the `#5` check-in DM)
sign-encrypt via the operator signer and soft-fail with a clear log until the
operator has a bunker/server-signing signer. Nothing crashes either way.
## Happy path
```mermaid