Delivery & background operation

The order

TalX tries the paths in this order and takes the first one that carries:

1. Nearby – Bluetooth and Wi-Fi Direct, with no network at all
2. Local network – discovery via mDNS, direct TCP connection
3. WebRTC – a direct connection over the internet
4. Relay – store-and-forward fallback

Which path it turned out to be is shown later as a small symbol on the message. There is a detailed explanation with a diagram under architecture.

When nobody is reachable

The relay accepts messages even when the recipient is offline: it stores the ciphertext for up to seven days and delivers it on the next connection.

Previously messages sat waiting until both devices happened to be online at the same time – the main reason TalX was unusable for everyday communication for a long while.

The relay only ever sees ciphertext. It can neither read nor alter anything. What it does see anyway is stated openly on the limits page.

Push wake-up

If a device is offline and the app is closed, a push signal can wake it. The signal contains no content – it is only a wake-up call. The app then fetches the message itself, encrypted.

Without push everything works as before, just without the wake-up. On devices whose manufacturers kill background services aggressively, that can mean delayed reception.

The “offline connections” switch

In the profile, on by default. It decides whether TalX may reach nearby devices directly – Bluetooth, local network, Sidelink – or communicates exclusively over the online paths.

Switching it off takes effect immediately: the announcement on the local network ends, standing connections are closed, Bluetooth discovery stops. Switching it on starts everything again without an app restart. The online paths are unaffected either way.

Receiving while the app is closed

A foreground service keeps discovery, reception and delivery alive even when the app is closed. Transport, delivery and database live in a single app-wide instance shared by the interface and the service – so there is exactly one connection and delivery instance, not two competing ones.

The permanent notification is an Android requirement for this kind of service. It shows the connection status and pending deliveries live and has a stop button.

Setting “stay active in the background” (profile, on by default): switching it off stops the service immediately. The stop button in the notification also switches the setting off – otherwise the service would come back unasked on the next app start.

Limits, stated openly

• Some manufacturers’ aggressive battery optimisation can kill the service anyway. That is why the profile has a button leading straight to the system battery list.
• Automatically starting after a device reboot is not permitted for this kind of service from Android 15 onwards. The service therefore starts when the app is first opened after a restart.

Online status

The chat list and chat header show who is reachable right now, and otherwise when they last were – “12 min ago”, “3 h ago”, “yesterday”, and beyond that with a date.

In a peer-to-peer system, “online” concretely means reachable right now: within short range or connected through the relay. For this the app sends a tiny sign of life to its contacts every 45 seconds – but only if a transport is connected at all. If there is no connection, there is naturally no presence information either.

These signs of life deliberately run without a queue and without confirmation, and they do not use the message ratchet – otherwise lost pings would make the key chain drift apart.

5G Sidelink / ProSe

The profile has an entry “5G Sidelink / ProSe (experimental)” marked “not available”. That is not an unfinished feature but an honest display:

TalX is architecturally prepared to use direct device-to-device radio over the PC5 interface. Android provides ordinary apps with no interface for it. This radio technology lives in the modem and additionally requires suitable hardware, clearance from the network and, depending on the mode, licensed spectrum. Only a privileged system or carrier app would have access.

The transport therefore stays inactive and says so, rather than keeping quiet about it. As soon as suitable access exists, it works without any further changes to the app.