talat sync, the companion app, and UI polish

Overview

Mike and Nick held their regular development sync on talat, reviewing current workstreams and polish items. The main focus was Nick's now-merged talat sync service (powering both cross-device meeting sync and the forthcoming iOS companion app), alongside UI refinements, speaker-recognition tuning, and model-download performance. No major blockers emerged; both agreed most remaining work is quality-of-life polish, with the companion app ready to submit to Apple.

Key discussion points

Live speaker assignment and speaker recognition

• Mike has built the live speaker assignment feature, which lets you assign a speaker to what someone is saying while they are still talking. This was a frequently requested quality-of-life item; previously the row just showed "listening" or tried to guess.
• Nick raised a recognition-threshold concern from testing: during one participant's long monologues (with no voice references saved and not locked to the room), the UI kept flickering between "listening" and their name. He suggested asymmetric thresholds: a higher bar to initially recognise someone, then requiring a drop below a separate lower threshold before flicking back to unassigned, rather than a single pivot point. Mike agreed to take a look.

Model download speeds and caching

• Slow model downloads (one user reported single-digit kilobytes per second) are suspected to be a CDN issue, though Nick couldn't correlate the slowness to any reported Cloudflare incidents.
• Nick is exploring smarter caching.
• Mike is looking into reducing the bundle size.

talat sync (device-to-device sync and companion app relay)

• talat sync is now merged; test and production services are live.
• Architecture decision: rather than pure peer-to-peer, sync now routes through a central relay server, even between two of Nick's own machines. Nick was uncomfortable with pure peer-to-peer due to network traversal risks and the amount of server logic it loaded into the desktop app. Payloads are end-to-end encrypted; the relay tries to spend as little time holding data as possible, and waits for the desktop to be active rather than holding indefinitely.
• The two originally separate branches (device-to-device sync and the companion app) merged but could still be released independently since they now share the relay service.
• Open questions Nick flagged: when to trigger a sync (call end versus the meeting being fully processed with summary and actions generated), and how to handle later edits to titles on either the source or destination computer. His intended scope is a unified view of transcripts across machines, not perfect real-time sync.

Companion app (iOS and watch)

• Nick is creating the app in App Store Connect to get the review ball rolling; even if rejected, they can pursue TestFlight review to share an opt-in link (for example via Discord).
• Background noise suppression (requested after a noisy test call from a café) was tested by jangling and scraping keys on a desk, and it suppressed the noise really well.
• Live notification works: the recording-in-progress notification persists when the iPhone is locked.
• Companion recordings land in Meetings (not Imports), sourced as "via phone" or "via watch"; Nick feels this makes more sense than the old import behaviour. There was some uncertainty about whether phone recordings should be movable between meetings and imports.
• The app is currently a plain audio recorder (record, stop, sync). Nick has aspirations to make it smarter, including an indicative live transcript (not the actual transcript, purely to show transcription is happening). The watch app will just indicate activity; not an MVP concern.

On-device transcription (future consideration)

• Nick is keen on on-device transcription for iOS; FluidAudio and Neural Engine support make it doable. It was noted that iOS 27 may ship its own on-device model, as the Mac now has.
• Shared concern: language support, since the native model reportedly only supports a handful of languages. Mike suggested that if they use their own model it should be multilingual only (skip the English-specific one). Nemotron was raised as an option since they still use it for some languages. Agreed this is not blocking anything and won't hold up the current release.

Recording-state capsule redesign

• Mic and system-audio-output selection, currently buried in the meeting-settings cog (awkward because the cog also appears on upcoming and closed meetings), are being moved up into the repurposed recording-state capsule at the top.
• Mike's main concern: the recording capsule looks like the stop button, so users may be nervous clicking there to access recording options. Nick acknowledged this is partly learned behaviour but agreed cautious users will share it; the tooltip currently says "recording options", which Nick wants to make more explicit ("click to reveal"). Mike suggested a settings icon next to the dropdown.
• The mute-button colours in the draft went a bit further than intended (they exist today but very muted). The capsule's recording light could be made reactive to speech.

Audio device and output tapping simplification

• It was suggested they may never need to let users choose which output gets tapped: the system can tap specific processes, and users almost never route different audio streams to different devices simultaneously. Both agreed it's probably counterintuitive to require output selection at all.
• The ideal is to present users no options and always do the right thing (for example auto-tracking Chrome's output). The tricky case: when a recording is started manually and then Zoom grabs a different mic, whether to relink. Agreed to hold off on the capsule mic and output changes and instead focus on reducing or eliminating the need to show these options at all.

Provenance column on the home (meetings) page

• Nick strongly dislikes the third column showing provenance ("via Google Meet", "detected Chrome", "calendar" and so on); he finds it confusing and hasn't yet landed on a redesign he's happy with. Some labels were shortened in 1.12 (for example "detected Google Chrome" to "detected Chrome").
• Mike's suggestion (which would require backend changes): replace it with a one-sentence summary of what the meeting was about, which is far more useful when scanning the page than the platform. Platform info could be reduced to an icon or folded into the title string for upcoming meetings.
• Nick also dislikes the decorative circle glyph on every row, which does nothing except turn talat-pink for today's upcoming meetings. Mike thinks the home page is the weakest page in the app and asked Nick to do some designs.

Other UI and polish items

• Transcript bars: Nick wants better treatment of the thick black bar and the pop-in when a long monologue is finalised (the bars all appear at once). Mike doesn't mind it but suggested animating it. Nick acknowledged it's splitting hairs but stressed that we have to blow people away when they do turn up.
• The 1.12 transcript view is now denser (more lines visible); Nick is abandoning the "prose" view. It will stay under experimental but won't make the main line. Mike doesn't mind it but prefers the other view.
• A layout-shift issue on transcripts was dismissed as irrelevant for the fraction of a percent of cases where it happens.
• Back-linking: Nick noted it oddly offers linking to a meeting that already started or finished (his recurring fake "planning" test meeting); flagged as a bug.
• Nick highlighted recent additions: the ability to pin the sidebar shut (not just open), with a delayed tooltip for hesitant users, and the new notification corner (acknowledging more apps are taking the right-hand corner). Mike likes both. Mike mentioned a collapsed sidebar with unclear tooltips in another product as an anti-pattern to avoid.

Onboarding and MCP

• Nick revisited the idea of adding MCP to onboarding given its importance and the new larger onboarding canvas, wanting the first experience to impress without bloating it to fifty steps.
• Mike was cautious: MCP as a final step isn't too offensive, but stats show most people currently complete every onboarding step; he'd only worry if completion started dropping off.

Decisions made

• talat sync routes through a central encrypted relay, not pure peer-to-peer; confirmed as the accepted model.
• Hold off on the capsule mic and output redesign; instead focus on removing the need to select an output at all and making the app do the right thing automatically.
• Companion recordings go into Meetings, not Imports.
• On-device mobile transcription is deferred; not for the first release. The current companion app ships as-is.
• Abandon the prose transcript view for the main line (it remains experimental only).
• Submit the companion app to Apple now to start the review process.

Additional notes

• Nick to work through Mike's sync feedback and get the companion app submitted to Apple; he plans to crack on with clearing long-running loose ends.
• The companion and watch apps have had extensive manual testing.
• Nick is reusing release and App Store setup patterns from a previous mobile app to streamline the talat mobile release.