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

feat(api): keyless GET /api/v1/public/bookings/{id} for guests

Browse source 
The guest cannot subscribe to the operator's wallet and the existing
booking read needs a wallet invoice key, so a client had no way to wait
for awaiting_payment -> confirmed over HTTP short of polling the invoice
on LNbits core. Add the HTTP twin of the RPC door's chatelet_booking_get:
the 10-char booking id from the quote is the capability, and the response
is public_booking_dict — lifecycle, dates and money only, with the guest's
pubkey/contact and the Lightning/Nostr plumbing stripped.

Closes #18

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
Padreug 2026-09-15 23:43:21 +02:00
commit 94542ad0f9
4 changed files with 106 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

5
docs/event-flow.md
View file

@ -39,7 +39,10 @@ scoped, so the *operator* can stream booking settlements
(`subscribe_payments({tag:"chatelet", link_id:<booking_id>})`, wired via
`register_link_owner_resolver`). A **guest** can't subscribe to the operator's
wallet, so the guest confirms by polling `chatelet_booking_get` until
`confirmed` (a guest push would need a NIP-17 DM — issue #5).
`confirmed` (a guest push would need a NIP-17 DM — issue #5). The HTTP door
has the same read as keyless `GET /api/v1/public/bookings/{id}` (issue #18):
the booking id from the quote is the capability, and the response is the
same identity-stripped shape (`public_booking_dict`) on both doors.
> **Custom kinds vs the RPC — training wheels, not redundancy:** the
> `chatelet_availability` RPC is what ships first, but the ephemeral