Rate Limits and ApplyWrites

[mm14kwn]

I'm attempting to programatically block a large number of users on bluesky, and am running into problems with rate limits creating records. Pushing each block individually with create_record I hit the 1666/hour or 16666/day limit, which is understandable, so I then attempted to batch create the records with apply_writes - thinking this would be able to just update my blocks in one chunk rather than overloading things with multiple requests. However this method limits me to 200 blocks per request and then runs into the same rate limit, meaning I can do 6 writes of 200 = 1200 per hour and then have to wait a further hour. Is there a more efficient/larger scale way to implement this or am I stuck either hammering a single create_record every 7 seconds or six apply_writes per hour for the next few months?

[bnewbold]

Can you describe your use-case more, and why creating so many block records would be a reasonable way to go about it?

The rate-limits exist for good reasons: repositories are not designed to store unlimited numbers of records, and graph interactions like blocks can consume resources in unexpected ways (for instance, blocks might be cached in-memory, and RAM is expensive).

[mm14kwn]

Hi,
The use-case/reasoning is very simple - unlike literally every other social media platform, bluesky/atproto refuses to provide any form of basic safety features when it comes to user privacy aside from the block function - so if a user (such as myself) wants a private account on the service the only currently feasible way I can see to achieve this is to block all users except a whitelist of trusted accounts.

There are currently 5.2 million users on the service, this does not seem like a particularly large commit of records to my account, the platform is happy to serve me up the list of all 5mil of these IDs as an API call. Once these existing users are blocked the commits become considerably less frequent, as all I need to do is monitor the firehose for account creation events and then block at that point.

[mm14kwn]

Alternatively, these accounts could be added to a list, which could then be blocked by multiple accounts - bluesky clearly has the functionality to handle large lists and also blocking large numbers of accounts, as you can subscribe to block lists and block all members immediately - and there are other users with block numbers nearly into the millions.

[bnewbold]

The ability to enumerate a large number of DIDs does not mean that a large number of block relationships can be maintained. The system is not designed to support liking, following, muting, or any other graph relation with a large fraction of the entire network.

While your idea is conceptually interesting, we simply aren't going to support it at this time, and there is a good chance your account will be suspended if you continue.

If the current fully public model does not work for you, I would recommend finding a different system to work with until there is a way to do group-private interactions with the protocol itself.

[mm14kwn]

Thanks for the reply. Unfortunately I feel like you are going to find more and more people attempting solutions like this given the refusal to implement basic safety features like private accounts/audience controls - every other social media platform had them and it's something bluesky/atproto is severely lacking.

With that aside, can you advise on the fraction that will trigger suspension etc? There's nothing in the code of conduct about blocks, only about posting spam. I'll note that there is an active account with considerably more blocks than I've managed - presumably who got started before the rate limits came down. If I have a number I need to stay under, I'll consider other options such as focusing the blocks to recent/active users at least, or some kind of branching graph to more effectively catch people who might feasibly see my posts/be tempted to interact.

[mm14kwn]

Alternatively, could you advise if federating/self-hosting a PDS is a possible way to avoid these restrictions imposed by the bluesky team? For example if I self hosted my own pds, applied the block relations to my record there, then federated to interface with the Bsky relay, would I be able to interact with the 200 or so actual accounts I care about on the service?