xmatic

Submitted by JimKnopfIoT on Tue, 2026/09/01 - 23:46

Rating:

Your rating: None Average: 5 (6 votes)

Native Matrix client built on matrix-rust-sdk with a Silica UI.

FEATURES

- Sliding sync, end-to-end encryption, cross-signing, device verification (both directions), key backup and recovery
- Rooms, spaces (nested), direct chats, threads (answer in one or start one), room directory search
- Create rooms, invite, leave; member list and member profiles with moderation
- Send, edit, delete, reply, pagination in encrypted rooms
- Search the messages of a conversation. The index lives on the device and is encrypted with the same key as the rest of the local storage; the query never leaves the phone
- Formatted messages: bold, italic, code, quotes, lists and links render as themselves
- Pinned messages, favourites, low priority, per-room mute, ignored users
- A line marks where reading stopped. A room opens there or at its newest message, whichever you set, and says who has read what
- A message whose authenticity could not be confirmed carries a mark next to its time, with a page explaining what each mark means
- Four coloured lines say how safe the device is: backup, recovery, cross-signing, local storage
- Reactions from an emoji picker whose first tab you fill yourself
- Pictures, files, sharing (also as share target from Gallery / file manager)
- Voice messages; voice and video calls (classic 1:1 VoIP; MatrixRTC-only clients cannot be called)
- Notifications, offline send queue, encrypted local storage
- OAuth (MAS) login, device-code login, password login
- 29 interface languages, switchable in the app

LANGUAGES

The interface is available in the 24 official languages of the European Union
plus Russian, Norwegian, Icelandic, Simplified Chinese and Hindi. Norwegian was contributed by a Norwegian
speaker and German is the project language; the rest are machine translations,
usable but unchecked. Account has a language setting of its own, English
included, so there is always a way back out of one. A change applies at the
next start.

Corrections are welcome at the GitHub repository below - the file to edit is
translations/harbour-xmatic-<language>.ts, and translations/STATUS.md says
which languages have been read by a native speaker.

LOCAL STORAGE

Session tokens and the message database are encrypted with a key from Sailfish
Secrets.

Some Sailfish images ship only the client library of that key service and not
the service itself. On such a device xmatic no longer creates an unencrypted
database quietly: it says what is missing, gives the command to install it and
a command to check the result with, and offers to continue without encryption
as an explicit choice. The package also requires the service, so on most
devices this never comes up.

An installation that already holds data is never blocked - that would strand
its room keys. Where a database simply predates the key, the encryption page
offers to re-create it encrypted, which costs one sign-out and your recovery
key.

How safe the device is stands in four coloured lines - backup, recovery,
cross-signing, local storage. Green is in order, orange is something you can
put right, red is something the system does not offer. If anything is not
green, the app says so once after starting, with the action that fits and
"later" always available. When everything is green you never see any of it.

WHY IS THE PACKAGE SO BIG?

The app ships the complete Matrix stack statically: matrix-rust-sdk, E2EE
(vodozemac), sliding sync, rustls, its own HTTP runtime and a bundled SQLite.
None of that exists as a system library on Sailfish OS, and Qt 5.6 is too old
for the C++ alternatives - which is exactly why the protocol core is written in
Rust. Installed size ~60 MB (Element X, same SDK: ~100 MB), RPM ~18 MB.

NO BACKGROUND DAEMON

Messages arrive while the app is running (the cover is enough). Like other
daemonless messengers on this platform, a closed app does not receive.

PUSH NOTIFICATIONS (off by default)

Requested by users. It is off, it has its own setting, and it does nothing
until you switch it on by hand. It needs a UnifiedPush distributor installed
separately and a push gateway you choose yourself, and it discloses metadata —
which rooms, at what times — to parties that otherwise know nothing about you.

Details, and what to weigh before turning it on:
https://github.com/JimKnopfIoT/harbour-xmatic/blob/master/docs/PUSH.md

Leaving it off changes nothing.

ARCHITECTURES

aarch64 (Sailfish OS 5.0+), armv7hl (Sailfish OS 4.6+). Tested on J2, Xperia10III and Gemini PDA.

REQUIREMENTS

xmatic syncs over simplified sliding sync (MSC4186), the same mechanism
Element X uses. Your homeserver must support it. If it does not, sign-in
works but no rooms load and the app keeps showing "Offline".

