Lists out differences between protocols

(request from @krishna0209)

Feature Request

As we start planning to support different protocols, we should consider their differences and how Web Chat could adapt:

• File upload
  • We only support uploading a single file at a time
  • We don't support text message piggybacked to the file upload activity
  • Since Direct Line do not report attachment sizes, we use channel data to keep attachment sizes. This is an optional feature
  • Some services may support asynchorous file scanning for uploaded files, so the UI can block download before the scanning complete
• Server timestamp
  • All outgoing activities are server-timestamped, so we can maintain a correct order of transcript
• Outgoing activities acknowledgements
  • All outgoing activities are ACK after they are received/being processed by the bot. This is equivalent "read receipt" (email) or "double blue ticks" (WhatsApp)
• Channel data (per-activity in-band storage)
  • We keep a client activity ID in channel data for "read receipt"
• Heartbeat
  • User idle or typing indicator
  • Browser is active
• Notification of app switching
  • Connection is frozen, no incoming or outgoing is expected
  • Connection is killed and should reconnect on next opportunity
  • Push notification for frozen connection
• Queueing up of messages that failed to send
  • Is the protocol queuing up the failed messages?
  • How to retry? Is it by resending the whole activity?
• Connectivity
  • Is the connection already established before sending to Web Chat?
  • Who is responsible to call the connect() function
• Retry
  • On retry, should the protocol send a new bubble or just retrying the existing one?
    • Retrying existing one: the UI can color the bubble when they are successfully sent
• User ID and conversation ID
  • Today, some parts of Web Chat requires knowledge of user ID
  • Can we remove that part from Web Chat?
• Adapter should have a way to send extra information to customization component of Web Chat
  • For example, sending a customized avatar image from adapter to Web Chat
• Update activity
  • Activity with same ID will be replaced, including timestamp
  • Timestamp change will affect the order of message and is by design
• Acknowledging activities
  • Currently, the acknowledgement is used for pausing scroll, e.g. the developer set "pause scroll after 3 activities"
  • If the protocol supports conversation history, we might want to tell the adapter we have acknowledged up to which activities

Added from #2506:

• Disconnects (online/offline)
• Update/Edit messages

[Enhancement]

The issue does not name files, tests, or an entry point; start by reviewing the existing protocol and adapter support against the listed differences. Done would require an agreed, actionable scope for how Web Chat should handle these protocol behaviors, rather than only a comparison list.