feat: enhance chat import with multi-format support

[sidbetatester]

This PR enhances the chat import functionality, continuing the work from #280 and #871. Care has has been taken to follow the latest structure.

Changes:

• Added Import Chats button to Data Management tab in the Settings (removed my original implementation in the sidemenu to avoid duplicate places to perform the task, we can bring it back if necessary)
• Added support for multiple chat import formats in both the main page import for single chat import as well as all chat import in the settings, following the existing method of implementation in the main window.
• Added proper error handling and logging
• Updated README

Note: This addresses feedback from previous PRs:

1. Fixed TypeScript issues
2. Improved error handling
3. Added proper success messages
4. Moved import button to Data Management tab per @wonderwhy-er's suggestion

References:

• feat: Add chat history backup and restore functionality" #280 (original PR)
• feat: add chat history backup and restore functionality #871 (continuation PR)
  Overall History:
  feat: Add chat history backup and restore functionality" #280 Added chat history backup and restore functionality in the side bar, however the there was a structural change to bolt.diy, hand multiple conflicts with new structure.
  feat: add chat history backup and restore functionality #871 tried to add the feature back but some of the functionality was moved and based on feedback, needed more work.

This PR: Addressed previous feedback, merged using feature branch avoiding the issues caused in the previous PR by merging the main branch.

Import Multiple Chats in the Settings Window:

Import Single Chat In Main Window:

My original Method of implementation in the Side Menu removed for now since we will already have this inside the settings:

[sidbetatester]

@wonderwhy-er

thank you for checking my other PR, #871
I closed that to avoid the merge confusion and created this one. hopefully I followed the process correctly this time!

Please review and let me know if we need any further changes.

[wonderwhy-er]

Hm, what is chrome extension format?
And I am not sure why we have multiple formats at all.

[wonderwhy-er]

What also is interesting, it seems to overwrite existing chats if id matches, but leaves older in place

If I made changes to chats after export and then imported than changes are lost.
May be we should ask user if he want's to overwrite in such scenario?

I am fine with merging this though and making such a change as separate PR.

I mean its usually bad if users by accident looses his work.
On other hand its a mess if on imports we create copies of chats.

Thinking of how this usually is solved form UX standpoint this reminds of copy pasting files when user is asked "replace, cancel, or make copies of duplicate items"

[sidbetatester]

Hm, what is chrome extension format? And I am not sure why we have multiple formats at all.

I included multiple formats for the backward compatibility.

I was initially using the indexeddb-exporter chrome extension for exporting the database since we natively did not have that functionality.
https://chromewebstore.google.com/detail/indexeddb-exporter/kngligbmoipnmljnpphhocajldjplgcj

Also, I noticed the previous implementation seems to have a slightly different exported format than the current one, so the multiple format support helps bring these in just in case someone was switching from an older version to the latest version, not a big deal but nice to have.

[sidbetatester]

What also is interesting, it seems to overwrite existing chats if id matches, but leaves older in place

If I made changes to chats after export and then imported than changes are lost. May be we should ask user if he want's to overwrite in such scenario?

I am fine with merging this though and making such a change as separate PR.

I mean its usually bad if users by accident loses his work. On other hand its a mess if on imports we create copies of chats.

Thinking of how this usually is solved form UX standpoint this reminds of copy pasting files when user is asked "replace, cancel, or make copies of duplicate items"

@wonderwhy-er

Nice Observations!
While I understand your suggestions, I would love to work on these as a next update but the more straight forward way is really to suggest users to always back up current version before applying a restore. That way they are always having a version they need. I would love to have a method to choose which chats to restore but that's a lot more work and I really think we will solve that using version control rather than the backup feature, which I have some ideas about and tried implementing in the past but its a completely different feature.

Initially I introduced these features since I was using them quite a bit and I think we are already giving users the opportunity to individually duplicate chats, restore to older stages, restore single chats and all chats.

My request and suggestion is to go ahead with the current implementation and use new PRs to enhance based on feedback.

Please let me know if you agree or have further suggestions.

[wonderwhy-er]

Hm, about formats. It does mean that you add support for import format that only you used and no one else?
I mean indexdb export style was never merged so only you could use it?
I think it should not be merged than.
Just convert your older exports to current format.

I mean we will be merging code we will never be able to remove(as no one knows who needs it) but only you will ever use it?

[sidbetatester]

Hm, about formats. It does mean that you add support for import format that only you used and no one else? I mean indexdb export style was never merged so only you could use it? I think it should not be merged than. Just convert your older exports to current format.

I mean we will be merging code we will never be able to remove(as no one knows who needs it) but only you will ever use it?

I do not know anyone else that used these chromedb extensions (they do have 1000s of users) that can backup browser databases, but there could be people who faced this in the past just like I did and tried different other methods.

I can relate to why you are skeptical about including the support for other formats, I already worked on that solution so I included it just like I initially posted the complete backup feature, and it is very straightforward code, it should not slow down the system, rather providing the error handling in case users have used other methods to back up chats.

I guess we have the following choices:

1. Keep it for now since we already have this ability, and remove it eventually in future releases if its not being used at all (code is well-isolated, maintainable, follows existing patterns; usage could be tracked may be via a forum poll)

2. Get rid of it now (users needing this functionality can use my fork, and I can maintain my local version for personal use)

I am happy to take either direction, please let me know.

[wonderwhy-er]

@sidbetatester
Well for 1 I would then ask "what are criteria of when to remove"
I would go with 2.

[sidbetatester]

@sidbetatester Well for 1 I would then ask "what are criteria of when to remove" I would go with 2.

@wonderwhy-er
Sounds good! I removed the alternate format support and kept the code focused on the current format.

Changes Made Based on Review Feedback

Simplified the chat import functionality by removing multi-format support:

In DataTab.tsx:

• Removed Chrome extension and other format support
• Kept only two essential formats:
  1. Standard Bolt format (single chat)
  2. Bolt export format (multiple chats)
• Added proper TypeScript types for processChatData

In ImportButtons.tsx:

• Simplified import logic to handle standard format only
• Improved error handling and messages

this PR is pointing to the following branch with the updated files:
https://github.com/sidbetatester/bolt.new-any-llm/tree/feat/chat-history-v2

and the multi-format version is backed up to the following branch for reference:
https://github.com/sidbetatester/bolt.new-any-llm/tree/chat-history-with-multi-format