Giters

semperai / amica

Amica is an open source interface for interactive communication with 3D characters with voice synthesis and speech recognition.

Home Page:https://heyamica.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

feat: Chat Sessions Managament

snowyu opened this issue · comments

commented
  • List Chat Sessions
  • New Chat Session
  • Use Chat Session
  • Delete Chat Session
  • Import/Export/Share Chat Session
commented

I'll likely work on it as I'm also missing it.

commented

@kasumi-1 but for this I think first it's better to create sorta char selection. Create something like "character" consisting of model, and sys prompt at least. And then session could hoop on that. Regardless, I'll first have to setup sqlite for next.js and see if I'm able to do much. I'm beginner with react and next kinda (had to do some work in it for well work).

commented

From the user's perspective, it is true that conversations are related to characters. Even multi-person/bots conversations should be considered.

To record such conversation, then each item in the conversation should be:

  • userId
  • content
  • toUserId: optional, maybe use @userId in content

about the character, see #32

refs:

commented

@morphles check out the /share and /import pages - these aren't done I have some bug in the backend I need to sort out, but I think this can help as a base and for ui I think its ok start. they're still pretty simple. We need a character selection screen as well.

@snowyu I agree 100%. I think moving to indexedb for this might be needed, as well as ability to export as (json?) for backup.

commented

I'll check it out. But as at work same here, not loving react stuff :( Still for now will try to power through, back-end should be less annoying anyway :) . Will check out agnai, was not aware of that. As for index dunno, I'm extra huge fan of sqlite and not really seeing much index would bring to table compared to it. Well apart from being pure client side, iirc there is some sqlite on index thing.

For proposed DB structure I strongly disagree "toUserId" column. As it makes no sense, in case of 2 user conv, it's mostly obvious (but even then it could something like "muttering to self"), in multi, it is context sensitive/implied (think of all things like sarcasm and what not), and most importantly what's the point of such column? For starters I'd say, just id/msgId, content , author, parentMsgId/prevMsgId; and likely conversationId. Parent cause easy branching is fun :) And with SQLite CTE easy to generate flat thing from a tree. I'm also not sure if author can just be character id, likely. But maybe it should be something like "char+conversation".

commented

After more thinking I'm even less inclined to use indexdb, as even current setup is limiting. I'd like to have access to say system/character definition prompt easily via cli, but now as it's stored in browser only sensible way to get it out is manual copy paste (afaik). While if it's stored server side you can do `sqlite3 db 'query' | anycmd > wherever'

commented

Same for sharing chars on desktop and phone (which is main reason why I even started looking into this :) to be able to chat with bot hands free on my lunch break walk).

commented
  • optional means it could be NULL(for 2 users conv), it usually means private chat in multi-person conversation if exists.
  • "@userId" in the content means mentioning someone in a multi-person conversation.
    • we can treat it as toUserId if only use it in AI Models, so you can remove toUserId.
  • The term "author" here refers to both the AI model (LLM) and the human participant. The "userId" field, in this case, would point to the Character Card associated with the human participant. It's worth noting that a human participant can also be considered a character card.
  • If the "prevId" field is used, it can serve as a reference to the previous message in the conversation. In such cases, the "conversationId" field may not be necessary since the relationship between messages can be inferred from the "prevId" field.
  • Including a "timestamp" field might be useful for tracking the time at which a message is sent. The presence of a "timestamp" field becomes particularly important if there is no "prevId" field available to establish the order of messages.
  • parentId should be optional for reply msg. Or extract it from content if content is in markdown format.

Then use the simplest json object only. No database backend. And could be extends to any db.

commented

Timestamp is very sensible, prev/parent is used no question, it's just auto thing by the order in sequence, or if you fork multiple msgs can be from same parent. toUser makes no sense, unless you want to ask to clarify in some out of band way, and then rely on it (which I will not :) ), worst case you can check few prev messages to gauge possible intended recipient. I just see it as completely pointless anyway. So will won't even be looking at it.

commented

That could be ok. Another words you can safely ignore the optional fileds.

commented

btw there is now way to access share and import from the app (on left hand side, the share and cloud icons).

commented

Cool, will check it out. I'm a bit busy with some other stuff, so could not continue on characters, but should be able to put some time in over weekend.

commented

@kasumi-1 interface is quite a bit prettier! But clicking import can't really go back, as go home basically refreshes things loosing history for me.

commented

@kasumi-1 The share page does not work when running npm run dev as it throws errors. Additionally, the VRM animation cannot be loaded correctly and is being redirected to /share/animations/idle_loop.vrma erroneously.

Unhandled Runtime Error
Error: Text content does not match server-rendered HTML.

See more info here: https://nextjs.org/docs/messages/react-hydration-error

Call Stack
checkForUnmatchedText
node_modules/react-dom/cjs/react-dom.development.js (9647:0)

Unhandled Runtime Error
Error: Hydration failed because the initial UI does not match what was rendered on the server.

See more info here: https://nextjs.org/docs/messages/react-hydration-error

Unhandled Runtime Error
Error: There was an error while hydrating. Because the error happened outside of a Suspense boundary, the entire root will switch to client rendering.
commented

btw, it's time to write a storage backend and refactor the backend code to make it more modular and allow for easy plugin integration in the future.

Currently, there are 3 backend components: chat,tts, stt. Additionally, the UI could be considered as a special fifth backend component too.

IMO, all interfaces in the future are only auxiliary, and all interfaces should be able to be called by talking to the bot.

commented

I was thinking about something like /commands not sure I'd call it exactly talking with bot, but I guess close enough :)

commented

@snowyu I believe the issues were caused due to new step which I didn't document, just fixed.

Copy .env.example to .env.local and you shouldn't get any more error on share page.

commented

@kasumi-1 The animation can be loaded correctly now. but the Error: Text content does not match server-rendered HTML is still here. I 've removed .next directoy.