room level and thread level context or both

[seshubonam]

trafficstars

https://github.com/matrixgpt/matrix-chatgpt-bot#good-to-know

This popular bot allows the following :

• The bot uses threads by default, to keep the context you should reply to this thread or the bot will think its a new conversation. "Threads" were previously experimental, you may need to activate them in your client's settings (e.g. in Element in the "lab"-section).
• There is support to set the context to work at either the: room level thread level both (threads fork the conversation from the main room)

any possibility to add this feature? would be very useful for practical use cases in a group chat setting. This also solves the problem of context per user query that we discussed few weeks ago.

Thanks

[hibobmaster]

I have been very busy recently and won't have time until next week. I will look into these features at that time.

[seshubonam]

yup sure thanks

[jaodei]

Hi,

seshubonam

May I know what are the benefits of adding this feature? Cheers.

[Dual-0]

May I know what are the benefits of adding this feature? Cheers.

Thread level is based on the functionality of ChatGPT. The bot keeps the context of the chat inside a thread. If you want the bot to refer to a message, reply to it in the thread. If you don't want it to, you can open a new thread. If you don't have this function, the bot will refer to all previously sent messages and treat them as context.

[hibobmaster]

Thread level has "rel_type": "m.thread", it's possible to implement it but It is difficult to maintain and differentiate the relationship between contexts. So for now, let's keep things as they are, with each person's conversation undisturbed, maintaining their own contextual relationships.

It seems unsigned[transaction_id] in thread is equal .

          "unsigned": {
            "age": 2944662618,
            "transaction_id": "m1692237232973.89"
          },

[seshubonam]

yup thats good enough ... very good work on repo so far 👏👏

[mwnu]

yup thats good enough ... very good work on repo so far 👏👏是的，这足够好...到目前为止，回购工作非常好👏👏

I believe that having robots reply within threads (message columns) is a better approach. Firstly, use a command (such as !gpt) followed by a prompt to trigger the robot's response. Then, the robot replies within the thread, where users can converse without needing further commands. The robot will gather context from within the thread. This setup allows for multiple topics to be discussed within a single room, avoiding the clutter of long contexts and mixed topics in the message list.Like this project

[seshubonam]

hi, great thought. we are trying threads on a matrix client using this matrix bot. you can checkout the site at https://pixx.co/ the repo at https://github.com/pixxels-team/Pixxels-App

[hibobmaster]

I will look at it. It may take some time to achieve that.

[hibobmaster]

To make less changes, i implement thread level context in following steps:

1. mention bot with prompt
2. bot replies in thread
3. send prompt in thread directly without mention it

From web: From mobile:

In this way you guy don't need do anything, then we have room level or thread level chat.

[seshubonam]

hi, great thought. we are trying threads on a matrix client using this matrix bot. you can checkout the site at https://pixx.co/ the repo at https://github.com/pixxels-team/Pixxels-App

wow so quick. 

we tried to manage thread context using llm and msgid. but will try this out. thanks again and again and again.

[hibobmaster]

In version v1.7.0, room level context is user independent same as before, thread level context is thread independent.

So users can use the same context for a single thread, which make more senses. 🎉 https://github.com/hibobmaster/matrix_chatgpt_bot#thread-level-context

Remember create a blank context.db and edit your compose.yaml accordingly before spinning up new version.

[seshubonam]

sure thank you, will check

[mwnu]

In version v1.7.0, room level context is user independent same as before, thread level context is thread independent.

So users can use the same context for a single thread, which make more senses. 🎉 https://github.com/hibobmaster/matrix_chatgpt_bot#thread-level-context

Remember create a blank context.db and edit your compose.yaml accordingly before spinning up new version.

The upgrade is fantastic, but there's a minor issue. In the Matrix Spec v1.4, the implementation method for threads involves assigning the value m.thread to rel_type when an event occurs. However, some clients might use their own tags. For instance, Element Web and Element Desktop might label thread events as "rel_type": "io.element.thread". This is because the server has not yet implemented this version of the Thread MSC, or the client version is outdated, leading to these compatibility changes. I suggest including "io.element.thread" in the robot's thread response events as well.

[hibobmaster]

In version v1.7.0, room level context is user independent same as before, thread level context is thread independent. So users can use the same context for a single thread, which make more senses. 🎉 https://github.com/hibobmaster/matrix_chatgpt_bot#thread-level-context Remember create a blank context.db and edit your compose.yaml accordingly before spinning up new version.

The upgrade is fantastic, but there's a minor issue. In the Matrix Spec v1.4, the implementation method for threads involves assigning the value m.thread to rel_type when an event occurs. However, some clients might use their own tags. For instance, Element Web and Element Desktop might label thread events as "rel_type": "io.element.thread". This is because the server has not yet implemented this version of the Thread MSC, or the client version is outdated, leading to these compatibility changes. I suggest including "io.element.thread" in the robot's thread response events as well.

Adding "rel_type": "io.element.thread" to the response does not work.

[mwnu]

In version v1.7.0, room level context is user independent same as before, thread level context is thread independent. So users can use the same context for a single thread, which make more senses. 🎉 https://github.com/hibobmaster/matrix_chatgpt_bot#thread-level-context Remember create a blank context.db and edit your compose.yaml accordingly before spinning up new version.

The upgrade is fantastic, but there's a minor issue. In the Matrix Spec v1.4, the implementation method for threads involves assigning the value m.thread to rel_type when an event occurs. However, some clients might use their own tags. For instance, Element Web and Element Desktop might label thread events as "rel_type": "io.element.thread". This is because the server has not yet implemented this version of the Thread MSC, or the client version is outdated, leading to these compatibility changes. I suggest including "io.element.thread" in the robot's thread response events as well.

Adding "rel_type": "io.element.thread" to the response does not work.

"rel_type": "io.element.thread" replaces "rel_type": "m.thread", rather than treating them as an array.

[hibobmaster]

io.element.thread

If we use "rel_type": "io.element.thread", thread is nether properly display from element web nor element android.