The close button functionality (assuming you refer to the X in the top right of the "WordPress Assistant") could just collapse the container or it could it clear the chat window. It could persist by default but then there could be ways to clear it - settings for closing it on collapse or a clear chat button. How you envision that part of the interface?

Points 1 and 3 are closely related and connected to a wider user meta / session feature to build out like #5 . At first it can probably just clear when they logout (or some other action) or would there be saved chats with an interface to manage those as well?

The close button functionality (assuming you refer to the X in the top right of the "WordPress Assistant") could just collapse the container or it could it clear the chat window. It could persist by default but then there could be ways to clear it - settings for closing it on collapse or a clear chat button. How you envision that part of the interface?

My idea was simply to close the interface. The only reason I haven't implemented it yet is that the react-chatbot-kit framework I use got a bit in the way, so I didn't want to get hung up on that at the time. There's a few crucial pieces to consider there in terms of accessibility too, e.g. automatically bringing the focus back to the button that opens the chatbot.

Points 1 and 3 are closely related and connected to a wider user meta / session feature to build out like #5 . At first it can probably just clear when they logout (or some other action) or would there be saved chats with an interface to manage those as well?

The difference I see in point 1 and 3 is that point 1 is more important to be reliable than point 3. In other words, I'm thinking to implement chat history persistence on the server-side (e.g. relying on user meta) whereas whether the chat window is open is a simple non-destructive UI preference that's easiest managed clientside, via something like localStorage or sessionStorage.

You mention #5, however where I am thinking to treat this differently is that I consider #5 a functionality to build into the underlying AI infrastructure, whereas the whole chatbot is essentially a user-facing feature built on top of that AI infrastructure. So I'd like for managing the chat history persistence to happen as part of that specific feature - since I don't want to mandate how any kind of chat feature another plugin may implement should or should not implement its persistence.

Regarding chat history clearing, I was thinking that it would be persistent beyond sessions, e.g. timestamp based where we would automatically remove messages older than a certain point, let's just say for example 1 week old. But it's worth thinking through the possible options. Maybe it would even be enough to only store these messages client-side for the session? 🤔

Let me know if that makes sense, or any other thoughts you may have.

For now, the history is persisted using a simple solution with sessionStorage, which should be good enough for now.

A proper persistence layer that uses the WordPress database and therefore could persist beyond sessions could be explored in the future.