Limits, stated openly
This page is deliberately uncomfortable. It gathers in one place what TalX cannot do, does not do, or where it falls behind the market standard. Anyone who still wants it after reading knows what they are getting into.
The most important thing first
Section titled “The most important thing first”Maturity
Section titled “Maturity”- A young codebase. The internal audits of recent versions have turned up real faults – fixed and regression-tested, but a level of maturity like a messenger that has run at scale for years takes years in the field, not months.
- Development state 0.x. Version 1.0 has deliberately not been assigned yet.
- A small user base. Every contact has to install the app and be deliberately paired once. There is no directory and no network effect.
Platform
Section titled “Platform”- Android only, version 8 and newer. No iOS, no desktop, no web. TalX does not reach mixed circles of friends.
- 64-bit devices only (arm64). Pure 32-bit devices are excluded.
- Google Play Services required for short-range delivery – the Bluetooth and Wi-Fi Direct connections run through a Google component.
Verifiability
Section titled “Verifiability”- No reproducible builds. You cannot independently verify that the shipped app was built from exactly this source code.
Metadata
Section titled “Metadata”- The relay operator sees who communicates with whom, and when. Not the content – but the pattern. Anyone who wants to rule that out runs the relay themselves or uses TalX purely offline.
- Sealed sender is missing. Since protocol version 13 the sender marker in the chunk hides who is writing – but only from third parties. The operator of the brokering ties every delivery to the registered connection; a social graph can be built from that. Even anonymous delivery would only change half of it, because the IP address remains.
- The ratchet header is not additionally encrypted.
- On a local network, presence is visible. Anyone on the same Wi-Fi sees which TalX identifiers are present.
A single central point
Section titled “A single central point”- Push and store-and-forward run through a single piece of brokering operated by the project. It is self-hostable, but it is not a worldwide server fleet. If it fails, the serverless paths keep working – delivery to contacts who happen to be offline over the internet does not.
- That sits at the top of the roadmap.
Feature gaps against the market standard
Section titled “Feature gaps against the market standard”- No disappearing messages with a timer.
- No very large groups – every message is encrypted separately per member.
- No group calls.
- Attachments up to 100 MB one-to-one, 50 MB in groups.
- No status stories, channels, communities, sticker ecosystems or bots. That is a deliberate decision, but it remains a gap.
Operation
Section titled “Operation”- Some manufacturers’ aggressive battery optimisation can kill the background service. Without it, messages only arrive the next time the app is opened.
- No automatic start after a device reboot – not permitted for this kind of service from Android 15 onwards. The service starts when the app is first opened.
- Restoring from backup is only partly demonstrated. The backup and read paths are tested and measured; a complete run with a cloud download and a second factor on a device is still outstanding.
Limits of the technology itself
Section titled “Limits of the technology itself”- “View once” is an agreement, not a guarantee. Anyone allowed to read a message can photograph it.
- Blocking is not invisibility. A blocked person still receives delivery confirmations and presence signals – deliberately, so that the block does not announce itself. Anyone who gets no answer for long enough can still work it out.
- A name filter never catches everything. It deliberately runs on receipt as well, so that nobody can bypass it with a modified app – complete it is not.
- On a rooted device with active malware no app helps. That applies to every messenger.
- The wrapping key is not bound to a user unlock – a prerequisite for background reception. With physical access to an unlockable device the bar is lower; mitigated by the app lock.
- 5G Sidelink is prepared but unusable – Android gives ordinary apps no access to this radio technology.
When TalX is the better choice – and when it is not
Section titled “When TalX is the better choice – and when it is not”| Use | Recommendation |
|---|---|
| Highest confidentiality, highly sensitive | Signal – independently audited, mature, metadata-frugal |
| Communication without internet or without a phone number | TalX – works offline, no account |
| Home or office on the same Wi-Fi, calls included | TalX – no server at all, delivery in seconds |
| Transcribing voice messages without giving content away | TalX – runs on the device |
| Maximum everyday reachability | WhatsApp – network effect, at the cost of Meta metadata |
| Data sovereignty, self-hosting, tinkering | TalX – full control, but still without an external audit |
| A mixed device world with iOS or desktop | Signal or WhatsApp – TalX is Android-only |
| Very large groups, very large files | WhatsApp – TalX is deliberately limited here |