Four comments that describe a client from before this year

A coverage review measured each backend against the protocol's own surface, and
these turned up on the way: comments telling the next person to read them that
something is unimplemented when it landed weeks ago. That is the expensive kind
of wrong, because it invites the work to be done twice.

Discord's poll extractor said voting "is not implemented"; it is, in polls.rs.
Kick's said voting "goes through the player"; it goes through api.rs and the
card beside the line. Discord's VOICE_SERVER_UPDATE said it was "reported
rather than used" nine lines above the call that uses it. And Matrix's
verification header claimed self-verification only, which stopped being true
when start_user_verification was added.

Each is rewritten to say what the code does, and where the other half lives.
The Matrix one now names what is genuinely still missing there - QR
verification - rather than something that is not.

Part of #168.

Co-Authored-By: Claude Opus 5 <[email protected]>

src/backend/discord/gateway.rs

@@ -1085,9 +1085,11 @@ pub(super) async fn run_gateway(state: &AppState, config: &DiscordAccountConfig,
                     }
 
                     "VOICE_SERVER_UPDATE" => {
-                        // The endpoint and token an audio implementation would
-                        // open its own connection to. Reported rather than
-                        // used: this build establishes the session only.
+                        // The endpoint and token the audio connection is
+                        // opened against. Announced to the client as well as
+                        // used, because a frontend showing a call wants to
+                        // know the session moved even though it is this
+                        // daemon that carries the audio.
                         state.events.emit(
                             "discordVoiceServer",
                             json!({

src/backend/discord/messages.rs

@@ -421,10 +421,13 @@ pub(super) fn extract_stickers(d: &Value) -> Vec<Attachment> {
 
 /// A poll, as the text of the question and its options.
 ///
-/// Voting is Discord's own interactive machinery and is not implemented (see
-/// the slash-commands issue), but a poll-only message used to arrive as
-/// nothing - so a channel would go quiet in the middle of a decision being
-/// made. This is what was actually asked, which is the part that matters.
+/// This is the record of what was asked, written into the log. Answering one
+/// is a separate thing in `polls.rs`, which draws the same poll on a card -
+/// the log keeps what was asked, the card is the part that can be acted on.
+///
+/// Worth having on its own even so: a poll-only message used to arrive as
+/// nothing, so a channel would go quiet in the middle of a decision being
+/// made.
 pub(super) fn extract_poll(d: &Value) -> Option<String> {
     let poll = d.get("poll").filter(|p| p.is_object())?;
     let question = poll["question"]["text"].as_str().unwrap_or("Poll");

src/backend/kick/chat.rs

@@ -274,10 +274,9 @@ pub(super) fn handle_event(
             );
         }
 
-        // A poll running on stream. Announced rather than made interactive:
-        // voting goes through the player, and a chat client showing the
-        // question and the options is the part somebody reading chat is
-        // missing - a running poll is otherwise invisible here.
+        // A poll running on stream, written into the log as a line and drawn
+        // on a card that can be voted in - the line is the record of what was
+        // asked, the card is the thing somebody can answer.
         //
         // One line per poll, rewritten as the votes come in. Kick sends this
         // event on every vote, so recording each one put a near-identical

src/backend/matrix/verification.rs

@@ -1,7 +1,8 @@
-//! Interactive session verification (SAS - "compare emoji") between two of
-//! *our own* logged-in sessions. Self-verification only - no cross-user
-//! identity verification (a materially bigger feature, not what was asked
-//! for). Doesn't change the existing decrypt/share trust model
+//! Interactive verification (SAS - "compare emoji"), between two of *our own*
+//! logged-in sessions and, since `start_user_verification`, with somebody
+//! else's identity as well. What is still absent is QR-code verification:
+//! this compares emoji or it does nothing. Doesn't change the existing
+//! decrypt/share trust model
 //! (`TrustRequirement::Untrusted`/`CollectStrategy::AllDevices` in
 //! crypto.rs stay as-is) - verification here is purely informational/
 //! trust-building for the user.