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

15
README.md
View file

@ -4,9 +4,18 @@ Nostr-native room rentals for LNbits — an "Airbnb for the castle". List
rooms, take booking requests, arbitrate availability, and settle stays over
Lightning, with Nostr as the interop layer.
> **Status:** design sketch + scaffold. Data model, migrations, availability
> arbiter, REST surface, and Nostr event model are in place; relay plumbing,
> FX/invoice wiring, and the guest UI are stubbed with `TODO(...)` markers.
> **Status:** functional prototype. Data model, migrations, availability
> arbiter (atomic hold), FX + invoice + settlement, the REST + kind-21000 RPC
> doors, and the nostrclient relay layer (publish + availability queries) are
> in place and tested. The guest UI and encrypted-event delivery pre-bunker
> are the remaining gaps.
>
> **Soft dependency:** publishing/subscribing to relays uses the **nostrclient**
> extension (imported in-process). Install + activate it to reach relays; if
> absent, the booking flow still works over HTTP/RPC and relay publish is
> skipped with a logged warning. Encrypted events (reservation `30078`, check-in
> DMs) additionally need a bunker/server-signing signer (lnbits #18); on a
> LocalSigner they soft-fail until then.
## Why not just reuse an existing NIP?

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