supermessage v0.1.2

Built from db75d7a.

These binaries are unsigned. macOS Gatekeeper and Windows
SmartScreen will both warn on first run until signing is set up.

supermessage 0.1.1

supermessage 0.1.1 fixes two Android problems found on a real phone, a OnePlus 8T running Android 14.

Fixed

Android

• No blank space above the keyboard. Typing in a room left a band the height of the keyboard between the composer and the keyboard. The app never declared how its window should respond to the keyboard, so Android slid the whole window up, and the composer lifted itself by the keyboard's height as well. The composer now sits right on the keyboard (#155).
• The timeline follows a streaming answer. After you send a message, the timeline stays on the newest content: your message, the agent's live card as it grows, the streaming answer, and the typing indicator. If you've scrolled back to read, it doesn't move you; Jump to newest takes you back (#155).

Desktop and iOS: no changes in behaviour since 0.1.0. The builds are rebuilt with the new version number, and iOS is on TestFlight as 0.1.1.

Tests and CI: the new keyboard tests run against the real on-screen keyboard. CI's emulator no longer shows the System UI "isn't responding" dialog, which had been taking focus from tests (#156, #158).

Downloads

Platform	File
macOS (universal)	supermessage_0.1.1_universal.dmg
Windows	supermessage_0.1.1_x64-setup.exe or .msi
Linux	.AppImage, .deb or .rpm
Android	supermessage_0.1.1_android-<abi>-debug.apk: arm64-v8a for most phones, x86_64 or x86 for emulators

Please read first

• The desktop builds are unsigned. macOS Gatekeeper and Windows SmartScreen will warn on first run.
• The Android APKs are debug-signed, for sideloading only. They're not on Google Play, and they're not release-signed. They install as an update over 0.1.0's APKs, and they need Android 12 or newer.
• iOS is TestFlight only. There's no App Store release.
• The known issue from 0.1.0 remains: a pending decision doesn't yet light up Needs you on any platform. Decision cards still appear in their room.

Built from 1d9c920 (tag v0.1.1).

supermessage 0.1.0

supermessage 0.1.0 brings the desktop and Android apps level with iOS. It completes the iOS-parity roadmap (M0–M8).

Verification record: docs/research/2026-10-23-ios-parity-verification.

Against iOS's 60-row feature matrix:

Platform	Parity	Partial	Missing	Not applicable
Desktop	52	3	0	5
Android	57	2	0	1

What's new since 0.0.15

Desktop (macOS, Windows, Linux)

