Lightning 0.9.4
A release about being able to sign in, and about a call that stops working
while telling you nothing is wrong. Two of the fixes below came from people
who reported them the same day; the rest came from a deep audit of the parts
of the client nobody had read end to end.
Signing in to a strict homeserver works again
If your homeserver is continuwuity, OAuth sign-in failed outright with
invalid_client_metadata: HTTP redirect URIs for native applications do
not need to specify a port.
Lightning registered its loopback callback with the port it happened to be
listening on. RFC 8252 says a native application takes an ephemeral port at
the time of the request, and that the authorization server must accept any
port — so pinning one is invalid metadata, and a server that checks says no.
It no longer pins the port. Nothing about the callback itself changed: it is
still loopback-only, still an ephemeral port, still refused if the response
comes back to anything else.
A room opened from a notification loads again
Clicking a notification took you to the room and then showed nothing — no
history, no scrolling back, and it stayed that way until you opened a
different room and came back.
The room was being selected rather than opened. Every other way into a
room in Lightning — the room list, the quick switcher, search, a link, the
Spaces rail — goes through the same code that starts the room's live
connection to the server. The notification path did not, so the room had no
live connection and nothing to show. Reported from Windows, where a
notification is the main way most people ever took that path.
A thread notification had a second problem: it carried an internal identifier
that is not a room id at all. That is fixed too, and it had to be, because
opening the room without fixing it would have disconnected whichever room you
were already reading.
The bell menu used the same route and is fixed with it.
Calls
A participant who is really in the call no longer disappears from it.
This is the important one, and it has two halves that produced the same
symptom.
The first is a membership that is born already expired. Lightning re-publishes
its call membership every minute, and one of the two places that writes it
measured the expiry from the wrong instant — so a refresh twenty minutes into
a call, or a rejoin after an unclean exit, could publish a deadline that had
already passed. Every other client drops it, including Lightning itself: the
participant list can empty out with you still in the call, and everyone else
rotates their media keys without you. You stay heard and stop hearing.
The second is that Lightning trusted its local copy of the room's state even
when that copy was missing somebody. Now, when the call service reports a
participant that no membership accounts for, Lightning asks the homeserver
directly instead of believing the copy. The two answers are merged rather than
one replacing the other, so a fresh publish cannot be erased by a slightly
older snapshot, and a stale local copy cannot bring back somebody who left.
A call that cannot connect now says which step failed. "Couldn't connect
to the call" covered fifteen different failures — a DNS failure, an expired
certificate, a captive portal, a rate limit and an outright refusal from the
service all read identically. Each now says what actually happened.
A call reaches a service with more than one address. Lightning tried only
the first address a hostname resolved to. If that one was unreachable — most
commonly an IPv6 address on a machine with no working IPv6 route — the call
failed even though another address would have worked. It now tries them all,
inside the same overall time budget, and stops immediately if the service
itself refuses rather than retrying somewhere else.
Your chosen camera and microphone are used. The device picker on the
MatrixRTC lane was decoration: the pipeline opened whatever the platform
considered default.
Transient reactions in calls, in the same format Element Call uses, and a
call you cannot join now says so before you press Join rather than after.
Messages and the timeline
- A message containing certain non-Latin text could vanish on send. Two
places sliced text by byte position rather than by character, which crashes
on a multi-byte character; the crash was swallowed, so the message simply
never appeared and nothing said why. - An edit, a redaction or a late decryption now reaches the message it
changed when a long history is loaded. It was being announced against the
wrong row. - A redacted message is removed from local search. It could still be found
by its own text. - An attached audio file carries its length, instead of showing 0:00.
Accounts
Adding a second account now behaves like switching to one. It did not, and
two things followed. Your hidden-image list from the first account was written
over the second account's; and the first account's ignore list stayed in force,
so somebody the new account had ignored could still ring it, and somebody the
old account had ignored was silently suppressed.
Keyboard
A set of shortcuts familiar from other chat clients, all rebindable in
Settings, none of them colliding with what was already there:
- Up arrow in an empty message box edits your last message.
- Ctrl+/ shows the shortcut list, Ctrl+, opens Settings.
- Ctrl+U shows the people in the room, Ctrl+Shift+P the pinned messages.
- Ctrl+Shift+E, Ctrl+Shift+G, Ctrl+Shift+O for emoji, GIFs and
attachments; Ctrl+Shift+V toggles your camera in a call and
Ctrl+Alt+A returns to one. - Shift+Page Up jumps to the oldest unread message.
Escape also works properly again: with a thread panel or the find bar open,
opening Settings left two things claiming the key and Qt gave it to neither,
so Escape stopped closing Settings.
macOS
- The menu-bar icon is a proper monochrome template icon, which follows the
light and dark menu bar like every other status item. The Dock and Finder
icons are unchanged. - The bundle carries its own GStreamer plugin scanner, so the warning about
an external plugin loader at every launch is gone.
Linux
An AppImage that updates itself now restarts. The relaunch inherited a
temporary directory that no longer existed, and, when it had been started by
an extractor, assumed it could mount itself.
Under the hood
Sync no longer dies silently on a single network error and stops asking the
server for the complete state of every room on every poll; the room list has
one producer instead of two disagreeing about the same index; credentials
migrate under the right account; and several places that could report a failed
network read as "there is nothing there" now say which it was.
Known limitations
- macOS packages are ad-hoc signed and not notarized. Windows packages are
unsigned. The signed update manifest is the integrity guarantee on every
platform. - macOS is Apple Silicon only, macOS 26 or newer.
This is a read-only mirror. It is not a release authority.
The canonical Lightning 0.9.4 release lives on GitLab:
https://gitlab.smetonis.net/Mizerd/lightning/-/releases/v0.9.4
The files attached here are byte-identical copies of the artifacts published
there. They exist so downloads do not all have to come from one small server.
Nothing about this page decides anything: it does not determine what version
exists, what is installable, or what Lightning will accept.
Verify any download against the SHA256SUMS asset, which is itself a copy of
the published one.
Lightning's in-app updater fetches its update manifest only from GitLab and
verifies an Ed25519 signature made with a key that exists nowhere near GitHub.
Every downloaded file is checked against the SHA-256 recorded in that signed
manifest before it is installed, so replacing a file here cannot cause Lightning
to install it.
Issues, source, and history: https://gitlab.smetonis.net/Mizerd/lightning