The Global Rate Limit by IP is Developer Unfriendly and Counter-Productive

[gnito-org]

The global rate limit of 3,000 API calls per IP per 5 minutes is extremely discouraging when one wants to develop a service that will have thousands of customers, each performing actions on their own Bluesky account, via the central servers of the bespoke service (for example: social media management, analytics, engagement, etc.).

The API calls for all the customer actions will be via the IP address(es) of the service's servers. The limit of 3,000 means your customers can each perform one operation every 5 minutes if you have 3,000 customers. That is just nuts.

To work around this limitation, the developer is going to spin up multiple servers, each with its own IP address. And guess what? That invalidates any usefulness of that particular rate limit and it unnecessarily increases costs for the developer.

I get it that Bluesky must protect against spam. But, we're not talking about a spamming service here.

Per handle or per app password rate limits are perfectly fine, because it targets abuse while not limiting legitimate large-scale API usage.

[emilyliu7321]

Hi @gnito-org, thanks for the note! We're planning some improvements to the rate limiting system. Can you share some more information about what your use case is so we can keep it mind?

[gnito-org]

My recommendation would be to completely remove the per IP rate limit and focus on per handle and/or app password rate limits.

Per IP rate limits never work. They are trivial to circumvent by spammers and they frustrate legitimate high-velocity API use. Think of services such as HootSuite, Buffer, Sprout Social, and a myriad similar services.

Without serious business use of the network, you can take it into the backyard now and shoot it.

[gnito-org]

A common issue experienced by the services I referenced above is that you get light-volume users and heavy-volume users of your service.

A common (IP-related) rate limit severely penalizes the light-volume users of your service since their usage gets curtailed due to the heavy-volume users consuming the common rate allowance.

A common rate limit actually also penalizes a third-party service for its success in building a business on top of the Bluesky service.

I guess one solution to this problem would be for the third-party service to run its own PDS, once you allow federation on the production network, correct?

If I run my own PDS, can I configure the rate limits any way I wish?

[bnewbold]

Yes, a service provider running their own PDS could give them more control over some basic operation limits today, but only for accounts hosted on that instance.

[bnewbold]

This is a big important question that we care a lot about. The economics of the network matter in the long run, and they also matter now in the early days as things grow. We want to balance permissive access to allow experimentation and growth, but want to be careful about setting expectations, keeping things sustainable, and not "pull the rug" by slashing free limits in the future.

I'll also say up front that this is a complex issue, with a lot of different kinds of developers using our APIs for different reasons. We've got alternative clients, mobile-apps apps, web SPA apps, backend apps, analytics services, self-hosters, hobbyists, researchers, moderators, small businesses, bulk-delete tools, startups, large corporations, publishers, investigative journalists, content-creators, etc. When we talk in public we are talking to all those folks at once, and they have different priorities and concerns.

The big worst-case hedge is that each component of the network can be self-hosted by other parties. If they don't like our limits or policies, they can individually or collectively run parallel infrastructure. Even if we provide huge API quotas, many folks will probably want to self-host for latency, performance, reliability, technology stack, or other reasons.

For the specific situation of "providing services or automation on behalf of a user", we can take a look at relaxing per-IP rate-limits for most authenticated API calls, because (as you mention) we can partially get away with using per-account limits. Of course, then spammers will evade per-account limits by simply creating lots of accounts; there is no silver bullet here.

We are also working on OAuth (https://github.com/bluesky-social/proposals/tree/main/0004-oauth), which will open up a lot of flexibility around identifying specific clients/integrations and letting operators (like us) measure usage and set different limits per integration.

For some use cases, the public AppView API (public.api.bsky.app) has larger limits and/or better performance (it has lots of caching). This works for un-authed app.bsky.* endpoints like getAuthorFeed or getProfile, but not things like creating posts.

If you (or any other developer) have concerns about specific project or business ideas and want to chat, we are happy to talk through the details. Talking about specific API endpoints, timelines, and estimated calls-per-day-per-user and aggregate calls-per-second can really help clarify the conversation. Happy to do this privately or publicly.

[gnito-org]

Thank you for your thoughtful reply and information.

In terms of running one's own PDS, that would be my preferred approach. I've been using Twitter's API since the very early days when Alex Payne was the lone warrior hacking it together. Once burned by Twitter's growing hostility towards developers, twice shy.

Are you planning on making the implementation more flexible so that one can:

• Store the PDS DB on an external PostgreSQL or MySQL database,
• Locate the PDS Blobstore on external storage such as Amazon S3,
• Point a caching server to an external Redis server,
• Run the PDS behind an ELB load balancer, which implies multiple PDS instances serving requests to the same DB,
• Adjust individual rate limits, and
• Bypass rate limits with a special request header?

If these capabilities are already implemented, would you be so kind to document how to enable them?

As you know, Amazon EC2 instances periodically go bad or are taken out of a commission. Storing any persistent data on the instance is a no-no.

[bnewbold]

there was a version of the PDS which had many of those features, but we have moved to having single sqlite files per account (plus at least one larger instance-wide sqlite file). we use a tool similar to litestream for continuous backups to an S3-compatible storage system. in an AWS context you could use EBS to allow EC2 instances to be replaced and have the data persist. in this setup using a load-balancer doesn't help much. we do use redis for caching.

the rate-limits can be adjusted in code, and there is a rate-limit bypass mechanism using an HTTP header.

not all of this is well documented yet, but will get a bit more attention as we start to open up to federation.

furthermore, we are optimistic that other folks will build compatible PDS implementations using different techniques and programming languages. we have intentionally made the PDS simpler. I would be surprised if there are not implementations in golang, rust, python, or other languages, and using datastores like PostgreSQL or MySQL in a few months.

[CrispStrobe]

@emilyliu7321 did you make recently some changes? for i am encountering "ratelimit-limit": "100", "ratelimit-policy": "100;w=86400", which would be radically strict.