From 1b65890f42889531e88d008d1cea223ff001ee38 Mon Sep 17 00:00:00 2001 From: Padreug Date: Sun, 19 Jul 2026 15:37:06 +0200 Subject: [PATCH] docs: reframe kind:22000/22001 as retained proposal, not redundant Per the client-agnostic doctrine (workspace CLAUDE.md): the availability RPC is the training wheel, the public kind:22000/22001 is the destination. Keep the custom kinds as a proposal so a generic Nostr client can one day query availability without our RPC. Published via the nostrclient relay path (#2). Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_019VUQCfdqiLSsFS2jcGnaFD --- docs/event-flow.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/docs/event-flow.md b/docs/event-flow.md index 5989195..b8fc7cc 100644 --- a/docs/event-flow.md +++ b/docs/event-flow.md @@ -41,11 +41,15 @@ scoped, so the *operator* can stream booking settlements wallet, so the guest confirms by polling `chatelet_booking_get` until `confirmed` (a guest push would need a NIP-17 DM — issue #5). -> **Consequence for the custom kinds:** with availability answered by the -> `chatelet_availability` RPC, the ephemeral `kind:22000/22001` availability -> query/response (ADR-0001) is **redundant for RPC clients**. It is only worth -> keeping if we want non-RPC Nostr clients to query availability by publishing -> an event. Revisit when the public-discovery transport is chosen (issue #2). +> **Custom kinds vs the RPC — training wheels, not redundancy:** the +> `chatelet_availability` RPC is what ships first, but the ephemeral +> `kind:22000/22001` availability query/response (ADR-0001) is **retained as a +> proposal**, not dropped. The RPC is the training wheel; the public event kind +> is the client-agnostic destination — a generic Nostr client must one day be +> able to query availability *without* speaking our private RPC (workspace +> doctrine: extensions aim to be Nostr-client-agnostic). It will be published +> over the nostrclient relay path alongside the NIP-99/52 discovery events +> (issue #2). ## Actors