-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ability to handle multiple chats with a single instance of tg-spam #100
Comments
Which type of separation is preferable?
There are also a number of questions about behavior
In principle, I've already implemented the second option, except for the mentioned questions. Well, and tests need to be expanded |
1 is like running multiple instances, but with the same tokens, which is impossible with multiple instances. To me, 2 sounds preferable, i.e. a single "event loop" on multiple chats/groups.
I don't think it should be that smart, i.e. I would expect it to ban the user only on the chat it sent spam to.
I'm not even sure if we actually care about a separate set of super users. We can keep a single list at least for now. However, if you're going to implement separate lists, I don't think allowing cross-chat bans between super users should be permitted.
As far as I recall, TG API doesn't provide this info, but I can be wrong on this one. If such info can be retrieved, this is the solution, but if not, we can consider disabling forwarding functionality in this mode (probably should be a message in admin chat explaining it if a message was forwarded). |
OK, the second option suits me completely as well
OK
If we set super-users in the old format (just the name), then the current behavior will not change and they will be able to moderate all chats. Additionally, there will be an option to restrict a super-user to a specific chat (chat:username instead of just username). And accordingly, chat admins will be able to moderate only their own chats.
A forwarded message gives us forward_date (timestamp of the original message), forward_from.id (original userID), from.id (super-user/admin userID) and text (message content). If we replace time with the time from the processed message in the "messages" table, then it's possible to limit the set of chats by super-user, and with the other parameters, we can find the message itself with a high degree of probability. |
I don't think this is the case. From what I recall all the forwarded messages have the same user id of some TG forward bot or smth like this |
Now I see {
"ok": true,
"result": [
{
"message": {
"chat": {
"id": -1002242702397,
"title": "TestSpamAdminGroup",
"type": "supergroup",
"username": "TestSpamAdminGroup"
},
"date": 1722888044,
"forward_date": 1722873154,
"forward_from": {
"first_name": "Chan",
"id": 5748393497,
"is_bot": false,
"last_name": "Lee"
},
"forward_origin": {
"date": 1722873154,
"sender_user": {
"first_name": "Chan",
"id": 5748393497,
"is_bot": false,
"last_name": "Lee"
},
"type": "user"
},
"from": {
"first_name": "No",
"id": 182570762,
"is_bot": false,
"is_premium": true,
"language_code": "en",
"last_name": "Man",
"username": "copermann"
},
"message_id": 59,
"text": "message"
},
"update_id": 674833881
}
]
} Chan Lee is the spammer and copermann is the super-user who reported this |
Thank you for a great tool!
Nope. Actions should be taken only upon event. Spam in one chat should however increase probability to ban in other chat. Similar to cas ban idea.
Nope. That would be unexpected behavior |
This was requested by @winhex during our conversation about #98
The main issue with the current approach of running multiple instances of tg-spam is the need to create separate bots, set up and potentially synchronize configurations, samples, and all other data. However, if you manage multiple chats, it could be advantageous to use a single instance of tg-spam to protect all of them with shared rules, data, and history.
Implementing this change is not straightforward because it involves dynamically managing all information related to the "source chat." Instead of having a predefined group ID in the configuration, the bot will have to fetch messages from multiple groups and correctly handle the group ID for all actions. Most likely, the new "source group/chat id" should be incorporated across data storage, API, and UI levels.
By the way, it appears that a single bot can monitor multiple chats as long as the bot is a member in those chats.
The text was updated successfully, but these errors were encountered: