Connecting contacts

There is no directory in TalX in which you could look somebody up. Contacts come into existence solely because two devices once exchanged their public keys. There are three ways to do that.

QR code

One device shows its code, the other scans it. One direction is enough: the scanner then announces itself back to the scanned device, authenticated, so a contact is created on both devices.

Only the public key is shared. Nothing can be decrypted from it – it exists precisely in order to be public.

NFC

Hold both phones together. The other person only needs their screen unlocked, nothing needs to be tapped. Technically the exchange runs over NDEF; TalX brings its own card-emulation service for it.

By code, remotely

The most interesting route – for the case where you cannot see each other. One side shows a short code, the other enters it together with a shared handle.

Behind it sits J-PAKE (RFC 8236): the short code turns into a strong, mutually authenticated key. Only afterwards does the actual connection record travel – encrypted with exactly that key.

The decisive point: an attacker who controls the brokering gets exactly one guess per attempt. Brute-forcing a recording offline later is impossible by construction. That is precisely why a short code you can read out over the phone is enough here.

The one-time link – receive-only since 0.84.2

Up to version 0.84.1 there was a fourth option under “Connect”: generate an encrypted one-time link and send it over any channel you like. That button has been removed.

What this means exactly:

• TalX no longer creates pairing links.
• TalX still accepts them. A link somebody sent earlier still opens the connection flow.

The reason lies in the nature of the thing: a link carries the pairing material inside it and is therefore only as safe as the channel it travels over. Passing it through a readable chat gives away precisely the protection that QR code, NFC and the J-PAKE code provide. The three remaining routes do not have that problem.

A second channel, always

Say the code over a different route than the one you used for the handle – over the phone, for instance. Sending both in the same chat cancels the protection.

Afterwards: the safety number

All four routes make sure that you have exchanged a key. Whether it was the right one is proven only by the safety number.

Tap the shield symbol in the chat, compare the numbers with the other person over a second channel, and mark them as verified if they match. The contact then carries the note “verified”.

If the number later changes unexpectedly, TalX warns you in the chat. That is usually harmless – the other side reinstalled the app – but it can also be an interception attempt. Compare again in that case.

A second device of your own

Under Profile → Link another device the existing device shows a code that the new one scans. Here too J-PAKE runs first; only then does the identity travel along with the state, encrypted with the negotiated key.

Afterwards both devices are the same identity. Two honest notes on that:

• For linking, the private identity key is exported and transferred. That is the crown jewel. It only happens after a successful J-PAKE, but it does happen. Only ever tell the code to your own device.
• Both devices have to be Android. There is no desktop or web companion.

Blocking someone

Contact info → Block, confirmed in two steps so a slip does no harm. The chat then shows a notice with a way back instead of the input field.

Nothing is accepted from a blocked person any more: no messages, no attachments, no calls – it does not even ring – no profile or presence details. Their content no longer arrives in shared groups either. In the other direction nothing goes out to them, and whatever was still queued is dropped at the moment of blocking. The history stays – blocking is not deleting.

Two things deliberately keep running

This looks contradictory at first, but there is a reason:

• Delivery confirmations still go out. A missing ACK would be a signal: the other side would see their messages permanently stuck on “waiting” and would know. That is exactly what blocking should not do – someone who blocks wants quiet, not an invitation to switch to another channel. Besides, their queue would otherwise keep retrying for days.
• The presence heartbeat stays. Falling silent all at once would be just as telling.

The rule behind it: suppress what stays invisible, keep what would be noticed. Profile updates and anything new in terms of content are no longer delivered – neither of which the other side can detect.

A block survives a re-pairing

Even with a new key. Otherwise it would be worthless: anyone blocked would only have to reinstall and get paired again. A block applies to the person, not the key – unlike verification, the post-quantum secret and the prekey, which are deliberately discarded on a key change.

Unblocking is possible at any time in the same place.

Getting rid of a contact again

A contact can be removed from the device together with the complete chat history. Their memberships and key material in all groups are cleaned up along with it – otherwise a “ghost member” would remain, and every further group delivery would fail against it permanently.