Please ease the restrictions on getting their own friends/followers data.

Twitter's API restrictions are getting stricter every year, and starting with Twitter API v2, I understand the data that users will be able to retrieve via the API will decrease by 80%.
Previously, with a single API call, users could retrieve 5,000 friends (or followers), but in the future, users will only be able to retrieve 1,000 friends (or followers). https://developer.twitter.com/en/docs/twitter-api/users/follows/migrate

I understand that this decision has been made from the perspective of sustainability of the service, but please reconsider restricting users from controlling their own data.

As one solution, how about separating the rate limits for when users retrieve their own data and when users retrieve other data?

Users are unable to search any words in the DM other than an exact name. This is a significant friction problem.

If we could search keywords for followers that want us to "notify" or of our Twitter Spaces directly, we could search them.

If we could search keywords we drop in the DM ourselves, we can quickly reconnect with specific connections.

It's a problem that if we don't spell someone's name exactly, we can't find their DM messages. This is especially a problem in an international community where we don't know how to spell names or remember them perfectly when time has passed.

Facebook has this in messager and it is powerful for reconnecting and searching messages to further & deepen relationships.

Enable creation of dedicated "bot" accounts, solely for posting tweets or other automated activity. These would display with a 🤖 robot emoji by the name (instead of a blue checkmark) so they are easily distinguished from regular users.

Self-selecting into the "bot" category could come with a different, more restrictive set of permissions - no web login or posting (OAuth only), cannot Follow others, or whatever other limits Twitter wants to impose on them. On the flip side, bots could enjoy different categories of moderation, suspension, or flagging rules as they are no longer being confused with "human" posters. No need to tie them to a phone number, for example, or provide other human identity verification.

The idea is to carve out a space for developers of purposeful "art bots", away from the current discourse surrounding bots as foreign agents, disinformation tools or political weapons.

A rule operator of "no more than X tweets per second" is very similar to sampling. However, if it existed, it could theoretically set on every rule. This would allow knowing that no rules could absorb too much of total allowed volume, and to make sure that low volume rules aren't sampled, while higher volume rules still are. It would also mean that a rule that has a sudden burst of activity would not absorb all available volume at once. Without this operator, monitoring the volume on rules must take place, and sampling must be applied dynamically when volume increases or decreases.

Please consider changing the current rate limit for the recent search endpoint (v2 API). Currently an app can only fetch a total of 500k tweets in a monthly window, no matter how many active Twitter users it has, or if the requests are per-user. If an app has over 500k active user then there's no way for the app to function correctly due to this limit.

In my case we're offering people to fetch hashtagged posts from Twitter for free, which is very popular for all kind of events, such as weddings and virtual conferences. We're not able to provide this type of service for Twitter if this hard limit is not removed or modified.

A better solution would be to decrease the number of tweets a user can fetch in a 15 minutes window, e.g. 300 tweets instead of 900 tweets in the Standard Basic access.

Another concern with the current limit is that people will be looking for alternative solutions, e.g. using scrapers to bypass new limits.

Currently the only way to fetch a user is by either using ID or username, which is great for most usecases. However, most of the endpoints need the authorized user's ID in the path. As a library dev I don't want to force the user to pass the authorized user's ID everytime they call a method. So, as a workaround I ask them to pass the "username" along with other credentials during login. Then I use that "username" to fetch the authorized user and save it in the cache. This way I can automatically pass the authorized user's ID internally wherever it is needed.

There is a problem with this approach. The user can change their twitter username and hence if they didn't change their username in the code, the fetched user would be someone else. This is why I'm asking for an "/@me" enpoint that will respond with user data by using the access token and secret. Unlike the fetch by username endpoint this endpoint can easily throw error if the provided credentials don't exist.