Filtered to Version 0.19.0

The names lemonfiber gives its own things — the words that also name a file, a command or an argument — MUST be declared, and every locale MUST render a declared name as declared and translate only the text around it.

A member MUST be able to see their own requests, ask for something, see what the household holds, and play it.

Where the media server cannot be reached, playback MUST be declined with the reason, and MUST NOT be queued or shown as buffering.

The player MUST NOT implement request, approval or allowance logic of its own.

Where the household reaches a service that faces them, the surface MUST be able to hand them its address, whether or not that service is the front door.

Where a service a member is handed to cannot be reached from where they are, the surface MUST say so, and MUST NOT present an address it knows will not answer.

Setup MUST accept a key link (C10-R18) in place of the address, key and pin: it MUST collect the key once over the TLS the link's fingerprint verifies (C10-R20), keep only what the reply carries, and name the reason when the claim is refused.

Setup MUST accept a key link (C10-R18) in place of the address, key and pin: it MUST collect the key once over the TLS the link's fingerprint verifies (C10-R20), keep only what the reply carries, and name the reason when the claim is refused.

The core MUST answer a member's session with the member's display name as the media server holds it.

On every surface, the label of a control, a tab, a menu item or a section heading MUST name what it opens or does in at most three words and MUST NOT be a sentence; a sentence MAY explain beside it, and a name declared under G2-R14 counts as one word.

The artefact MUST publish the notification kinds as a closed union, problem, completion, update, backup, request and member, and every alert event MUST carry exactly one as notification beside its event kind: problem for every condition at warning or worse, at onset and resolution; completion for work the operator asked for finishing; update for an update to the stack or lemonfiber being available; backup for a backup that succeeded; request for a household member's request newly waiting on the operator; and member for an invitation accepted, declined or lapsed. request and member alerts MUST ride the operator's stream and wake only endpoints an operator session registered, and MUST NOT reach a member's stream; the core MUST NOT raise an alert addressed to a household member (B5-R1).

GET /api/alerts MUST carry kinds, the notification kinds this stack raises as it is configured, each from the union ARCH-R279 publishes.

A stream opened with Last-Event-ID MUST be sent, before any other event, every alert event raised after that id, oldest first, from the last 24 hours and at most the last 200; where the id is older than the oldest kept or unknown, it MUST send those kept and mark the replay partial. A stream opened without one MUST be sent no past alert (ARCH-R162).

An operator session MUST be able to register a UnifiedPush endpoint for one device with POST /api/push-endpoints, taking name, an https endpoint, and the WebPush p256dh key and auth secret, and to list them with GET /api/push-endpoints and remove one with DELETE /api/push-endpoints/{name}; the command line MUST list and remove them too. On every alert's onset and resolution the core MUST send each registered endpoint a WebPush message encrypted under RFC 8291 whose content says only that the stack has something to say, MUST forget an endpoint its distributor answers 404 or 410, and MUST refuse an endpoint that is not https or whose name another holds, naming it. A member session and a key MUST NOT register, list or remove endpoints. Every registration and removal MUST be journaled.

The space action MUST accept only, a list of categories the offer it answers names as costing nothing, and with the offer's name MUST reclaim those categories alone; a category the offer does not name MUST be refused, naming it, with nothing removed.

A member's paired client MUST be able to watch a live TV channel only through the core, which MUST open the channel's live stream on the member's behalf only where the media server answers the channel's live TV read with the member's own session and the programme on it is within the member's limits (D8-R9). The guard's item question MUST NOT stand in for either answer.

The core MUST answer the client the location of the live stream's bytes at the guarded front door with a pass the core issued for that live stream and that member alone, which lapses within a bounded time, and MUST close the live stream when its pass lapses or the member is removed (D6-R8).

The guard MUST serve a live stream's bytes, its playlists and segments included, only to a request whose pass the core confirms, asked of the core on every such request, for exactly the live stream the request names, and MUST refuse one whose pass is absent, lapsed or not confirmed, or where the core does not answer. A live stream's bytes MUST NOT be served on an item's byte route (D11-R2).

A live-stream pass MUST travel in one fixed place in one spelling, held to an exact shape, and the guard MUST refuse a request carrying it anywhere else, under another spelling or in another shape. Before it asks the core, the guard MUST hold the request to the normal form it holds an item's byte route to (one canonical path, no byte the forward would re-escape, one spelling of each parameter it reads), and MUST ask about exactly the bytes it forwards.