Review of the delay feature. No more flood alerts. Problem solved.

[tissole]

As you know a big concern with this rapid method of forwarding is the flood alerts raised by TG that some think could lead to an account ban. There are 2 cases reported here, many rumors and even warnings from the developers of similar scripts on Github.

A feature to control the forwarding speed was requested by users, to reduce the risk. @aahnik implemented a mechanism so we could test it. He chose the delay feature.

I created a fresh new channel and starting the test with an initial delay of 3 seconds. The script is working 1s and waits for 3s. I tested in smaller time windows of 3 minutes and then extrapolated to 1h. In 3 minutes the script has forwarded 57 msg, ~1.26 msg/s. In 1 hour will forward 1140 msg. That's too few!

Next, I lowered the delay to 2s. In 3 minutes has forwarded 83 msg, ~1.38msg/s. In 1 hour that results in 1660 msg. Still too few!

Then I tested with the lowest delay of 1s. Has forwarded 154 msg in 3 minutes, ~1.71 msg/s. In 1 hour 3080 msg will be forwarded. That's too many!

We could see that the speed increases as the delay decreases. The max speed is when there is no delay, over 3 msg/s, but that triggers flood. So I needed a delay between 1 and 2 and @aahnik was kind to implement floating numbers.

I tested for bigger timeframes -5 hours- with a delay of 1.65. After 1h 1983 msg were forwarded and no flood!!!. After 5 hours has forwarded 9873 msg, that's 1974 msg/h and no flood alerts!!!

The next test was done with a value of 1.63. After 4 hours the script has forwarded 7989 msg, 1997/h. Still no flood alerts!!

The final test was done with a delay of 1.62s. After 5h 10015 messages were forwarded, 2003/h. No flood alerts!

In conclusion, these values are suitable for long sessions without triggering flood alerts. Feel free to test this feature yourself and give feedback. It would be interesting to find the lowest delay that does not trigger flood and then the next value that triggers those alerts. Use lower values and longer timeframes.

Thank you @aahnik for this feature, I know it was not a top priority and you were skeptical about it, but is working. The script is as fast as before and the flood messages are gone.

[aahnik]

i am glad that the problem is solved! @tissole

[tissole]

But how you handle the lack of persistency for offset value?

[ankit-sinha-18]

Just as you already suggested to someone to find out the last message from the source Channel, I also used this sometimes

But ,I generally check logs within a day before the dyno stops, In the logs I can see the message forwarding Id ,just stop the app and keep in mind that offset
And just update the offset id through config and restart the app again.

[tissole]

Ha...ha...this trick works, but kinda breaks the idea of automatic flow upon which this script is based. I think that a DB will overcome the limitations of non-persistent storage. It offers other advantages besides, preventing duplicates to be forward.

[ankit-sinha-18]

Create a discussion for implementing this feature 😁

[tissole]

That's a good idea, I will open a discussion on this subject.

[BitQuanta]

where you have deployed tgcf

…

On Fri, May 7, 2021, 9:12 PM tissole ***@***.***> wrote: As you know a big concern with this rapid method of forwarding is the flood alerts raised by TG that some think could lead to an account ban. There are 2 cases reported here, many rumors and even warnings from the developers of similar scripts on Github. A feature to control the forwarding speed was requested by users, to reduce the risk. @aahnik <https://github.com/aahnik> implemented a mechanism so we could test it. He chose the delay feature. I created a fresh new channel and starting the test with an initial delay of 3 seconds. The script is working 1s and waits for 3s. I tested in smaller time windows of 3 minutes and then extrapolated to 1h. In 3 minutes the script has forwarded 57 msg, ~1.26 msg/s. In 1 hour will forward 1140 msg. That's too few! Next, I lowered the delay to 2s. In 3 minutes has forwarded 83 msg, ~1.38msg/s. In 1 hour that results in 1660 msg. Still too few! Then I tested with the lowest delay of 1s. Has forwarded 154 msg in 3 minutes, ~1.71 msg/s. In 1 hour 3080 msg will be forwarded. That's too many! We could see that the speed increases as the delay decreases. The max speed is when there is no delay, over 3 msg/s, but that triggers flood. So I needed a delay between 1 and 2 and @aahnik <https://github.com/aahnik> was kind to implement floating numbers. I tested for bigger timeframes -5 hours- with a delay of 1.65. After 1h 1983 msg were forwarded and no flood!!!. After 5 hours has forwarded 9873 msg, that's 1974 msg/h and no flood alerts!!! The next test was done with a value of 1.63. After 4 hours the script has forwarded 7989 msg, 1997/h. Still no flood alerts!! The final test was done with a delay of 1.62s. After 5h 10015 messages were forwarded, 2003/h. No flood alerts! In conclusion, these values are suitable for long sessions without triggering flood alerts. Feel free to test this feature yourself and give feedback. It would be interesting to find the lowest delay that does not trigger flood and then the next value that triggers those alerts. Use lower values and longer timeframes. Thank you @aahnik <https://github.com/aahnik> for this feature, I know it was not a top priority and you were skeptical about it, but is working. The script is as fast as before and the flood messages are gone. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#132>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATLDVJBQYCN3GU3Q2JNENQLTMQC6ZANCNFSM44KMVLVQ> .

[tissole]

I run it from my PC.

[tissole]

A little update. I run more tests. First with a delay of 1.60, after 1h 1962 msgs were forwarded and a pause of 262s was imposed by TG. So this might be the unsafe lower limit between delays. I didn't run it further.

Then I used a 1.61s delay and run for 4h. After the first hour a small pause of 108s was imposed but nothing for the rest. The forwarding rate was 1995 msg/h. This is probably safe but on the edge, better using 1.62 or 1.63. Now we need confirmation for longer timeframes 10h+.

[ghost]

It's very interesting. Thank you. I'll test this over the long term.

[warc0cara]

good night

I'm from Brazil this telegram bot project (tgcf) is incredible, congratulations, I would like to know if I can delay receiving the forwarded message.