How to check your server: open this address in a browser

https://YOUR-SERVER/_matrix/client/versions

and look for this line:

"org.matrix.simplified_msc3575": true

If it is missing, xmatic cannot load your rooms from that server.

Sign-in methods supported: OAuth 2.0 / Matrix Authentication Service,
device code ("Sign in on another device"), and username plus password on
servers without OAuth.

The classic SSO redirect sign-in (SAML, CAS) is not supported.

Written with Claude Code (Anthropic), icons included; the protocol core is upstream matrix-rust-sdk.

Source, issues, releases:
https://github.com/JimKnopfIoT/harbour-xmatic

Screenshots:

Keywords:

Application versions:

Attachment	Size	Date
harbour-xmatic-0.28.0-1.aarch64.rpm	18.35 MB	01/09/2026 - 23:45
harbour-xmatic-0.28.0-1.armv7hl.rpm	18.87 MB	01/09/2026 - 23:45

Changelog:

- Rooms stopped receiving on accounts with many rooms. 0.27.0 widened the sync
window per room so the unread badge could count, and that number is
multiplied by the rooms in one request - which the room list grows to a
hundred at a time. On an account with two hundred rooms the request asked for
forty thousand events, timed out, and everything but the twenty most recent
rooms stopped updating, silently and for good. The window is back where it
was, and the badge now says where it stopped looking: it counts to twenty and
shows "20+" beyond, in the list and on the cover.
- The emoji comparison had no buttons. Verifying could not be finished from
that page at all in 0.26.2 and 0.27.0 - neither a device of one's own nor
another person - because the two answers were laid out in a way that gave
them a width of zero. They are back.
- Verifying another person moved out of the encryption page, where it sat as a
Matrix address to type in directly under the button that verifies one's own
second device. In a two-party encrypted chat the room's own menu now offers
it without asking for an address; for everybody else there is one entry in
the chat list's pull-down.
- The security page that comes up after signing in no longer stays on screen
once everything is green. Entering the recovery key settles it from the page
above, and coming back landed on the alarm that had just been cleared.
- A failed request stopped claiming there is no key backup. Asking the server
is a question over the network, and while a sync fault made the app believe
it was offline, the answer "could not ask" was read as "there is none" - so
the security page raised an alarm about a backup that was on the server all
along. It says the server could not be asked, and asks again once the
connection is back.
- The cover says when nothing is arriving. Being cut off was written under the
room's name and in the chat list, but not on the tile - and this app has no
background service, so the tile is how it is watched.
- Account has an error log now, at the top of its pull-down menu. Whatever
fails is kept there for the run, newest first, instead of flashing as a red
line on one page and being overwritten by the next failure. Identifiers are
already stripped by the core, so the list can be copied and passed on as it
stands. Nothing is written to disk.
- "Token is not active" no longer appears as an error. The sign-in token is
rotated in the background, and a download that was in flight across the
rotation came back with that message - which reads as an ended session while
the session is perfectly alive. It goes to the log; a session that really has
ended still signs out and says so.
- Everything a message can be done to is on a page now instead of a context
menu. That menu shares its machinery with the room's pull-down: opened on a
message near the top of the view it took the pull-down's place, and with that
on screen there was no way to leave the room, call, search it or open its
page at all.
- Forwarding works on attachments. A picture could only be forwarded from the
full-screen view, and every other attachment offered "Forward" and then sent
the file name as a sentence.
- Push notifications, asked for by users and off by default. They have their
own setting and do nothing until switched on by hand: Account › Push
notifications. A UnifiedPush distributor has to be installed separately - it
is the app that holds the connection, this client still has no background
service of its own - and a push gateway has to be chosen, because a
homeserver cannot talk to a distributor directly and nobody can guess whose
gateway you trust. Notifications carry no message text; the message is
fetched and decrypted on the device. What it does disclose, and to whom, is
written out in docs/PUSH.md - read that before turning it on. Leaving it off
changes nothing.
- A picture in a reply quote is shown whole and in a frame of its own. It was
cropped to a square out of the middle, which is where a photograph says the
least, and it lay against the reply's text with no edge to separate it.

Comments

kaulian

Wed, 2026/09/02 - 07:21

Search form

Main menu

You are here

User login

Categories

Tags Cloud

Recent comments

Who's online

xmatic

Category:

Keywords:

Comments