feat: add more credentials

[nickchen120235]

Closes #2

This PR introduces all four key pairs found here

Testing Instructions

No functionality changes. Everything should still work.

[12joan]

Looks good! Just one small typo

[nickchen120235]

I'm converting this to draft temporarily because I found some other tokens that might work. zedeus/nitter#925

I'll be back if any (or none) of them works.

[nickchen120235]

So both the developer.twitter.com and the ipad token will return 20 tweets per request. But the tweetdeck token usually returns less than 20 tweets.

[12joan]

That's interesting. I'll let you decide what's best here.

Incidentally, I'm liking Twitter's new tagline, courtesy of DuckDuckGo.

[nickchen120235]

Here's my plan

1. Remove caching for the access token (since they are hard-coded)
2. Remove caching for guest token (this may add a little more overhead but we can make sure that the randomly-picked access token are actually used)
3. We can keep user id cached since it should not change when different token is given

If this sounds like a plan, we can keep the tweetdeck key but give it a lower weight.

[12joan]

That sounds all right to me. No need to remove guest token caching, since the cache is keyed on the access token.

[12joan]

Are we confident that the hardcoded access tokens are just as unlikely to change as the raw client credentials?

[nickchen120235]

As far as I can tell, the bearer token for the frontend (twitter.com) hasn't changed untill all hell breaks loose, so I think those tokens are unlikely to change.

However, considering the Tesla guy is constantly unplugging any means of twitter profile scraping, the tokens may or may not be invalid in the near future.

[12joan]

Thanks! Are we ready to merge?

[nickchen120235]

I think we are good to go!