Privacy Policy

Last updated: 2026-11-05

consolet is not released yet. This page describes the app as it is built today, and it changes with the app.

This policy explains what the consolet Android app (name.gpm.consolet) does with data. It covers the app only.

The short version: consolet connects your phone straight to your own machines, and keeps what it learns about them on the phone. If you run the optional relay on a machine of yours at home, the phone tells it that home’s machines over an encrypted channel, with their KVMs and, if you agree, their KVM logins sealed for it, and what the relay keeps stays on that machine. Unless you start it with --no-backend, the relay also links to our server while a pairing is open or a paired phone has told it the number of its account with us, and a phone signed in with Pro can then reach the relay through our server when the home network and your VPN fail; our server passes that encrypted channel and cannot read it. The relay can also ask our website, which GitLab serves, for a newer signed version of itself: that request carries only the relay’s version and system (Updates says when it happens and how to turn it off). You need no account to use it. Sync between your phones is optional, part of Pro and end-to-end encrypted: our server keeps what it cannot read. The only things our server learns about you are the address you sign in with, what you send in a report, if you turn sync on, the facts listed under Sync, and, if you have a relay, the facts listed under Your relay. The Google Play build also sends crash reports and usage statistics to Google’s Firebase, both on until you turn them off (Diagnostics); the store-free build sends neither.

Who is responsible

Gabriele Proietti Mattia is the data controller for the processing described here. Contact: apps@gpm.name.

Connections to your machines

These go straight from your phone to your machine, over your own network or your own VPN. We do not see them, pass them on or keep a copy.

SSH. The app connects to the machines you add, signing in with the key made in your phone’s hardware, a key from your vault or a password saved in it. It confirms the machine’s host key the first time and remembers it. A foreground service, with a notification, keeps the connections you opened alive while the app is in the background.
What it reads from a machine. Over SSH, the app reads CPU, memory and network (from /proc on Linux, or from the consolet command-line tool where /proc is not there, such as Windows), the list of tmux sessions and the screen of a tmux pane that has a coding agent in it, and, for Claude Code, what its hook records on the machine. This is used to show the machine’s state and to catch a command or a link that an agent asks you to run or open. A caught command goes to the clipboard on your phone; it is never run for you.
Waking a machine. The app sends a Wake-on-LAN packet on the local network the phone is on, or asks a machine you chose (over SSH), a KVM or your relay (below) to wake it. The packet is sent only on a Wi-Fi or Ethernet network the phone is on, never over the mobile network.
KVM devices. For a PiKVM or JetKVM the app talks to the address you give it, signs in with the password you saved, and shows the KVM’s own web page in a WebView inside the app. The session cookie is set for that page only and removed when you leave it. The app asks you before it trusts a certificate it does not know, and before it uses plain HTTP. If your relay reads that KVM (below), the phone does not read its lights or picture itself; only a PiKVM with two-factor sign-in, or one the relay has no login for, is still read by the phone.
Whether a machine is up. While the app is on screen it tries each machine’s SSH port every 30 seconds, except the machines your relay reads, which the phone leaves to the relay.
Adding the relay’s key. If you ask, and after a yes that names the machines and shows the line, the app signs in to each of them over its own SSH and adds your relay’s public key line to ~/.ssh/authorized_keys when it is not there yet. Nothing else on the machine is changed.

None of what is read from a machine reaches our service, except as part of the encrypted sync you turn on, or in the channel to your relay when it passes through our service, and then only sealed (see Sync and Your relay).

Your relay

The relay is optional. It is a mode of the consolet command-line tool, consolet relay, that you install on an always-on machine of yours at home, such as a NAS (on Linux, or on Windows as a service). It runs on your machine and keeps what it keeps there. It reaches a server of ours in one way only, the link described under “Finding it, and the link to our server” below, and our website, which GitLab serves, in one way only, the update check described under “Updates”; apart from those two, nothing in this section reaches us.

