agnaistic
add support for tree-based chat
add support for tree-based chat (i.e. allow swiping for each message in the chat). The way it was done in roko's basilisk. In his implementation each message edit generated a new branch. But there was no way to delete a single message or edit it without generating a new branch. Would be great to improve it by giving user the option to edit the message without creating a new branch (the way it works right now) and with creating a new branch at will. Also it would be nice to add to each swipe (branch/message) an optional label (e.g. "this branch ends with bad end z", "this branch takes turn towards y") next to the date.
Yeah, I've been thinking about this as well. It's definitely possible to do. My only concern is that for the public version this would probably quickly consume a fair amount of database storage and result in some more complex querying. These are totally fine to have, but I'd probably need to toggle them off for registered users in agnai.chat, but allow it for guests and self-hosters.
I'll put it in the backlog. I want to do this, but I just need to think carefully about it's implementation. To maintain a valid graph/DAG, I'd need to do the same as the basilisk implementation you're talking about and not be able to delete any messages. Validating changes to the graph would be fairly computationally expensive at scale.
I'd need to do the same as the basilisk implementation you're talking about and not be able to delete any messages
Incidentally, there's virtually no need to delete messages, UX-wise, when you can just create a new branch.
My only concern is that for the public version this would probably quickly consume a fair amount of database storage and result in some more complex querying.
A note about complex querying. I believe Roko simply loaded every message from their database, and linearized the message history in the application code. You shouldn't need to filter messages at the DB query level (You'd still need to change which message is "active" every time a swipe is made.). And there's value in having every tree branches loaded on the client; for example being able to export the full tree.
@sceuick One potential tweak you could apply if database usage is a problem would be to only keep all swipes in memory in the browser, and discard them at the end of a session. Would need to think about how to communicate this to the user. Also, something would have to be done for the DB to stay updated when the user swipes to an existing swipe. Perhaps swiping to an existing swipe should send it to the DB again to update the selected message.
I have a proposition. To avoid the branch-based implementation, there could be a "fork" button instead, that would simply copy the whole chat in a new chat. This would make it simpler to explore branches only when you want to, without any new fancy features. What do you guys think?
To add make it "feel" like branching, we could also add a "Branching" message (when forking, you'd have a "Forked from (CHAT)" link where you did the fork on the forked conversation, and a "Forked to (CHAT)" on the source conversation). This way, you can navigate between forks too.
The idea of having "non-chat messages" will come again, for example "events" (message that says "something happened") or, for multi-user chats, "user lefts the conversation" entries, etc.