• The agent experience: a live card for a running turn, with "What I did" on the answer. Agent cards, a long-read view, a status pill in the header, agent tiles in the roster, the "Sent to → is on it" dock, and an @ menu built from the room's cast.
• Navigation: Chats, Needs you, Agents and Search destinations. All/Unread filter chips, readable space names, and a welcome screen with a first-run demo.
• Notifications worded by the core. On Linux you can answer permissions and gates from the notification; clicking any notification opens its room. The Needs you count shows in the window title.
• Voice messages (on Linux this needs GStreamer's gst-plugins-good).
• A tray icon with live counts, and opt-in "keep running in the tray". On Linux this is offered only where a tray is actually visible.

Android

• The same agent experience and navigation, plus supermessage:// links.
• Local notifications worded by the core. Answer from the notification (the device must be unlocked first).
• Background push over UnifiedPush. It needs a distributor app, such as ntfy. Pushes carry only event_id_only ids; the app fetches and decrypts the message itself.
• Voice messages.
• Needs you and Agents home-screen widgets, with answering in place, and an ongoing notification for a running agent turn.

iOS: shipped through TestFlight, by invitation.

Downloads

Platform	File
macOS (universal)	supermessage_0.1.0_universal.dmg
Windows	supermessage_0.1.0_x64-setup.exe or .msi
Linux	.AppImage, .deb or .rpm
Android	supermessage_0.1.0_android-<abi>-debug.apk: arm64-v8a for most phones, x86_64 or x86 for emulators

Please read first

• The desktop builds are unsigned. macOS Gatekeeper and Windows SmartScreen will warn on first run.
• The Android APKs are debug-signed, for sideloading only. They're not on Google Play, and they're not release-signed. You may need to uninstall an earlier debug build first.
• iOS is TestFlight only. There's no App Store release.
• One known issue on every platform: a pending decision doesn't yet light up Needs you. Decision cards still appear in their room. See D1 in the verification record.
• Some behaviour is verified by tests, but its live check on real accounts and devices is still pending. That covers live push, lock-screen answers, widgets on a real launcher, and tray behaviour on GNOME, macOS and Windows. The record lists exactly which checks.

Built from b2f5c35 (tag v0.1.0).

supermessage v0.0.15

Built from 6af632f.

These binaries are unsigned. macOS Gatekeeper and Windows
SmartScreen will both warn on first run until signing is set up.

supermessage v0.0.11

Built from 9f2e081.

These binaries are unsigned. macOS Gatekeeper and Windows
SmartScreen will both warn on first run until signing is set up.

supermessage v0.0.9

Built from 66cca10.

There is an iOS app now

Native SwiftUI, over a Rust core this desktop app now shares with it (#24).
Everything that is a decision moved into Rust — markdown and sanitised HTML
into blocks, the render classification, room-name parsing, previews,
affordances, mentions, matrix.to parsing, custom-event rendering, display
naming, and the roster's ordering and grouping. Both clients read the same
answers, so they can no longer disagree about what a room is called or how a
message renders.

The iOS app is not distributed here — these artifacts are macOS, Linux and
Windows, as before.

The desktop, in this release

• Switching rooms is one movement instead of five (#21). A room used to
  pass through four visual states in 145ms, including a false "Nothing here
  yet." over a room holding 1,937px of history. Now: three states under one
  fade, settled at 103ms, and the list lands at the tail rather than
  travelling to it.
• An agent's reasoning is on screen (#23). It reached the device and was
  thrown away; "Thinking…" was all you got. It is now a collapsible that
  holds the last turn's reasoning after the channel closes, because the
  question becomes askable exactly when the answer arrives.
• The timeline stops losing its place (#20, #22), and stops going blank
  when a message arrives (#19).

Under both clients

• Reaction chips carry who reacted, not just how many.
• Read receipts, message editing and deletion, mute and pin, and search
  scoped to a single room — all in the core, with Tauri commands; the desktop
  UI for the last four is still to come.
• dev.agentpod.turn.v1 accepts a reasoning field and
  dev.agentpod.tool.update accepts input/output. Both render when
  present. No harness sends them yet — see docs/agentpod-events.md.

---

These binaries are unsigned. macOS Gatekeeper and Windows SmartScreen will
both warn on first run until signing is set up.

supermessage v0.0.8

Built from 55fbd73.

These binaries are unsigned. macOS Gatekeeper and Windows
SmartScreen will both warn on first run until signing is set up.

supermessage v0.0.7

Built from 21dc7bb.

These binaries are unsigned. macOS Gatekeeper and Windows
SmartScreen will both warn on first run until signing is set up.

supermessage v0.0.6

Built from e61897c.

These binaries are unsigned. macOS Gatekeeper and Windows
SmartScreen will both warn on first run until signing is set up.

supermessage v0.0.4

Agent rooms can be entered

AgentPod's Matrix Application Service provisions one room per station and invites you to each. In 0.0.3 all 32 of them sat in the roster looking like rooms, and not one could be opened: the room list includes invited rooms, and nothing in the wire format said which was which. Element could accept them; the client built for rooms whose other occupants are agents could not. That was the whole of issue #1.

• Accept / Decline, where the composer sits, replacing it. The two answer the same question — what can I do in this room? — with different answers, and a composer for a room you have not joined takes a message and loses it at the homeserver. A room that is neither joined nor invited gets neither affordance.
• An Invitation pill on the roster row, and that word in the row's accessible name right after the room's — it changes what the row is.
• membership on every room, an enum rather than a boolean, so knocked and banned cannot masquerade as joined.

Nothing is optimistic: accepting does not mark the room joined. The homeserver does, the room list reports it, and the panel gives way to the composer on that update. A refused join says so in the panel rather than leaving a button that visibly does nothing.

Known issue

A message you send from another client of the same account may still not appear (#2). Four layers have been ruled out with tests — the projection, the live streaming fold, local-echo reconciliation, and the homeserver's sliding sync, probed two-device directly. This build adds event ids to the emitting timeline diff trace, so a reproduction under RUST_LOG=supermessage=debug will settle where it goes.

---

These binaries are unsigned. macOS Gatekeeper and Windows SmartScreen will both warn on first run until signing is set up.

• macOS (universal, Intel + Apple silicon): .dmg
• Linux x86_64: .AppImage, .deb, .rpm
• Windows x86_64: .exe installer or .msi