Pairing. The relay prints a one-time code, good for 10 minutes and for one phone and void after five wrong tries, and a line for each way in (its address on the home network, its tailnet address, and its id for the way through our service) with the code, which you type into the app, or, for a relay the app found on the Wi-Fi, the code alone. The relay proves to the phone that it is the one that opened the code, with a proof made from the code; for a relay old enough not to send one, the app shows its fingerprint for you to compare. The phone and the relay then know each other by their public keys: the phone’s key is made in its hardware (the Android Keystore) for relays alone, and its private part never leaves it. The phone gives the relay its model as its name and, if it is signed in, the number of its account with us (a relay paired before you signed in is told it once, the next time the phone connects to it).
Finding it, and the link to our server. The app looks for relays on the Wi-Fi or Ethernet network the phone is on, never over mobile data and only while it is open: on the pairing page, and when a paired relay does not answer at its addresses. It broadcasts one datagram of 256 bytes to UDP port 7420. The relay answers only an address of a home network (10.x, 172.16 to 31.x, 192.168.x or 169.254.x), with its id, its host name, its port and whether a pairing is open. consolet relay --no-find turns this off. Unless it is started with --no-backend, the relay opens a connection to consolet-app.gpm.name whenever a pairing is open or a paired phone has named an account, and keeps it open while that holds. Through it the relay tells our server its public key and id, a signature that proves the key, its version, whether a pairing is open and the numbers of the accounts of its paired phones. That is the same whether or not any phone has Pro.
The channel. The phone reaches the relay at the addresses the relay lists or that you typed, on your home network or over your own VPN such as Tailscale, then at an address the Wi-Fi search found that the relay does not list, and last, only if it is signed in and has Pro, through our service. The channel is encrypted from end to end between the two: a new P-256 key agreement for each connection, AES-256-GCM for every message, and each end proving its key. A phone that is not paired can do nothing but pair. Through our service the phone sends its account’s key and the relay’s id; our server passes each message between the phone and the relay and does not read it, and the phone checks the relay’s key as on any other way.
Updates. consolet relay update asks https://consolet.gpm.name/relay/ for two small files, latest.json and its signature, and, only when the release they name is newer than the relay’s own, for the program file for the relay’s system. Each request carries a User-Agent of the form consolet/<version> (<os>/<arch>) (the relay’s version and system) and nothing else of the relay’s or yours: no relay id, no account, no phone, no cookie. The phone takes no part. The site is served by GitLab Pages (GitLab.com), through a name of ours that points at it and is not passed through Cloudflare. GitLab receives these requests, with the relay’s IP address, as any web host does, and keeps what it keeps under its own terms; no server of ours is in the path and we keep nothing of it. The relay replaces its program only with a release signed with the author’s key, whose public half is built into the program, only with a version newer than its own (never an older one), and only if the file’s size and SHA-256 are the ones the signed list names and the file answers version with that version. It then keeps the old program beside the new one, as consolet.old, and puts the new one in its place. When: on Linux, nothing checks by itself until you install and enable the consolet-relay-update timer; it then runs once a day, up to 6 hours late, and at the next boot if the machine was off, and, if the relay was running, restarts it on the new program and, if the relay stops within 20 seconds, puts the old program back and restarts it on that. You can also run consolet relay update yourself; the running relay stays on the old program until you restart it. On Windows the relay’s service checks about once a day, after a random delay of up to 6 hours, unless it was installed with --no-update; after replacing its program it stops with an error so that Windows starts the new one, and nothing puts the old one back. Turning it off: on Linux, sudo systemctl disable --now consolet-relay-update.timer (or never enable it); on Windows, install the service with --no-update (once it is installed, consolet relay uninstall and install it again with it). What the timer’s check said is written to the system journal, what the Windows service’s said to the Windows event log; a check you run yourself prints on your terminal.
What our server sees of it. When the relay links, our server learns the relay’s public key and id, the numbers of the accounts of its paired phones, whether a pairing is open, the relay’s version and the relay’s IP address. When a phone connects through it, our server learns which account connects to which relay and when, the phone’s IP address, and the size and time of each message. It cannot read a message: the channel above is sealed between the phone and the relay, which keep the keys. A phone needs to be signed in and to have Pro to use this way. Our server turns away a phone whose account is not one the relay named, unless the relay named none or a pairing is open, so that a new phone can pair; the relay itself lets such a phone do nothing but pair. It keeps the links and connections in memory only, nothing on disk. Its log holds the first six characters of a relay’s id, account numbers, counts, sizes and whether a link or connection came up or went down, and never a message, a key, a signature or the rest of an id.
What the phone sends it. The machines of the place you chose for the relay: their names, addresses, SSH ports and users, MAC addresses, whether each is Linux or Windows, and the host keys you trusted. For a machine that has a KVM: its kind (PiKVM or JetKVM), address and user, whether it signs in with two factors, the certificate you pinned, whether you agreed to plain HTTP, and its power board (ATX, DC or none). A KVM’s login is sent only if you agreed, for that relay, on a page that comes before the vault is asked for, with a switch for each KVM. With the vault open, the phone takes that one password and seals it for the relay’s key before it goes into the channel; the seal is tied to that machine, address and user. The relay can open it, and does, to sign in to a PiKVM; a JetKVM’s login it keeps and does not use in this version. No other password and no key leaves the vault for the relay. Then what you ask of it: to wake a machine, reboot it or shut it down, press a PiKVM’s ATX, try it again, or list or remove the phones paired with it.
What it does. It tries each machine’s SSH port, signs in with its own SSH key, made on the relay, to read CPU, memory, network and what Claude Code’s hook records, sends Wake-on-LAN packets on the home network, and reboots or shuts down a machine when a paired phone asks. While the app is on screen and the relay answers, the phone reads those machines from the relay and does not check them itself.
What it does with a KVM. It signs in to a PiKVM with the login it was sent, reads its ATX lights every round (10 seconds unless the relay was started with another) and a picture of its screen about every 30 seconds, and reads a JetKVM’s DC power board (on or off, volts, amps and watts) from its metrics page, which needs no login. It presses the ATX of a PiKVM whose board is ATX (power on, power off, hard off, hard reset) when a paired phone asks, and does not repeat a press that got no answer. It sends nothing to a KVM whose certificate it does not trust, which is the system’s trust for that address or the pin your phone sent, and uses plain HTTP only if you agreed. What it reads goes to the paired phones: the lights if the machine’s board is ATX, the DC reading if it is DC, and the picture. A phone asks for the picture only while a screen of the app shows it, and keeps it in memory only.
What it keeps, on that machine. Its own keys; the paired phones (an id, the model, the public key, when it was paired); the machines the phone sent, with their KVMs; a pairing code while one is pending; and a day of history, one point a minute for each machine (whether it answered, CPU, memory and network). A KVM’s login is kept sealed, as the phone sent it, in the same directory as the key that opens it, so whoever can read that directory can open it. The password it opens to is held only while the relay signs in, and the KVM’s session in memory. What Claude Code’s hook records, and what the relay last read from each KVM (the lights, the DC reading and the newest picture, which the next one replaces), are held in memory only; none of it is in the history. The directory can be read only by the relay’s own user and root. Its log, in the system journal, records connections, pairings, whether each machine answers and how signing in to it went, each KVM’s address and how reading it went, and each ATX press with the name of the phone that asked, with the address a phone connected from and its name, and never a code, a proof, an account number, a key, a password, a session, a picture or what a machine printed. Besides the paired phones, it keeps for each one the account number it named, and a small file saying whether the link to our server is up and since when.
Removing it. Unpairing in the app asks the relay to forget the phone when the relay can be reached, and otherwise gives you the command that does it on the relay (consolet relay remove). That does not remove the machines or the KVM logins it holds, and it goes on reading the KVMs. Turning a KVM’s switch off on the relay’s page in the app makes the next set of machines the phone sends carry no login for it, and the relay replaces its copy with that. Removing a phone from the relay takes its account number with it; with no account named and no pairing open the relay closes its link to our server. Deleting the relay’s state directory removes everything it kept.

