Skip to main content

Use the reviewed communication contract

Driver communication spans order-conversation lists, order chat, read receipts, text/media writes, sockets, notifications, clipboard, phone/SMS/email, and map handoffs. These are separate contracts. Visibility or local state must never be used as delivery, authorization, receipt, provider, or completion proof.

Current public support is viewing-oriented and source-api-only. Message/media writes and read-receipt completion remain excluded until server authorization and negative tests are accepted.

Availability

CapabilityCurrent public boundary
Conversation listAuthenticated Driver order reads plus local pagination/sort/socket presentation
Order chat viewAuthenticated order-participation read and audience-filtered presentation
Read receiptsState-changing intent can begin when chat opens or closes; completion/scope claims are blocked
Text sendVisible client control exists; public send procedure is excluded
Image/signature sendShares the blocked message-write path; upload/storage/delivery claims are excluded
Document sendSource definition exists but productive UI/payload wiring is absent
Sockets/pushTransport intent only; no durability, security, ordering, or delivery receipt
Phone/SMS/email/map contactExternal OS/provider handoff; no universal support route or provider outcome

Prerequisites

For any viewing implementation or documentation:

  • Use an authenticated Driver account and an order the Driver is authorized to handle.
  • Treat order/message/participant data as private and purpose-limited.
  • Separate initial order read, message-list read, local filtering, socket append, read intent, and provider render.
  • Do not enable send, media, receipt, contact, or external-app actions in a documentation runtime.
  • Keep deployed behavior and provider success excluded while source/deployment authority remains unresolved.

Responsibility boundaries

OwnerResponsibility
Driver App UILoading, list, header, bubbles, audience presentation, composer state, local errors and handoffs
Client controllersAuthenticated reads, local state, read intent, write intent, socket listeners, and immediate preview cleanup
API read contractAuthorize order participation and filter visible messages for the current role
API write contractAuthorize before any upload/write, validate content/audience, persist atomically or return a safe receipt
Read-receipt contractAuthorize order participation and per-message visibility before mutation
Socket/push providersTransport events; never define authorization or durable completion
OS/contact/map providersOwn external app support, privacy, user confirmation, and outcome
Product/security ownerResolve blocked authorization and receipt findings before public write procedures

Inputs and result

Viewing

Inputs are an authorized order context, authenticated session, returned message rows, audience metadata, and local configuration. Safe outputs are loading, empty, populated, error, historical, or locally appended presentation states.

An image bubble, sender label, audience avatar, unread badge, or socket append is not an authorization or delivery receipt.

Writes and media

Text and image/signature controls can construct a message intent. Media-write authorization and rollback remain under security review, and media/message/ socket/notification effects can settle separately. Public send/media procedures are therefore blocked.

Document-picker state is not transmitted by the accepted client. Do not claim document attachment support.

Read receipts

Opening chat can trigger a state-changing read intent. Receipt-scope and visibility authorization remain under security review. Local unread zero, Back navigation, or returned rows are not read completion.

Sockets and contact

Socket room joins/events are freshness hints, not auth or durability. External phone, SMS, email, clipboard, and map actions transfer data/control to the OS or provider. They are not support tickets, delivery receipts, or safe retries.

Security and privacy

  • Enforce authorization before upload, message persistence, or receipt writes.
  • Use purpose-minimal message fields and audience; never trust client audience selection as server authorization.
  • Do not log tokens, raw message/media, contact values, order IDs, coordinates, socket room names, or provider payloads in public evidence.
  • Reject remote media schemes and external contact/provider actions in capture fixtures.
  • Treat signature/media as sensitive content, not proof of identity, consent, pickup, delivery, or PIN validation.
  • Keep the exact security findings and exploit details private; public docs state only the blocked responsibility and objective re-entry requirement.

Limits and failure states

StateRequired interpretation
Conversation visibleRead presentation only
Empty chatNo visible row passed current read/filter; not “no records”
Socket eventLocal append/update intent; not durable delivery
Unread count changesLocal/returned aggregate; not receipt completion
Send-looking bubbleLocal/response presentation; not authorized persistence
Preview disappearsClient cleared state; not upload success
Media fails to renderProvider/source/access unresolved; do not open externally
Contact/map app opensExternal handoff only
Error after write intentEarlier upload/write effects may still exist; do not retry blindly

Writes, media and receipts remain blocked until authorization is enforced before effects, negative tests cover cross-order/cross-audience access, partial failures have cleanup/receipts, and independent security review accepts the contract.

Troubleshooting

A team wants to document sending

Keep the article viewing-only. The current write authorization finding blocks a public send procedure, even when a happy-path test or visible bubble exists.

Unread state differs between list and chat

Do not reconcile by opening/closing repeatedly. Reads, local zeroing, receipt mutation, socket events, and refreshed order state settle separately.

An attachment appears selectable

Preview is local state. Image/signature send shares the blocked write contract; document transmission is unwired. Do not claim upload or delivery.

A socket event appears to prove delivery

Sockets are transport hints. Require server authorization and durable receipts; do not use arrival order or one client view as completion.

Treat it as an external handoff. Do not infer provider availability, support ownership, identity, consent, or outcome.

Related guides: Run governed evidence safely · Driver App architecture · View order conversations · Use order chat · Add and view chat media