Context: Follow-up discussion Core weekly sync about communication of message sent/receive status in UI
Objective: Understand UI requirements to accurately inform people of message send/receive status.
We want to make sure people sending a message using Status can rely on that message arriving at its intended recipient; Intended recipient can be anyone in a public, group or 1:1 chat. Next to continuous work on message reliability, we want to accurately inform people of the status of messages sent and received. There are situations where somewhere in between tapping [send] and the recipient [opening a chat], something goes wrong. Below is a list of use cases that may lead to messages not being sent or received. All are by design, a consequence of using Whisper and a network of nodes acting as mailservers in conjunction with efficient use of bandwidth.
Use case 1a
- Connection is dropped for a few seconds or minutes after tapping Send in a 1:1 chat / Public chat / Group chat. The client is still trying to connect while the user has the app open.
- Message does not get ‘sent’ caption
- Client will attempt sending again when connection is back
Proposal: Add caption ‘Sending’, ‘Pending’ or other indicator to show that client is still attempting to send.
NOTE: This was part of the original proposal, but back in April of last year was left for future iteration.
Use case 1b
- Message is sent when client reconnects
- Message gets ‘Sent’ caption
- Recipient sees message appear at bottom of thread. Given the timeframe it is likely, not guaranteed, that the message still makes sense in context.
Use case 2a
- Connection is dropped for a significant amount of time (?) after tapping Send in a 1:1 chat / Public chat / Group chat. Status is no longer trying to connect.
- We cannot guarantee that the message has been sent. It may have been sent, but the client has not received a confirmation. It may not have been sent at all.
- Message gets error note stating [Not sent, tap for options]. This is not accurate. The message might be sent, we simply don’t know if it has been sent or received.
Proposal: Send a ‘soft confirmation’ (@cammellos can you expand on this?)
Proposal: Update error note to indicate that it’s not an error, but rather there is no guarantee that message was sent, to all users. Give user control to send again.
Use case 2b
- Message is sent when user taps ‘Tap to send again’.
- Message is send again; recipient client removes duplicate and shows the message only once
- Recipient sees message appear at bottom of thread
- Message on sender client gets ‘sent’ caption
Proposal: Add caption ‘delayed’ or similar to message both on recipient and sender side to indicate that the message may appear out of context.