A problem raised when we are working on Dall-E feature: We need the bot to enter a dialogue mode where the bot ask questions, and users can reply back to continue the painting. The current dispatcher will literally not support this operation, because the handlers are performed one-by-one in registration order. Registering DallE module earlier than Chat module seems to solve our problem, but that would just be a workaround.

The common usage of the bot is chatting, it's the default mode. However, sometimes, some other modules may want to respond to a message with higher priority temporarily. This is where Conversation comes in. It's similar to Dialogue in teloxide, but instead of single-typed state, we support multiple-typed state, and each type of state can provide different handlers. Back to the problem we issued before. When user want to use Dall-E, it can type let's say /paint, then the bot will enter a Dall-E painting conversation. User can answer the questions asked by bot in the conversation without being intercepted by Chat module. This is implemented by a handler ahead of regular module handlers.

As we are doing the refactor, we also refined how commands are handled. In the current implementation, command providing and handling are separated, which is not that scalable and maintainable. In the next version, it will also be unified.

Here is a overview of how updates are processed in the new dispatching pipeline:

[Updates] --> (Preflight Filter) --> (Conversation Handler)
                                 |-> (Command Handler)
                                 |-> (Module Filter Handler)
                                 |-> (Default Handler)

Legend: [Input]
        (Handler)

This PR adds Markdown supports that renders contents returned from OpenAI server into Telegram's rich text format. Rather than directly rendering the Markdown contents to HTML, we parse them with a pull-mode parser and generate the message entities provided by Telegram. This approach ensures maximum compatibility with Telegram.

Note: The feature is disabled by default, users may manually enable it in the configuration.

docker pull ghcr.io/icystudio/telegpt:sha256-0b1341532c105be66bf5e9969644761df51d299243e90f277f288889925657c4.sig sha256-0b1341532c105be66bf5e9969644761df51d299243e90f277f288889925657c4.sig: Pulling from icystudio/telegpt 0abb78e9996e: Extracting [==================================================>] 241B/241B failed to register layer: Error processing tar file(exit status 1): unexpected EOF

As we are going to support Dall-E feature soon, OpenAI client will be used across the modules. In this PR, we extract the client from Chat module to a separate module.

By the way, due to the capacity problems of OpenAI APIs, I also added a configuration item: max_tokens to limit the maximum tokens in the answer response, which can alleviate the problem.

This PR adds supports to configure the bot from a config JSON file. It also introduces a CLI option to specify the config path (other options may be added in the future).

I have found an issue with this program, it cannot work continuously and often needs to be manually executed or reset to work normally. I also noticed that your demo program has the same problem. If we continuously send messages, it will keep displaying "Thinking..." and the following log will appear:

DEBUG telegpt_core::dispatcher          > nssss sent a message: 你好
TRACE want                              > signal: Want
TRACE want                              > signal: Want
TRACE want                              > signal: Want
TRACE want                              > signal: Want
TRACE want                              > signal: Want
TRACE want                              > signal: Want
OpenAI response: Ok(
   ChatModelResult {
       content: "",
       token_usage: 3413,
   },
)
TRACE want                              > signal: Want
TRACE want                              > signal: Want
TRACE want                              > signal: Want
TRACE want                              > signal: Want
ERROR telegpt_core::modules::chat       > failed to send message (will fallback to raw contents): A Telegram's error: Bad Request: message text is empty
TRACE want                              > signal: Want
TRACE want                              > signal: Want
ERROR telegpt_core::modules::chat       > Failed to handle chat message: A Telegram's error: Bad Request: message text is empty

Based on your description, it seems like you are encountering errors while using TeleGPT on a CentOS 9 environment to connect to Telegram. You are wondering if there is a way to run TeleGPT in debug mode to help diagnose the issue.

To address this issue, you can try running TeleGPT with debug logging enabled. You can do this by setting the logging level to DEBUG in the configuration file or by passing the -d or --debug option when starting TeleGPT.

After the cargo build --release, everything seemed ok until the teloxide-core

root@ubuntu-s-1gb-sgp1-tg:~/TeleGPT# cargo build --release
   Compiling teloxide-core v0.6.3
    Building [=====================>   ] 227/253: teloxide-core  

It seems the crate 'teloxide-core v0.6.3' could not be found in registry index.

app_1 | 2023-03-22T01:27:41.154Z ERROR telegpt_core::modules::chat > Failed to handle chat message: A Telegram's error: Bad Request: message text is empty

[+] Running 0/1 ⠿ app Error 2.0s Error response from daemon: denied

docker login 成功 执行 compose 报错

[+] Running 0/1
 ⠿ app Error                                                                                                                                                                              1.1s
Error response from daemon: denied

level=info msg="Attempting next endpoint for pull after error: denied"
level=error msg="Handler for POST /v1.42/images/create returned error: denied"