Basic collaborative chat

[dlqqq]

Description

Enables collaborative chat by migrating to the new Chat WebSockets API implemented in #40.

Correctly handles selection inclusion + replacement. 😁

Demo (collaborative: false)

Screen.Recording.2023-04-12.at.4.06.00.PM.mov

Demo (collaborative: true)

Screen.Recording.2023-04-12.at.4.18.50.PM.mov

Backend changes

• Each client is now identified with a unique UUID
• Each message is also now identified with a unique UUID
• Server message types are now declared via pydantic. There are currently 3:
  • ConnectionMessage: sent after a WebSocket connection is opened, providing the client with their client ID
  • HumanChatMessage: broadcast by server after receiving a ChatRequest. this is now broadcast to all clients, so that the sending client can also verify that the server received the message.
  • AgentChatMessage: broadcast by server after agent responds to a HumanChatMessage. The reply_to field stores the message ID of the HumanChatMessage it is replying to

Frontend changes

• The ChatHandler class has a new interface:
  • async initialize(): must be awaited prior to usage
  • async send(): send a message and return a Promise. The Promise resolves when server acknowledges receipt by broadcasting the message back.
  • async replyFor(messageId: string): return a Promise that resolves when an agent replies to a message with ID messageId

In summary, this adds an awaitable fetch-like API for sending chats and waiting for agent replies. This is extremely powerful, and allowed me to implement this while making minimal changes to the Chat components 😁

Next steps

• Handle client disconnects
• User avatars

[3coins]

@dlqqq
Thanks for making these changes. The request/reply design looks great, left some comments about some redundant code.
One consideration to keep in mind is that the initial version relied on hydrating the chat history from the conversation memory. With the new changes, this is no longer the case, so for instance, if we decide to use persistent memory it will not align with the chat history in the UI as these two are handled separately now. Let me know if I missed anything, and that's not the case.

[dlqqq]

@3coins

The request/reply design looks great, left some comments about some redundant code.
One consideration to keep in mind is that the initial version relied on hydrating the chat history from the conversation memory. With the new changes, this is no longer the case, so for instance, if we decide to use persistent memory it will not align with the chat history in the UI as these two are handled separately now.

Yes, this is technically an instance of duplicate state. However, I would think of settings["chat_messages"] to be more like a "cache" of the agent's memory; it would be expensive to serialize the agent's memory to a list of ChatMessage objects if we did that dynamically every request. This cache is fairly straightforward to keep consistent in the serial execution model (i.e. prompts get executed in-order one-by-one). All you need to do is make sure that list gets appended to every time the agent executes.

When you parallelize model execution, you may run into issues with this strategy regarding process safety; feel free to change it as much as you'd like.

[3coins]

@dlqqq
The changes look good, let's continue to the history discussion offline and merge these changes.