Goals & roadmap

Four undertakings lie ahead. They are ordered by impact, not by effort – and none of them has a date, because TalX is a private project with no team behind it. What is written here is an intention, not a commitment.

1 · An independent external audit

Why it comes first: it is the only point TalX cannot solve under its own steam. Every review so far has been internal – thoroughly documented, regression-tested, measured on real hardware. But operational blindness cannot be removed by more of your own diligence. That is exactly what an outside view is for.

The finding is tracked as F-07 with severity high, and the internal report’s recommendation is unambiguous: before any 1.0 or production claim, an audit by a specialised lab.

Intended focus areas:

• the ratchet bootstrap including the serverless prekey rotation,
• the choreography of the password-authenticated key exchange,
• the integration of the post-quantum share into the root key,
• call and media signalling,
• the protocol of the brokering.

What is blocking it: money. An audit of this kind is by far the most expensive item in the project – and the main reason there is a donations page at all.

Until then the sentence stands: TalX has not been audited.

2 · Expanding the server landscape

The problem today: the serverless paths work without any infrastructure – short range, on a local network, directly between two devices. But as soon as a message has to reach a currently offline contact over the internet, it runs through a single piece of brokering operated by the project. It is self-hostable, but it is a single point.

The goal: a cluster instead of a single node.

• Several locations instead of one, so that an outage does not take out all internet delivery.
• Geographical proximity – the node with the shortest round trip wins.
• A shared store-and-forward buffer, so it does not matter which node a device happens to be attached to.
• Federation: a self-hosted node should be able to participate as an equal, not merely be an isolated replacement.

The hard part is not the technology but the metadata. More nodes initially means more places where it becomes visible who communicates with whom. The expansion should therefore come together with an improvement on that front – the sender identifier is visible to the operator today, and the sender marker in the chunk does not change that.

What does not change: a node sees nothing but ciphertext. That is not an operational decision but a property of the protocol.

3 · An iOS version

The biggest everyday gap. TalX is Android-only. In mixed circles of friends that is a deal-breaker – not because the app cannot do something, but because half the people cannot install it.

What will be different on iOS, stated up front:

Building block	On Android today	Expected on iOS
Offline short range	Google Nearby Connections (Bluetooth, Wi-Fi Direct)	has to be rebuilt – the platform offers its own building blocks with different properties
Local network	mDNS and a direct TCP connection	comparably feasible
Reception while the app is closed	foreground service	considerably more tightly regulated; push will play a larger role
Key storage	Android keystore, StrongBox	Secure Enclave – conceptually comparable
Transcription and translation	on-device engines	a replacement is needed

Part of the serverlessness will therefore cost more work on iOS, or look different. That deserves saying before anyone expects a one-to-one port.

A prerequisite is point 4: as long as the cryptography is interwoven with the Android code, an iOS version would mean writing it a second time. Two implementations of the same protocol are two opportunities to get it wrong in different ways.

4 · A modular crypto core of our own

What is meant: the cryptographic core logic – ratchet, prekey bootstrap, post-quantum mixing, sender keys, wire format, key hierarchy – should be lifted out of the app and become a self-contained, platform-independent unit.

What is expressly not meant: ciphers of our own. The ground rule “no home-made cipher code” stays untouched. X25519, AES-GCM, HKDF, HMAC, ML-KEM, Argon2id and J-PAKE continue to come from vetted libraries. What becomes modular is the layer above – the protocol logic that assembles those building blocks.

What that gains:

• One implementation for all platforms. Android and iOS share the same core instead of two variants that drift apart.
• A clearly delimited object of review. An audit that looks at a module with a defined interface is more thorough and cheaper than one that has to pick the core out of an app. Point 4 makes point 1 more affordable.
• Replaceable building blocks. When a method has to be replaced – and one day it will – the change is confined to a module instead of scattered across the app.
• Testability without a device. The more protocol logic can be checked without an Android runtime, the more of it runs in every test pass.

The price: rebuilding the crypto core is the riskiest rebuild this project can undertake. It has to work across the backwards-compatibility promise – at least ten app versions stay able to send and receive to each other. That means no cut-off date, no big-bang switch, but module by module with regression tests against the old path.

Smaller undertakings

From the internal reports, in no particular order:

• Anonymous delivery (“sealed sender”), so the operator of the brokering no longer sees who writes to whom. Honestly: that requires a change on the server, and even afterwards the attribution via IP address would remain – without an additional step in that direction it is only half a win.
• Encrypted ratchet headers.
• Ephemeral service identifiers on the local network, rotating per session instead of permanently showing your own identifier – with identity resolution only after the connection is established.
• Proof of freshness for call and connection signals.
• A separate key bound to user unlock for particularly sensitive parts, without losing background reception.
• A complete demonstration of the restore path with a cloud download and a second factor on a real device.
• Reproducible builds, so that it becomes independently verifiable that the shipped app was built from exactly this source code.

What is not coming

So that this is clear too: no status stories, no channels, no communities, no sticker ecosystem, no bots, no advertising, no analytics. These are not open items but decisions.