README covers: - What the extension is / isn't (CMS only; customer UI in webapp; no festival entity; no central splitter) - Architecture diagram - Data model summary - Order state machine - Nostr (kind 0 / 30402 / 5; NIP-17 stub) - Public vs owner-write API surface - A worked-out webapp integration snippet showing the multi- restaurant cart flow (group by restaurant -> per-restaurant quote -> sufficient-balance check -> N place_order calls -> pay each bolt11) - Install instructions for development - Roadmap of explicitly-deferred items (NIP-44 unwrap, per- restaurant secret storage, SSE/push, HODL atomicity, foreign menu cache, image upload pipeline)
563 B
563 B
Restaurant CMS for LNbits. Build menus, manage modifiers and inventory, and process Lightning orders. Menus are published to Nostr (NIP-99 classified listings) so customer-facing webapps and aggregators (festivals, food courts, collective spaces) can subscribe live across many restaurants. Each restaurant issues its own invoice — multi- restaurant carts pay each restaurant directly, no central wallet, no splitting. Includes a Kitchen Display screen, thermal printer queue, and an order state machine (pending → paid → accepted → ready → completed).