feat: copying or forking chat conversations

[Arcitec]

Is your feature request related to a problem? Please describe.
Sometimes Very often, I want to try different directions, without messing up the main "workbook". Currently, I cannot find any way in Open WebUI to copy or fork a conversation.

If it was possible to fork things, it would mean that we can finally try out different ideas, while having a totally separate branch for those tests, which we can refer back to anytime to manually copy interesting aspects into the main workbook.

We can then delete those branches/copies when they are no longer needed.

I've seen other Ollama frontends with the "duplicate conversation" feature, so there's clearly some interest in the feature.

Describe the solution you'd like

1. The hamburger "..." menu for a conversation could have a "Make a copy" menu item.
2. Individual messages (both prompts and responses) could also have a "Make a copy at this location", to make a copy which doesn't include anything after that message.

Describe alternatives you've considered
I've considered using the existing ability to delete parts of a conversation, and to try things in the main workbook, but here are the issues with that:

1. Having to delete everything to go back to a prior, "serious" state, means that you lose the ability to continue the separate experiment.
2. You lose all of the history/text from the experiment, and have to manually copy them to some other storage location (such as a text file).
3. I know that it's possible to edit prompts to create a new "internal branch" inside a workbook, which you can switch back and forth between, but this has the issue that it becomes increasingly difficult to find the message where the branch happened, especially if there's multiple branches.

It would just be so much easier to work with the LLM if we could copy a conversation, run experiments, and then delete the temporary copy.

Additional context
Matt Williams had a great video showcasing this exact feature in another frontend UI:

https://youtu.be/cdAb5CigAgQ?t=179

[Arcitec]

@tjbck I sincerely appreciate that you decided to consider this idea.

Something else just hit me. Even if there's no GUI whatsoever for it, it would be a good idea to remember the relationship between branched conversations, by having a table with the following fields:

• source_id: The original conversation's ID.
• source_message_id: The exact message ID that started the branch. (The final/last message's ID, if not branched from a specific message.)
• target_id: The new branched conversation's ID.
• target_message_id: Just the message ID of the last message in the copied branch, meaning "this is where the branch was created".

Then, whenever a branch is created, record these entries.

Whenever any conversation is deleted, delete all entries from that table where either source_id or target_id is equal to the deleted conversation.

Having this recorded historically, even if there's no GUI to see the information, would be very useful for a few reasons:

1. It's then possible to say "if conversation_id exists in target_id column of link_table", it means that it was a branch, and makes it possible to mark the conversation with a special "this is a branch" icon. That's an example of a trivial GUI change that would immediately make it clear which one is the original and which is the branch.
2. It would also be possible to have two links at the top of the branched conversation, which can take the user directly to the position where the branch diverges from the original conversation, and another link which goes to the exact conversation (or exact message) which created the branch. (And yes, the user could decide to delete or re-generate messages from the branch or source, breaking those direct message links, but that's solvable by not attempting to directly link to deleted/re-generated messages anymore.)
3. It makes it possible to have a GUI that can show the hierarchy of branches under a specific conversation, by checking "if conversation_id exists in source_id column of link_table" to know that branches have been created, and then recursively querying each of those branched IDs to generate a tree of all children, and displaying it to the user.

None of that would be interesting at all to an initial "minimum viable product", but would be invaluable to anyone who wants to make visualizations or branch management tools in the future.

So recording that branch relationship information in a secret database table for now would be a good move. :)

[tjbck]

Added to dev, let me know if you encounter any issues!

As for the visualisation feature request, that would be a great addition indeed. It would be deemed as low priority but feel free to open up a separate issue post, PR welcome as always!