What stays on your device

Everything about your machines: their names, addresses, users, MAC addresses, KVM addresses, the host keys and KVM certificates you trusted, what happens in a session, and your settings. If you turn on sync, the machines, host keys, certificate pins and vault also reach your other phones, sealed (see Sync). The key made in your phone’s hardware (the Android Keystore) is never exported and never synced. Passwords and keys you save are in the vault, encrypted with a key that the Keystore holds; opening the vault needs your fingerprint or screen lock. The vault stays on the phone, apart from the sealed copy sync makes if you turn it on, and a KVM login you agree to send to your relay (above), which is taken from it one password at a time. The app asks Android to check it and gets a yes or no: it never receives a fingerprint. The relays you paired (each relay’s id, public key, host name and addresses, this phone’s id on it, the account number it was told, the place it serves, and for each KVM login sent which vault item it was, its time and the KVM’s kind, address and user, never the password or the sealed text) are kept on the phone too, are never synced and are left out of backups. A picture a relay sends is held in memory only. Uninstalling the app removes all of it, as it does for any app’s private storage.

Notifications

The app posts notifications on the phone itself, from what it reads from your machines or from your relay: Claude Code is waiting for you, or a connection stopped. They are not sent through any service (there is no push service). On the lock screen the notice that Claude is waiting shows the machine’s name and a generic text, never what Claude asks.

