Let's start with the familiarization part in the software.
In the software there are 2 methods for inviting, they are username invite and user id invite.
I use username invite. Why? In this method there is a function forced number of invited users. What is it responsible for? It only counts successful invites (Done). All extraneous things like user privacy, user already in a group, etc. it does not count as a successful invite. Since I try to use each account to the maximum, I need this feature.
Adding the database,
which we sparred, enter username of the group where we want to add participants, then we move on to delays.
1 field means min [ ] users max [ ] users the number of participants that will be given to the account to add.
For example in the min column we will specify 30, in the max column we will specify 40, then each account will take a random number of participants from 30 to 40.
Since I try to make the account work to the maximum I set min [48] users max [48] users or min [49] users max [49] users.
Telegram limits on adding participants from 1 account is 50 people. Why do I set 49 participants? According to my repeated tests, I noticed that at about 50 participants added, Telegram spams the account for 3 days. If you stop at 49, the account is more likely to remain free of restrictions.
Delay
min [ ] sec max [ ] sec. This is the account delay between user additions.
This field is quite important for invites. If you don't specify the delay between account requests to add a member correctly, you can get either a ban, spam, floodwait, or the account will waste users (the software will successfully add users, but the counter in the group will stand at the same place). According to my tests I use a min [15] sec max [35] sec delay. Or min [25] sec max [50] sec.
For about 6 accounts I get between 250 and 280 successful invites. (I count successful ones by the counter in Telegram).
Why such a big spread of 250-280 people from 6 accounts? Well, first of all, Durov and his team know all the limits and protection of Telegram, and according to my tests I noticed that good proxies affect the number of successful invites as well.
The minus of rotating proxies is that someone else is using them too. You can add 280 people from one batch of 6 accounts, immediately start a new thread of 6 accounts and add 250 people on the same settings, or even less.
The problem with invite is that there is no 100% correct working option, too many factors affect the work (proxy, account itself, account geo, delays, group where you add, what audience you add, etc.) But in this article I will tell you what I know and how I work.
Maximum timeout: As far as I understand it works like this. If you specify 600 seconds, if the account gets FloodWait for 300 seconds, then the software will stop the account for 300 seconds, then try to continue working again, if the account gets FloodWait or any other limitation more than 600 seconds, then the software will stop working with this account.
I always set it to 600 seconds.
Choosing accounts. Choose the accounts that will work at invite and add new people. Usually at the beginning of work with any group I use 1 account for a test. If 1 account successfully adds +- 40-49 people, then I continue to invite to it.
Example: I have a goal to get 500 people into a group. I roughly understand that to add 500 people I will need 11-12 accounts.
There are 2 ways to get 500 people from 11-12 accounts. Either to divide into 2 batches of 6 accounts, or to choose 12 accounts to work at once, and through the flow control option to choose the number of accounts that will work at once (I will explain more about working with flows below).
Forced number of invited users. Counts only successful invites (Done).
Leave main group. After adding members, the account will leave the group to which it added these members.
Protection from bots. As far as I understand this function protects and does not invite bots to chat.
Flow Control. This is the number of accounts running simultaneously. This is very important when inviting. The number of threads also affects the quality of successful invites, and the protection of accounts from spam, floodvite, ban, etc.
I usually run 6 threads after 1 test with 1 account. I recommend to use no more than 8 threads.
I also use a delay between threads of 1 - 40 seconds. This is necessary so that 6 accounts will not start working at once. And randomly in turn 1-40 seconds began to work.
Since I wrote above that you can select 11-12 accounts at once to add +- 500 people, but I don't want 11-12 accounts to start working at once, but to do their work one by one, I specify 6 threads in the number of threads. With this setting the software will take 11-12 accounts, but at the same time it will start only 6, after one of the working accounts is finished it will immediately start the next one. And so it will run 11-12 accounts or any other number of accounts through 6 simultaneous threads.
Automatic stop. In case of ban, spam on account or flood wait will stop the software. Usually I put only on Ban status and Spam block 1 each.
For the safety of accounts I also check the checkbox for emergency closing of the program.
The maximum number of invites from an account is 50 people per day. Usually if the account without restrictions on the next day I use it to work.
Hibernation. For GEO Russia is enough 3+ days for invites. (At the moment after registration of a new account you can receive spam in the form of TempSpamBlock(GeoNumber) when 3+ days on a new account this spamblock is removed. With it on 1 invite you will get a restriction and can not add more).
I don't advise you to do any actions at all with the accounts until 3+ days until it's 3+ days old.
Don't forget to put a bot that will delete system messages in chat (user invited user to chat). Otherwise there will be a lot of notifications, users will start to throw spam, accounts will start to fly to the spam block, in short there will be a lot of difficulties.
PeerFloodError - spam block.
UserBannedInChannelError - eternal spamblock.
FloodWaitError - an error when there are too many requests from your Telegram account. It is issued randomly by Telegram from 60 seconds to 80 thousand seconds.
UserKickedError - user deleted or banned from the group.
UserPrivacyRestrictedError - the user has locked their account with privacy.
UserNotMutualContactError - It is impossible to add a logged out member.
UserChannelsTooMuchError - The user has too many chats.
UserIdInvalidError - User information is invalid.
Possible problems with invecta.
Here I will try to tell you about the problems I have encountered with invecta.
Hone the group.
Group durability is important, but it is also important to invite to the group correctly. According to my tests, and in general, I myself have poured a few groups with 7+ days of durability.
But of course it is better to buy a group with a longer durability.
Now, with the current Telegram updates, you can kill a group with any kind of timeout. It probably depends on the right invite, not on the timeout.
How to kill a group?
According to my tests and practice, I killed different groups, groups where there were bots, groups where there were no bots, new groups, groups with 5 000 + participants, etc.
On the tests I can say the following, no matter how many bots you have initially in the group, for the invite. If there is no activity in it, and new users exceed the threshold for complaints, you will get a mut on the group. How does this muting manifest itself? When inviting, your accounts on 1-5 adds will receive a FloodWait from telegram. It is unknown at this time how much this mut is imposed on the group.
Example: You have 5000 members in your group, 4500 of them are bots. 500 members are barely alive, there is little activity, online is small. Here you add 1000 new users, of this thousand of some % of users complain, if the limit of complaints exceeds, you will get a mut on the group.
Tip: do not rush to immediately add a large number of members at a time. It is better to slowly, little by little to raise the activity in the group and the number of live audience. I also do not advise you to add only active audience (those who wrote in the chat) at once. Parser all in a row, add live people, bots ... To reduce the number of complaints about the group.
How do I do? From 0 to 1000 people a day I add 200-300 people. From 1000 to 2000 thousand 250 - 350 people. From 2000 to 3000 350 - 450 people. From 3000 to 5000 thousand 500-600 people. From 5000 to 8000 thousand 600-800 people. Above 8000 people already adding 1000+ people per day.
See activity, see online, the number of participants. The more activity to your participants, the more you can add people per day.
On 25000 participants I boldly poured up to 3 thousand people per day and the group is stable live for the invite. At these limits I have never gotten a group mut yet.
How else can you get a group mut? Recently I was testing India accounts.
I decided to try this method. 50 accounts in 10 threads of 10 people. After completion, I would run the invite again to maximize the accounts.
Days 3-4 accounts successfully worked, +- not bad, in such a mode successful invites for India at least somehow worked. Until one moment, I started the party, all accounts that participated in the work flew to the ban, and on the group imposed mut.
There are also group problems.
Problem groups I call those groups where the heavy audience.
As a rule after parsing a heavy audience when inviting a large number of people is privacy. You will receive UserPrivacyRestrictedError messages in the console often.
If there are a lot of UserPrivacyRestrictedError, the account will get FloodWait. For example. 30 accounts he tried to add, 17 of them with privacy, he was able to add 13 and got FloodWait. Even though he should have made 48-49 invites. Don't be too surprised by this, that accounts go to FloodWait. Try to find another group for parsing.
I came across an interesting thing. Since the software does not track users who are already in the group when inviting, it adds them and in the software they go as Done.
But in fact the software counts the person who was already in the group as Done. I discussed this with Strix, he said that soon it will be implemented to exclude such users.
In the meantime, I will have to parse another group that has not participated in the invite before.
translated from topic - https://blb.team/threads/invajt-geo-rossija.3220/
In the software there are 2 methods for inviting, they are username invite and user id invite.
I use username invite. Why? In this method there is a function forced number of invited users. What is it responsible for? It only counts successful invites (Done). All extraneous things like user privacy, user already in a group, etc. it does not count as a successful invite. Since I try to use each account to the maximum, I need this feature.
Adding the database,
which we sparred, enter username of the group where we want to add participants, then we move on to delays.
1 field means min [ ] users max [ ] users the number of participants that will be given to the account to add.
For example in the min column we will specify 30, in the max column we will specify 40, then each account will take a random number of participants from 30 to 40.
Since I try to make the account work to the maximum I set min [48] users max [48] users or min [49] users max [49] users.
Telegram limits on adding participants from 1 account is 50 people. Why do I set 49 participants? According to my repeated tests, I noticed that at about 50 participants added, Telegram spams the account for 3 days. If you stop at 49, the account is more likely to remain free of restrictions.
Delay
min [ ] sec max [ ] sec. This is the account delay between user additions.
This field is quite important for invites. If you don't specify the delay between account requests to add a member correctly, you can get either a ban, spam, floodwait, or the account will waste users (the software will successfully add users, but the counter in the group will stand at the same place). According to my tests I use a min [15] sec max [35] sec delay. Or min [25] sec max [50] sec.
For about 6 accounts I get between 250 and 280 successful invites. (I count successful ones by the counter in Telegram).
Why such a big spread of 250-280 people from 6 accounts? Well, first of all, Durov and his team know all the limits and protection of Telegram, and according to my tests I noticed that good proxies affect the number of successful invites as well.
The minus of rotating proxies is that someone else is using them too. You can add 280 people from one batch of 6 accounts, immediately start a new thread of 6 accounts and add 250 people on the same settings, or even less.
The problem with invite is that there is no 100% correct working option, too many factors affect the work (proxy, account itself, account geo, delays, group where you add, what audience you add, etc.) But in this article I will tell you what I know and how I work.
Maximum timeout: As far as I understand it works like this. If you specify 600 seconds, if the account gets FloodWait for 300 seconds, then the software will stop the account for 300 seconds, then try to continue working again, if the account gets FloodWait or any other limitation more than 600 seconds, then the software will stop working with this account.
I always set it to 600 seconds.
Choosing accounts. Choose the accounts that will work at invite and add new people. Usually at the beginning of work with any group I use 1 account for a test. If 1 account successfully adds +- 40-49 people, then I continue to invite to it.
Example: I have a goal to get 500 people into a group. I roughly understand that to add 500 people I will need 11-12 accounts.
There are 2 ways to get 500 people from 11-12 accounts. Either to divide into 2 batches of 6 accounts, or to choose 12 accounts to work at once, and through the flow control option to choose the number of accounts that will work at once (I will explain more about working with flows below).
Forced number of invited users. Counts only successful invites (Done).
Leave main group. After adding members, the account will leave the group to which it added these members.
Protection from bots. As far as I understand this function protects and does not invite bots to chat.
Flow Control. This is the number of accounts running simultaneously. This is very important when inviting. The number of threads also affects the quality of successful invites, and the protection of accounts from spam, floodvite, ban, etc.
I usually run 6 threads after 1 test with 1 account. I recommend to use no more than 8 threads.
I also use a delay between threads of 1 - 40 seconds. This is necessary so that 6 accounts will not start working at once. And randomly in turn 1-40 seconds began to work.
Since I wrote above that you can select 11-12 accounts at once to add +- 500 people, but I don't want 11-12 accounts to start working at once, but to do their work one by one, I specify 6 threads in the number of threads. With this setting the software will take 11-12 accounts, but at the same time it will start only 6, after one of the working accounts is finished it will immediately start the next one. And so it will run 11-12 accounts or any other number of accounts through 6 simultaneous threads.
Automatic stop. In case of ban, spam on account or flood wait will stop the software. Usually I put only on Ban status and Spam block 1 each.
For the safety of accounts I also check the checkbox for emergency closing of the program.
The maximum number of invites from an account is 50 people per day. Usually if the account without restrictions on the next day I use it to work.
Hibernation. For GEO Russia is enough 3+ days for invites. (At the moment after registration of a new account you can receive spam in the form of TempSpamBlock(GeoNumber) when 3+ days on a new account this spamblock is removed. With it on 1 invite you will get a restriction and can not add more).
I don't advise you to do any actions at all with the accounts until 3+ days until it's 3+ days old.
Don't forget to put a bot that will delete system messages in chat (user invited user to chat). Otherwise there will be a lot of notifications, users will start to throw spam, accounts will start to fly to the spam block, in short there will be a lot of difficulties.
PeerFloodError - spam block.
UserBannedInChannelError - eternal spamblock.
FloodWaitError - an error when there are too many requests from your Telegram account. It is issued randomly by Telegram from 60 seconds to 80 thousand seconds.
UserKickedError - user deleted or banned from the group.
UserPrivacyRestrictedError - the user has locked their account with privacy.
UserNotMutualContactError - It is impossible to add a logged out member.
UserChannelsTooMuchError - The user has too many chats.
UserIdInvalidError - User information is invalid.
Possible problems with invecta.
Here I will try to tell you about the problems I have encountered with invecta.
Hone the group.
Group durability is important, but it is also important to invite to the group correctly. According to my tests, and in general, I myself have poured a few groups with 7+ days of durability.
But of course it is better to buy a group with a longer durability.
Now, with the current Telegram updates, you can kill a group with any kind of timeout. It probably depends on the right invite, not on the timeout.
How to kill a group?
According to my tests and practice, I killed different groups, groups where there were bots, groups where there were no bots, new groups, groups with 5 000 + participants, etc.On the tests I can say the following, no matter how many bots you have initially in the group, for the invite. If there is no activity in it, and new users exceed the threshold for complaints, you will get a mut on the group. How does this muting manifest itself? When inviting, your accounts on 1-5 adds will receive a FloodWait from telegram. It is unknown at this time how much this mut is imposed on the group.
Example: You have 5000 members in your group, 4500 of them are bots. 500 members are barely alive, there is little activity, online is small. Here you add 1000 new users, of this thousand of some % of users complain, if the limit of complaints exceeds, you will get a mut on the group.
Tip: do not rush to immediately add a large number of members at a time. It is better to slowly, little by little to raise the activity in the group and the number of live audience. I also do not advise you to add only active audience (those who wrote in the chat) at once. Parser all in a row, add live people, bots ... To reduce the number of complaints about the group.
How do I do? From 0 to 1000 people a day I add 200-300 people. From 1000 to 2000 thousand 250 - 350 people. From 2000 to 3000 350 - 450 people. From 3000 to 5000 thousand 500-600 people. From 5000 to 8000 thousand 600-800 people. Above 8000 people already adding 1000+ people per day.
See activity, see online, the number of participants. The more activity to your participants, the more you can add people per day.
On 25000 participants I boldly poured up to 3 thousand people per day and the group is stable live for the invite. At these limits I have never gotten a group mut yet.
How else can you get a group mut? Recently I was testing India accounts.
I decided to try this method. 50 accounts in 10 threads of 10 people. After completion, I would run the invite again to maximize the accounts.
Days 3-4 accounts successfully worked, +- not bad, in such a mode successful invites for India at least somehow worked. Until one moment, I started the party, all accounts that participated in the work flew to the ban, and on the group imposed mut.
There are also group problems.
Problem groups I call those groups where the heavy audience.
As a rule after parsing a heavy audience when inviting a large number of people is privacy. You will receive UserPrivacyRestrictedError messages in the console often.
If there are a lot of UserPrivacyRestrictedError, the account will get FloodWait. For example. 30 accounts he tried to add, 17 of them with privacy, he was able to add 13 and got FloodWait. Even though he should have made 48-49 invites. Don't be too surprised by this, that accounts go to FloodWait. Try to find another group for parsing.
I came across an interesting thing. Since the software does not track users who are already in the group when inviting, it adds them and in the software they go as Done.
But in fact the software counts the person who was already in the group as Done. I discussed this with Strix, he said that soon it will be implemented to exclude such users.
In the meantime, I will have to parse another group that has not participated in the invite before.
translated from topic - https://blb.team/threads/invajt-geo-rossija.3220/