[Poll] Twitter Bot SAAS ( software as a service )

[KocerRoxy]

I've seen a few comments on different threads on this forum about twitter bots running as a service.

What this would mean: Instead of running the bot on your own pc, the bot runs on the servers of the creator and you can configure all the required options through a web page.( multiple projects / follow / unfollow / proxies / delays / randomization / etc... ) This way the bot can run 24/7/365 and you don't need any vps or other shenanigans.

What i'm intrested in is finding out if there is a demand for such a bot and if so what kind of features would you guys expect / wish that this bot should have. And also what would you guys expect something like this to cost.

P.S.: i'm only interested in twitter at the moment so please lets keep this thread about twitter. (Thank you)

 

[phatzilla]

Problem is, the credentials would have to be stored on your server. And how would you handle proxies? Are they included? or do users have to provide them?

Im sure it could work, but there's many challenges

 

[KocerRoxy]

Every time you load your credentials into a twitter bot, you're trusting that the developer does not have a `backdoor` into the software that will send the credentials back to him.

It's no different from the SaaS model. The only thing that truly differs is perception.

As for proxies, i think the best method would be to be able to use both versions: either the service itself provides proxies or you can load your own proxies if you want to.

 

[punkinhead]

It's the way it should work, IMO, but there are the obvious issues brought up above and more. For an example, look at tube toolbox vs tube assist. Tube assist moved to "cloud", but they stripped out a lot of features and power... which brings up the other issue that scraping activities can involve lots of cpu cycles, etc. As a consumer, I love the idea that someone else can worry about that stuff, keep the system running, etc... but I would think a developer would either have to throttle it down or have lots of server containers of some sort. I manage to crash and/or overheat my local pc regularly since running FollowLiker.

For a feature set, there are a few things about FL that drive me nuts. Things that should be simple (if not default) are needlessly complex when running multiple accts. Just following those who follow you, for instance, requires setting up another instance, entering each account individually, then going into each one and typing it's own name into the right field, ticking boxes on several screens per acct, etc. And, of course, that other instance means I am now potentially running twice as many threads and causing a few other issues... just to do one simple task that frankly should probably be default behavior.

Actually, I've got a list of items broken down as far as how it SHOULD work, and how it actually does in FL, TS, etc. If you get serious about developing a bot that can run hundreds of accounts, I'll be happy to share some notes.

 

[KocerRoxy]

Hundreds of accounts is easy... I'm thinking more in the thousands. Servers are way cheaper than they used to be and renting a few very `large` servers also brings the cost down.
Using event based models instead of classical threads also increases efficiency and speed (I made a simple twitter bot in php with multicurl using an event based model that could run the equivalent of 1000 threads on a single thread). Classical threads have a lot of overhead

I don't see any reason why a cloud based solution wouldn't match or exceed a `normal` bot in features and performance

And as for being serious about doing this, I wouldn't have posted the question if I wasn't but I also don't want to do it only to find out that people are not willing to at least try it out.

Another advantage of the saas model is that it is evergreen ( no need for updates )
If twitter makes a change while you are away that breaks your bot, you most likely are going to lose time on you projects but in the saas model all the live projects can be updated in minutes potentially.

I would be really interested in hearing what you like/hate about other twitter bots.

 

[jamie3000]

Hundreds of accounts is easy... I'm thinking more in the thousands. Servers are way cheaper than they used to be and renting a few very `large` servers also brings the cost down.
Using event based models instead of classical threads also increases efficiency and speed (I made a simple twitter bot in php with multicurl using an event based model that could run the equivalent of 1000 threads on a single thread). Classical threads have a lot of overhead

I don't see any reason why a cloud based solution wouldn't match or exceed a `normal` bot in features and performance

And as for being serious about doing this, I wouldn't have posted the question if I wasn't but I also don't want to do it only to find out that people are not willing to at least try it out.

Another advantage of the saas model is that it is evergreen ( no need for updates )
If twitter makes a change while you are away that breaks your bot, you most likely are going to lose time on you projects but in the saas model all the live projects can be updated in minutes potentially.

I would be really interested in hearing what you like/hate about other twitter bots.

Ha your bot sounds very similar to mine. Its a nice idea, only point I'd make is you would be even more of a target for Twitter to take legal action against you because this business model is so centralised. If you can handle that heat go for it i say

 

[KocerRoxy]

Don't hold me to this but i think you should be ok with twitter(i mean that they probably won't sue you) as long as you don't include an account creator

 