Our service

The app talks to one service of ours, consolet-app.gpm.name, run by the author. It serves sign-in, the licence check, closing an account, the report and messages screens, sync and the way through to your relay. The licence check asks the family’s apps-management.gpm.name, also run by the author, whether the address you signed in with holds a licence. Reports, votes on feature requests and messages are passed on to it. Mail with a sign-in code or a notice is sent through a mail delivery service (Mailjet). Requests reach our service through Cloudflare, which carries the traffic as any web proxy does.

Writing in, and signing in

The Info tab has a report screen (something is wrong, or you have an idea) and a messages screen where you can read what was written back. Both are optional and neither runs on its own: nothing is sent until you write something and press send.

What a report carries

What you wrote: whether it is a bug or an idea, the title and the description.
What makes it fixable: the app’s version, your Android version, the phone’s manufacturer and model, and your language tag.
A screenshot, only if you pick one. Nothing is captured for you; what you see before sending is exactly what leaves the phone.
Your email address, only if you type one. Without it a report is anonymous and cannot be answered; with it, it is how you get a reply.
A random identifier for that single report, so that sending twice on a bad connection is not counted as two. It is not a device id and a second report gets a different one.
The IP address it was sent from. It is stored with the report, and only the moderator sees it.
A fingerprint of your device, made from its Android ID (Settings.Secure.ANDROID_ID), which the app reads without any permission. Android gives every app its own value, so two apps by Gabriele Proietti Mattia see different ones, and a factory reset changes it. The service keeps only a keyed one-way hash of it, never the value itself, and never shows it to anyone. It exists to keep abuse out: someone who sends obscene reports can be banned by device, by IP address (30 days) and, if they had proved it, by address.

All of it goes to the author’s own service. The app sends it to consolet-app.gpm.name, which passes it on to apps-management.gpm.name, the family service that receives reports, also run by the author. It is not shared with anyone, not used to build a profile and not published: reports are read, given a state and answered by hand.

A report never carries the advertising id, or an install id of our own.

Signing in, and the key that costs

A report is answered by email, to the address you typed into it. If you want to read the answers inside the app, or to use sync, it has to be sure it is you. There are two ways to prove an address:

an address and a six-digit code, sent to that address, in every build;
Google, in the Play build only, if the phone has a Google account on it. The app asks Google for your email address and nothing else: no access to your files, contacts or anything in your Google account. Google tells the app which address you picked; the app sends the proof to our service and keeps no other part of it.

Once the address is proved the app keeps a key. It is the one thing here that resembles a login, so it is worth being exact about it:

it hangs from the address you proved, never from your phone: nothing about the device goes into it, and removing the app throws the key away rather than recovering it;
it works for consolet only, and opens nothing in any other app;
the service stores a one-way hash of it, not the key itself;
it stops working after a year without use, and Sign out withdraws it at the service and not only on your phone.

A licence reaches the app through the same sign-in. If the author grants you a licence, it is granted to a proved address, and the app asks the service whether the address you signed in with holds one. A licence is what makes sync available. Nothing is asked where nobody has signed in.

Sending a report needs none of this. You can report something having proved nothing, and that report carries no key or login, only the IP address and the device fingerprint described above.

Sync

Sync is off until you turn it on, it needs an account and a Pro licence, and it keeps the same machines, host keys, KVM certificate pins, agents list and vault on every phone you add. It is end-to-end encrypted: the phone seals everything with keys that exist only on your phones, and the server stores the sealed result.

