Whispr v1.1.7 — Round-trip invite notifications
What's new
Round-trip notification on invite-link accept. Until now: A
shares an invite link with B, B adds A — and A had no idea. Now the
sender (A) gets a banner the moment the receiver (B) taps Add:
"B accepted your invite — add them back?"
A taps Accept on that banner → both sides have each other in their
contact lists, mirroring the Nearby-tab contact-request flow.
How it works
The invite link now carries one extra query param: o=<sender's onion>. When B taps Add, the app:
- Adds A as a contact locally (existing behaviour)
- Registers A's onion in the Tor message-routing table
- Fires a
contact_requestover Tor to A's onion - A's app receives it and surfaces the existing pending-request
banner in the chat list
What changes for users
| You're | What you'll see |
|---|---|
| Sharing an invite link | The link now includes your onion. Auto-omitted if Tor isn't ready when you generate the link — falls back to the previous one-way flow. |
| Receiving an invite link | Same banner-driven UX as v1.1.5/6. After tapping Add, the sender gets a notification on their device. |
| The original sender (A) | A new pending-contact-request banner appears when B accepts. Tap Accept to add B back. |
Privacy posture
The onion address was already shared via QR codes in the existing
add-contact flow — invite-link-based sharing now matches that
disclosure level. Onions are public addresses by design (not
secrets); they let someone attempt to reach you, but Whispr
rejects messages from non-contacts. Time-limited invite expiry
(1h–24h) caps the window during which the link can be used.
Verification
- Architecture: arm64-v8a
- Signed: release keystore (CN=Whispr)
SHA-256: 54e4679a3b2a0dfb160f3ec5f90271b42879d60bf7a17a446e967474607d6410