Whispr v1.1.9 — Chat messages flow cross-network

Bug fix

Chat messages now flow between contacts added via invite link.

The previous bug: email worked across networks (ECIES — one-shot
encryption with just the public key), but chat messages stayed
queued forever. The root cause was missing data in the invite
link: chat uses X3DH for first-message session establishment,
which requires the recipient's signed pre-key (SPK). The QR code
flow already includes spk + sig. Invite links didn't.

Without SPK, X3DH can't initialise → the encrypt step fails →
message never leaves the device. (You can confirm in logs:
[Chat] E2EE encrypt failed (...) — message will stay queued.)

What changed

The invite link now carries two additional query params:

• sk=<hex> — signed pre-key public key
• ss=<hex> — Ed25519 signature over the SPK

The receiver app reads these, persists them with the contact via
the existing _insertContact path, and the X3DH session
establishes normally on the first chat send. Messages now deliver
across LAN, Tor, and BLE mesh — same routes as email.

Also: if the sender's app doesn't have an SPK bundle yet (older
install that never produced one), _buildInviteLink now generates
one before building the URL. Ensures every freshly-shared invite
is fully usable.

End-to-end test (cross-network)

Two devices on different networks:

1. A → Share invite link → send to B
2. B taps link → banner → Add
3. A's chat list → pending request from B → Accept
4. Either side types a chat message → delivered via Tor
5. Same as before across LAN

Email and chat should now have parity for cross-network delivery.

URL length

The link grew by ~190 characters (sk + ss). Total URL is ~440
chars — still well within SMS multi-part, iMessage, WhatsApp,
email body limits. No real-world impact.

Verification

• Architecture: arm64-v8a
• Signed: release keystore (CN=Whispr)

SHA-256: c824f29fb4864b19467d02c014b2521d926e9a6dbc3124954cc1d10b4d48afec