What is sent. Sealed items (one for each machine, host key, certificate pin, vault entry and the agents list), and the vault’s keys wrapped by your passphrase and by your recovery code. Alongside them the server sees: your address; for each phone, a device name (the phone’s model), its model and the app’s version, and when it was added and last connected; how many items there are, the size of each and when it last changed; and the numbers needed to open the wraps (a salt and the cost settings), not what they protect.
What the server cannot read. It never sees a machine’s name, address, user or MAC, a label, a host key, a password or a key. It never has your passphrase or your recovery code, which never leave your phone, and it holds no key that opens a sealed item. We cannot recover either for you: if you lose both and every phone that syncs, the synced vault cannot be opened by anyone.
What is not synced. The key made in your phone’s hardware, the theme, the rule for locking the vault, the notification and diagnostics switches, the wake log, what the phone saw of a machine, the relays you paired, and sessions.
A new-device notice. When a new phone joins, the service sends an e-mail to the account’s address with that phone’s name, model and the time, so that you notice a phone that is not yours. It has no link in it.
Devices and removing. You can see the phones signed in and remove one. Removing signs the phone out at the server at once. You can also ask it to erase its synced data, which it does only if it can open a proof made on a phone you control, or make a new vault key so that the removed phone can read nothing written afterwards. A removed phone still holds what it already had, which is why the app says to change the passwords that matter.
Pro ending. Nothing is locked. Everything stays readable and exportable, and the phones keep their data. Pushing new changes needs the licence.
Export. The app can export the whole server copy to a file, and read such a file back, with your passphrase or recovery code.

The permissions the app declares

The permissions in the release build of both versions (the Play build and the store-free build) are:

Internet and network state: to reach your machines, your relay and our service, and to tell whether there is a network.
Foreground service (and its special-use type) and notifications: for the service that keeps your SSH connections open and for the notifications above. Refusing the notification leaves the service working.
Biometric, and the older fingerprint permission that comes with it: for the prompt that opens the vault. The app gets a yes or no, never a fingerprint.
Wake lock and start after a reboot: they come with Android’s background scheduler, which the app uses for the sync pass (every six hours with a network, and shortly after a change). Nothing else in the app uses them, and with sync off the job sends nothing.

The Play build also contains Google’s credential component for Google sign-in, which needs no permission. Its Firebase Analytics brings four more, none of which asks you anything: the advertising ID and Android’s two ad services permissions (ACCESS_ADSERVICES_AD_ID, ACCESS_ADSERVICES_ATTRIBUTION), which let Analytics read the identifiers named under Diagnostics, and Google Play’s install referrer, which tells it how the app was found on Play. consolet shows no advertising. The store-free build has none of the four. The app does not ask for your location, contacts, files, camera or microphone.

Diagnostics

The store-free build (F-Droid and the direct download) has no diagnostics at all: it links no Firebase and no Google library, and nothing in it sends crash reports or statistics. If it crashes, nothing is sent: the only way anything about a problem reaches Gabriele Proietti Mattia is the report you write yourself.

The Google Play build carries two of Google’s Firebase services, and both are on when you install the app. Both are switched off in the app’s manifest, so nothing is collected while Android is still starting the app; the app then switches them on to match your settings, which start out saying yes. So collection starts with the first launch, and stops when you turn it off. The first launch asks once, with the two switches and what each sends, and they stay in Settings, Diagnostics afterwards.

Crash reports. If this is on and the app crashes, Firebase Crashlytics receives the stack trace, the device model, the Android version, the app version and an installation identifier Crashlytics generates. The stack trace holds the error’s own text, which can name what the app was doing, such as an address it could not reach. The app adds nothing of its own to a report: no terminal contents, commands, keys or passwords.
Usage statistics. If this is on, Firebase Analytics records which parts of the app are opened (a terminal, a console, a wake, the KVM’s or the Boot SSH’s terminal, the vault, sync), never on which machine, and, as it does in any app, the first opening (with how the app was found on Google Play), sessions and updates. They go with the identifiers it collects by default: an app-instance identifier, the device model, the Android version, a coarse region from the IP address, and the Android Advertising ID, a cross-app identifier Google gives your device. consolet shows no advertising; the identifier comes with Analytics, and the app’s data safety section on Google Play declares it.

Turning a switch off stops that collection from then on, across restarts. What was already sent is held by Google under its own terms (Firebase privacy); turning a switch off does not delete it.

What the app never does

