Conpherence rendering is currently mostly server-side. This creates a lot of bugs and odd behaviors which are likely intractable without client-side rendering.

Sending Messages Should Not Discard Input: When you send a message, we should immediately clear it from the text input. This interaction should be seemless, no matter how quickly you type:

• Type text.
• Press enter to send the message.
• Continue typing text.

Currently, a slow connection discards text you have input. To reproduce this:

• Add a sleep(3) to ConpherenceUpdateController.
• Type text.
• Press enter to send the message.
• Type more text.
• Wait for the sleep(...) to end.

When the response returns, your input is cleared.

Ghosts for In-Flight Messages: When you send a message, a ghost/placeholder element should appear in the chat history, something like this:

+---+
|   | .o( ... )
+---+

This element shows that your message was sent. Currently, there is no UI feedback that you have messages in-flight. To reproduce this, add sleep(3) to ConpherenceUpdateController, then send a message. The UI won't reflect your message for three seconds.

Ghost Recovery: If a message fails to transmit, there should be UI feedback about it and an option to retry. With message ghosts, the easiest approach is to put a "retry" action inline on the ghost element:

+---+
|   | .o( ... )
+---+   /!\ Message failed to send! [ Retry ]

Currently, the message is lost forever and can not be recovered.

Degrade Network in Developer Mode: Possibly useful is to put a ~3 second delay on everything and a ~25% transmission fail rate when phabricator.developer-mode is enabled, and generally apply dramatic degradation to the "network"? Conpherence currently deals with these situations very poorly, and part of this is because local networks are reliable. We could add options to enable/disable these behaviors but they should probably be on by default, at least.

Consistent Rendering: Client and server rendering is currently inconsistent because of these rules, described in T3597:

• Adding date separators.
• Merging multiple consecutive messages by the same author.

Either a significantly greater amount of UI composition should occur on the client, or the server should re-render much more aggressively.

Race Conditions?: I'm not entirely sure what T8008 is describing, and the thing it links to sounds like something else, but we probably race destructively while performing two or more of these actions simultaneously in some cases:

• Click "Load Older Messages" to load new messages at the top.
• Send a new message.
• Passively receive new messages through the real-time channel.
• After T11644, edit a message.
• After T12566, passively refresh after a reconnect.

View state should be managed and updates should be serialized.