[jamie3000]

Don't hold me to this but i think you should be ok with twitter(i mean that they probably won't sue you) as long as you don't include an account creator

http://marketingland.com/inside-twitters-spam-lawsuit-9530

Interesting quick read

 

[KocerRoxy]

It doesn't mention if all the defendants are us citizens. Even If they are not, the simplest way of removing their lawsuit angle is to accept/pay only bitcoins. ( same for domains / hosting etc...)

 

[Paper-Boy]

@OP, how much are you going to charge for something like this?

 

[punkinhead]

Yeah, I'm thinking of stepping up to 500 accts personally, but at the current rate, it's going to take a long time and be a real PITA. There is a very narrow field of customers for mass TW automation for the simple reason that the technical barriers to entry and general PITA involved in getting all those accts created and running is far greater than the difficulty in actually running them.

If your service cators to those running mass acctss, then one of the most important things you could do is to ease entry into that arena in order to greatly expand your customer base.

Including all the tools (acct creation or purchase, email verification and unlocking, proxies, etc) under one roof with more of a turnkey service for an upcharge would do wonders for increasing the number of potential customers.

As for some basics about the bot, FL is a good example of how not to do certain things. The whole idea that some things need to be run as global settings, and others as individual doubles the necessary thread count and taxes the system... not to mention being a pain to manage.

What would make more sense is per item (tweet, retweet, etc) choosing details about which accts it goes to (or group of accounts), and what settings (only tweet once, filter for users who retweeted, etc).

For instance, say you want all your accounts to retweet something your main acct tweets. Just set THAT task to all acct groups, and disable only tweet once.

Have a spun tweet that you want each acct to do once per day? Set that one differently.

Want to switch which ones tweet this item? Just open the item and switch the groups it's assigned to. This lets you create overlapping groups so it's nearly impossible for TW to see a footprint.

Also, make sure your random settings are random PER account. When I say I want to follow 400-900 per acct, EACH account should do it's own distinct random number within that range. The more accts you have, the more important these details become. Most of the bots I've looked at are very easy to detect by looking at the overall stats of the group.

 

[KocerRoxy]

@paper-boy i haven't gotten that far yet at the moment
@punkinhead having an all in one solution would indeed be a better value for the users. Giving the users all the tools they need in one place should be imho the first priority.

If i am going to go through with this, there's probably not going to be a mention of threads anywhere... Any threads over the number of cores your processor has is an overhead introduce by bad code... I.e. nginx can handle hundreds of thousands of requests per second with minimal workers ( equal to the number of cores ) this is because when your bot does stuff online, most of the time it's just waiting for some action to finish ( i.e. waiting for a page to load ) if you do stuff in an event based model, you can have 1 single 'thread' waiting for thousands of pages to load at the same time, without any added overhead