No account that you need to use it, and no sign-up. An email address only if you sign in, to be answered about a report, to read those answers, to use sync or to have a licence found, and never for anything else.
No advertising, and no sale or sharing of data with anyone.
No tracking for advertising, in this app or across others. The Google Play build’s usage statistics (above) carry the Advertising ID because Analytics collects it; nothing here uses it, and the switch turns them off.
No uploading of your machines, hosts, keys, passwords or sessions to us, except sealed, by sync if you turn it on or in the channel to your relay if it passes through our service, in a form we cannot read.

For readers in the EU/EEA and the UK: the reports you choose to send, the address you choose to prove and the sync you choose to turn on rest on your request and consent (and, for sync, on providing the service you asked for); you may ask for them to be deleted at any time. Keeping the IP address and the device fingerprint with a report, and banning those who send obscene ones, rests on a legitimate interest (Article 6(1)(f)): protecting the service and the people who run it. Crash reports and usage statistics in the Google Play build rest on your consent (Article 6(1)(a)), asked at the first launch with both switches shown on and withdrawn by turning a switch off, then or later; withdrawing stops what is collected from then on and does not delete what was already sent.

The way through our service to your relay rests on providing the service you asked for (Article 6(1)(b)) when a phone signed in with Pro uses it. The relay’s link to our server, which keeps that way ready, rests on a legitimate interest (Article 6(1)(f)): letting your phones reach the relay when they are away from home, and a new phone pair with it from there; you object to it by starting the relay with --no-backend. Neither is kept on disk.

The relay’s update check rests on a legitimate interest (Article 6(1)(f)): keeping a program that runs on your network, with access to your machines, free of faults we have fixed. It sends nothing but what any web request carries and the relay’s version and system, and it replaces the program only with one signed by the author. On Linux it happens only if you enable the timer or run the command yourself, and you object to it by disabling the timer; on Windows it is on until you install the service with --no-update, which is how you object to it there.

Retention

A sign-in code lasts 15 minutes, or five wrong tries.
A sign-in key stops working a year after you last use it, and is withdrawn the moment you press Sign out, close the account or are banned.
The sync server copy (items, wraps, the vault record): kept while the licence is active. After it lapses it is kept for 180 days and then deleted. You are mailed at 150 days and again at 170; paying again at any point clears the clock. Turning sync off with “Stop and delete the server copy”, or closing the account, deletes it at once.
The list of devices: a phone that leaves on its own is removed at once; a phone that was removed from the account is kept in the list for 180 days, so it can still be told to erase itself, and then deleted.
An account nobody has used for five months is mailed and deleted a month later, never one that pays. An account that holds a synced vault is governed by the rule for the server copy above, and once that copy is gone it is an ordinary idle account again.
Reports are kept while they are useful: an open one until it is answered, a closed one as the record of a decision. The IP address and the device fingerprint are kept with the report as long as the report is kept.
Ban records (a one-way hash of the address and of the Google subject, and an IP address for 30 days) outlive an account on purpose, until they expire or the owner lifts them.
Crash reports and usage statistics (the Google Play build) are kept by Firebase according to Google’s retention settings for the project, and then deleted or aggregated. They carry no address and are not linked to an account, so closing the account does not reach them.
Your relay keeps a day of history and drops what is older; the rest, the sealed KVM logins included, stays on that machine until a later set of machines from the phone replaces it or you delete the relay’s state directory. The newest picture of a KVM is in memory only. We hold none of it. The old program an update leaves beside the new one, consolet.old, stays until you delete it or the next update replaces it.
The relay’s update check leaves nothing with us: no server of ours receives it. GitLab, which serves our website, keeps what its web servers log under its own terms, not ours.
The way through our service to your relay is held in memory only and ends with the link or the connection it belongs to; nothing of it is written to a disk of ours. The lines it leaves in our service’s log are the ones named under Your relay.
Deleting the app removes the copy on your phone.

Your rights, and deleting your account

Under the GDPR you may request access to, correction of, or deletion of your personal data. You can delete your account in the app (Info tab, Reports and ideas, Account; or Settings, Sync, Account), which deletes your address, your account and keys, the sync server copy and the list of your devices at once; or follow Delete your account, or write to apps@gpm.name from the address you signed in with. By e-mail it is done within 30 days. Your phones keep their own data. You retain the right to lodge a complaint with a supervisory authority.

Children

consolet is not directed at children under 13 and knowingly collects no data from them.

Changes

Material changes will be published on this page with a new date, and significant ones will be noted in the app’s changelog.

Last updated: 2026-11-05