# What WhatsApp has that we do not, cheapest first

*3 September 2026. Response to: "review all the other user flow processes and settings pages for
whats app to see what else we should use as the wa alternative app. only the low cost simple to
implement things first — go for the low fruit before the high fruit."*

Ranked strictly by cost, not by how good the feature is. Anything whose value depends on
convincing somebody to switch is noted, because that is the only reason to close a gap at all —
`STRATEGY-NOTE.md` is explicit that parity is table stakes that buys nothing on its own.

## Already have

Archive · block · delete message · delete conversation · report · per-conversation notification
sound · pairing by QR, by code, and by split code · contact browsing without ingesting · transport
toggles per rung · check cadence · quiet hours · translation offer · relay opt-in.

## Tier 1 — hours, no protocol change, no new permission

These are the ones worth doing now. Every one is local state and a menu item.

| | Why it earns its place |
|---|---|
| **Copy message text** | The single most missed absence in any messenger. One context-menu item. |
| **Mute a conversation** | We already have per-conversation notification settings, so this is one more flag on a path that exists. |
| **Mark as unread** | One bool. People use it as a to-do list, and its absence is noticed immediately. |
| **Pin a conversation** | One bool and a sort key. |
| **Screen lock (Face ID / biometric)** | Highest value-per-hour on this page. A privacy messenger that anyone can read by picking up an unlocked phone is a poor one, and both platforms give this away in an afternoon. |
| **Photos over direct paths only** | Don already asked for this. The setting exists in spirit — `DeliveryPolicy` — and now has something to govern. |

## Tier 2 — a day or two each, still no new protocol

| | Note |
|---|---|
| **Search within a conversation** | Local only. Cheap because we never index anything server-side. |
| **Storage usage screen** | Newly worth having: photos are the first thing here big enough to want managing. |
| **Rename a contact** | Trivial mechanically; wants care so it never touches the pairing identity. |
| **Font size / larger text** | Accessibility, mostly free from the platform. |

## Tier 3 — needs a protocol message, so not "low fruit"

Each of these adds a `PayloadType` and a compatibility story, which is the real cost rather than
the UI.

- **Reactions** — a new payload keyed to a message id.
- **Delete for everyone** — a retraction message, plus the honest caveat that we cannot guarantee
  the other device honours it.
- **Edit a sent message** — same shape.
- **Read receipts** — the payload type already exists and nothing sends it. Should be **off by
  default**: it tells the sender when you read something, which is exactly the kind of timing
  metadata `J57` argues about.
- **Disappearing messages, per conversation** — strongly on-brand, and the one Tier 3 item worth
  jumping the queue for.

## Tier 4 — deliberately not doing

- **Reply / quote and forward.** Not for effort — for `J59`: quoting is precisely the feature that
  turns compression into a CRIME oracle. Doable, but it must land *with* the decision to drop text
  compression, not before it.
- **Typing indicators.** A continuous stream of "this person is at their phone right now" is the
  purest form of the metadata this app exists not to emit.
- **Cloud chat backup.** The conversation store is deliberately excluded from iCloud and Android
  backup. Adding backup would undo the one guarantee everything else rests on.
- **Status / stories, channels, communities, payments.** Different products.
- **Voice and video calls.** Not cheap, and `DECISIONS.md` already routes calling to the phone's
  own dialler per contact.

## The honest framing

Tier 1 exists because their absence makes the app feel unfinished to somebody comparing it with
what they already use — not because any of them is a reason to switch. The reason to switch is the
thing WhatsApp cannot do at all: work with no internet. Spend the cheap hours on Tier 1 so nothing
looks broken, and spend the expensive ones on the radio.

---

## Photo send flow — Don, 3 Sep 2026 (evening testing)

*"image when selected sends immediately - on WA you have to hit send after you select
photo... WA lets you add a caption before you send so maybe better to follow WA here for
consistency. Showing a thin progress bar during photo upload would be a nice touch though and
still show the check when it arrives and the progress bar disappears - could be blue in
progress with a brief green upon arrival or red if it failed."*

### 1. Selecting a photo must not send it

Today the picker's completion sends. That is a **destructive action with no confirmation step**,
and it is the one place in the app where a mis-tap cannot be undone: the bytes are already
sealed and deposited. WhatsApp's flow exists because people pick the wrong photo constantly.

Required: picker → **preview screen** with the image, a caption field, and an explicit Send.
Cancel discards. The caption rides in the same payload rather than as a second message, so a
photo and its caption cannot arrive apart or out of order.

### 2. A thin progress bar under the bubble, colour-coded

| State | Colour | Behaviour |
|---|---|---|
| Sending | blue | **thick enough to read across the room**, advancing by chunks acknowledged |
| Arrived | green | brief flash, then the bar disappears and the existing check remains |
| Failed | red | bar becomes a strip reading **Failed** with two buttons: **Resend** and **Cancel** |

**Cancel removes the image and the bar entirely** -- the bubble disappears as though it
had never been sent, because from the recipient's side it never was. **Resend** restarts
from the first chunk. Neither is a menu item or a long-press: a failed send is the moment a
person is least willing to hunt for a control, so both are buttons, in place, already on
screen.

**Why this is worth more here than in most messengers:** attachments are chunked into 16 KB
pieces (`J58`), a 300 KB photo is ~19 of them, and on Bluetooth that is tens of seconds during
which the app currently shows nothing at all. The bar is not decoration — it is the only signal
that a slow path is working rather than stuck.

Progress must be driven by **chunks acknowledged**, never by a timer: a fake bar that completes
while delivery has stalled is worse than no bar, and this transport stalls often enough to make
that a real risk rather than a hypothetical one.

**Both platforms, same colours, same placement.**