[FEATURE_REQUEST] Better documentation and consistency for JSON chat format
aaronshenhao opened this issue · comments
Have you searched for similar requests?
Yes
Is your feature request related to a problem? If so, please describe.
I am trying to write a script to import chats into SillyTavern. However, the JSON chat format does not seem to be documented anywhere. Furthermore, there appears to be several ways to represent send_date. When I created a new chat then analyzed the chat file, this was the format: "April 26, 2024 6:06am".
Yet when importing in src/endpoints/chat.js, it uses humanizedISO8601DateTime in src/util.js, the and format is different again.
In my save file, each entry has an "is_system": false line, which seems redundant. I've looked at other save files as well (not mine), and some of them have send_date as the Unix Epoch time in milliseconds, or "is_name": true on every entry.
Describe the solution you'd like
The documents should specify the default format to use for chat files. This will make it easier for developers from other platforms to write functionality for importing into SillyTavern.
The inconsistency between the chat formats in different parts of the code base can be improved by having a single factory class for building correctly formatted chat entries. This will help ensure the longevity of backups for non-technical users.
Describe alternatives you've considered
No response
Additional context
No response
Priority
Medium (Would be very useful)
Are you willing to test this on staging/unstable branch if this is implemented?
Yes
The inconsistency between the chat formats in different parts of the code base can be improved by having a single factory class for building correctly formatted chat entries. This will help ensure the longevity of backups for non-technical users.
Not possible. As chats are both crafted and filled on client side and on server side. They don't share the same code base.
I agree on a few points and have also noticed the inconsistencies with send_date. I have that on my todo list to maybe fix some time in the future.
I don't think you'll get a good documentation on the internal workings of ST. Unless you are willing to make one yourself. It takes a lot of time. Which could just be spend working on ST itself.