2 files changed, 54 insertions, 11 deletions
diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 525c5c3..64364b0 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -3422,6 +3422,36 @@ lands the target is shown, not the old stream's position. Pausing the receiver
 pauses the local element too, which otherwise goes on fetching for nobody. The
 copy-URL cast has no receiver to read and keeps the ordinary player.
 
+**A television is chosen for the session, not for one film**
+(`cast-session.js`). Any cast button — Videos' toolbar, the Photos toolbar, a
+photo album's bar, the lightbox, the player — sets it, and it is held in memory
+only. A film opened
+while one is set starts its cast as a restart does: pending until the first
+segment, then the relay and `connect` (or `reload`, when the receiver is already
+connected), with the player drawn as the remote from the start. *Stop casting*
+clears it, from the player's remote or from any button.
+
+**A photo is served at `/image`, one at a time** (`cast:image`). The page scales
+it to fit 1920×1080, applies its EXIF orientation and re-encodes it as JPEG
+before it leaves: a camera original is too large for a receiver to decode in good
+time, and some formats it does not decode at all. The relay starts for it if
+nothing else has, serves it behind the stream's token with a versioned address
+(a receiver handed the same URL twice shows what it already has), and accepts
+only `image/jpeg`, `image/png` or `image/webp`. **The shell, not the page, says
+what the receiver loads:** the relay's photo URL is loaded as a picture
+(`streamType: NONE`, photo metadata, no subtitles), any other relay URL as the
+stream, and on Android no URL but the relay's own is accepted at all. A photo
+does not start the foreground service, and its load answers as soon as the
+receiver accepts it: a photo never reaches PLAYING. Only the newest photo asked
+for is sent; paging quickly shows where the reader stopped.
+
+**The interface itself is not cast.** The default media receiver plays what it
+is given and renders nothing of its own, and a rendered interface sent to it as
+live video does not work: it starts a progressive stream that arrives at real
+time only when the stream carries audio and its first seconds arrive faster than
+real time, and then holds that lead as latency — five seconds, measured. Showing
+the application on a television needs a registered receiver of our own.
+
 **Subtitles are rebased onto the relay's clock before they are sent.** The node
 extracts a track whole, so its cues carry the film's timeline, and the player
 can use them unchanged because its SourceBuffer is given `timestampOffset =
diff --git a/docs/USERGUIDE.md b/docs/USERGUIDE.md
index d6eab26..3b2f16c 100644
--- a/docs/USERGUIDE.md
+++ b/docs/USERGUIDE.md
@@ -352,7 +352,9 @@ An album browser and a player, over the folders the operator chose for it.
 ### Photos
 
 An album browser over the folders the operator chose for it, where **an album
-is a folder**. Thumbnails come from the node, already rotated correctly.
+is a folder**. Thumbnails come from the node, already rotated correctly. A
+photo opens full size, with a slideshow button that moves on every five
+seconds and stops at the album's last photo.
 
 **Location data is never shown.** Photos shows when a picture was taken and
 what took it, and no coordinates anywhere. Worth knowing, though: the
@@ -392,15 +394,25 @@ resume.
 
 ### Casting to a TV
 
-**The desktop and Android applications.** A film playing in the application can
-be sent to a cast-capable TV or dongle on the same network: *Cast to device* in
-the player, pick one from the list. On a phone, the film goes on playing silently
-on the phone while the TV shows it, and the screen can be turned off. While a
-TV plays the film, the player becomes its remote: the position shown is the
-TV's, with play/pause, 30-second jumps and a slider to go anywhere in the film.
-Devices appear as they answer, usually within a couple
-of seconds; the search carries on for a few more, for a TV that is still
-waking up.
+**The desktop and Android applications.** Films and photos can be sent to a
+cast-capable TV or dongle on the same network. The cast button is in the
+Videos toolbar, at the top of Photos, in an album's bar and in the photo
+viewer — in a group and in Search alike — and *Cast to device* is in the
+player. Devices appear as
+they answer, usually within a couple of seconds; the search carries on for a
+few more, for a TV that is still waking up.
+
+**A TV, once chosen, stays chosen** until *Stop casting*, from any cast button
+or from the player. Every film opened plays on it, and the player opens as its
+remote: the position shown is the TV's, with play/pause, 30-second jumps and a
+slider to go anywhere in the film. Every photo opened in the viewer is shown on
+it, and a slideshow pages the TV along with the screen. Choosing a TV from an
+album's bar opens its first photo. On a phone, a film goes on playing silently
+on the phone while the TV shows it, and the screen can be turned off.
+
+Photos are sent scaled to the TV's screen, upright, as an ordinary picture.
+The menus, covers and summaries stay on your phone or computer: the TV shows
+what is playing, not the application.
 
 The application decrypts the film and relays it to the TV itself, over your LAN.
 The TV is not a group member and holds no key — which is also why the relay's
@@ -981,7 +993,8 @@ Better to know now than to go looking for it:
 - **Hubs do not talk to each other yet.** Everyone in a group needs an account
   on the same hub.
 - **Casting reaches Chromecast devices** from the desktop and Android
-  applications. Support for other TV protocols is designed but not built.
+  applications, for films and photos. Music is not cast yet. Support for other
+  TV protocols is designed but not built.
 - **Some subtitle tracks cannot be shown** — the ones stored as images rather
   than text, roughly one embedded track in five. Displaying them would need
   text recognition.