A real live example: i had to make a script that pinged about 30k ips every ten minutes. The first iteration i made in the clasic way... Ping one, wait for replay( up to 5 seconds, retry if the ping failed up to 3 times -- so it could potentially take 15 seconds for each ip... Times 30k that's 125 hours... If i had 100 threads that would still take up to 1.25 hours ). The second iteration was based on an event model, i would just send all the pings one after the other(this takes about 1/1000 of a second ) and then listen for the ping replies all at once so they can come bakc in which ever order. I did a test with this on a single thread but some of the ips always showed up as down because the cpu of the vps i was using was rather slow so my next iteration kept the event model but only pinged 1000 ips at a time and the results were great and the max potential time was reduced to 15 seconds times 30 batches of 1000 so a total of 450 seconds for 30k IPS but in reality because most are live, it takes about 50-80 seconds to run, on a single vps core with 2.0 ghz
Edit: I forgot to add my conclusion: I see it working kind of like this: you load your accounts, maybe split them into groups ( potentially overlapping groups ), create a new project that has some actions in it ( scrape / tweet / reply / retweet / etc ) and assign the project to one or more groups, setup a schedule for your project and maybe an optional start/end date and save it, and it just runs in the background on the servers without setting threads or connections or anything like that.

 

[KocerRoxy]

IP changing is not really an issue with most server providers, also lots of providers of proxies accept password authentication

 

[blurr]

Why should you even use proxy? Just one IP, since you are using API.

 

[KocerRoxy]

Nobody said anything about using just the api, I think that a combination of api / web would work best.
But even if you use only the api, there are per IP limitations from twitter

 

[punkinhead]

Correct me if I'm wrong. I've only dabbled in very light development (websites, a media player), but... wouldn't it make a lot more sense to steer clear of the api alltogether? Real users interact over the web. The api use alone establishes a footprint which is distinctly different than that of a real user. Plus, even if everything is kosher today, one change on TW's end to how they treat API use, and you could end up with all your clients' accts banned overnight. Seems to me that all these kinds of issues are avoided by sticking with straight web interface, no?

Also, good to see you're picking up on the overlapping groups thing. The more I dig into this stuff, the more obvious footprints I see from the bots I've used (TSupremacy, FL). If TW isn't picking up on some of that stuff yet, it won't be difficult for them to do so. To give a rough example of what I mean about the overlapping...

Using the example of someone selling athletic shoes:

50 accts across 10 proxies means 5 per proxy.

So, there's already one association. Each proxy is a group. Proxy group 1 has 5 accts as does proxy group2, etc.

However, we DON'T want that group to define all other activity. Quite the opposite. If we want some of the accts to follow Reebok's followers, for instance, and some to follow Nike's, the worst thing we could do is have all the proxy group 1 accts chase nike, all the proxy group 2 accts follow Reebok, etc. That's an easy pattern to spot. All accts on the same proxy are doing the same thing.

Better is having the first account in each proxy group in group A, the second from each in group B, etc... so in the A, B, C groups, there's only one acct per group on each proxy. Now assign Nike to group A, Reebok to group B, etc. Much harder to see any pattern there.

Now spit it some other way. Half get this search term, half get that, but NOT split according to either of the existing groupings.

Anyway, this kind of ability to assign each acct to multiple groups, and assign any task to any group or groups (and switch which groups they apply to at will) can pretty quickly add up to a situation where it's impossible for TW to detect a footprint.

Doing this in FL would mean running MANY instances of the software simultaneously which would crush even a decent system.... but there's really no reason it should work that way. Fact is, it shouldn't. I'm not doing half the stuff I want to in FL right now because it's just too much of a PITA and would kill the system to run all those instances. You should be able to:

1) Create an acct, assign proxies or have them auto assigned according to max per

2) Create groups of those accts. Name a new group, add accts to it or subtract groups from it.

3) Create tasks where the randomization is per acct

4) Assign each task to the group or groups (or individual acct) of your choice.

That's it. Now you're only running one instance of the software. Actually, it's not taxing any more resources than one instance of something like FL would use... except it's doing a MUUUUUCH better job of making each acct appear unique and gives WWWAAAAAYYYYY more control.

 

[KocerRoxy]

There are use cases where the twitter api is much better suited than the web interface. The best example of this is twitter's streaming api.

With the streaming api you can for example 'follow' a given list of users and you are instantly notified about tweets from those accounts without having to constantly search. You can also track keywords/hashtags/geo zones with the streaming api, for these reasons the streaming api would be much better suited for a wait and reply module because you could reply instantly and you would have a much better chance of catching the target online and another plus is that you don't rape the proxies by searching every few seconds.
You can also have different types of accounts for different tasks: you have accounts that use the streaming api ( this is legit and will never get you banned ) and you have other accounts that do the actual follow / reply / etc

 

[punkinhead]

Yeah. That much makes sense to me. Do the search with one account, and have the other do pure web interface. Like I said... not a developer, just seems that the api stuff is the easiest point for TW to choke off bots in future revisions. Common sense just tells me, for instance, that if their TOS says no automation... then you have to grant permission for an app to access your account... I've seen some Youtube tools work that way, anyway. Just strikes me as a flawed concept... and I have read the odd story here and there about one social network or another pulling the plug on tools that did their tos violations via api. I seem to remember something similar about TW fairly recently.

Twitter does a crap job of cleaning up it's user rosters at the moment, but that doesn't mean they won't get better at it. Just taking longevity into consideration.

 

[blurr]

You can always use official twitter applications to access the API, for example, Twitter for Android. No footprint left behind.

 

[punkinhead]

Gotcha.

My distinction was what happens when a native button is pressed (via web or TW app) vs a third party app being enabled to interface with the API. I made a YT embed player a while back and had all sorts of issues to sort about how YT views data coming in from thier own player vs any third party on the api. The plays may look the same to the user, but YT knows the difference and treats them differently.

Maybe I'm making too much of distinction upon that recent experience. So long as all interaction looks to TW like it is coming directly from one of thier own interfaces (be it their website or their app)

The second it appears on their end as a third party app accessing the api, they can shitlist you (and all your customers) on a whim.