#ActivityPub developers only: do you implement rate limit support in your HTTP client implementation?
-
@julian Mastodon sets some pretty strict limits on requests -- what do you do when you get 429 errors?
-
@julian Mastodon sets some pretty strict limits on requests -- what do you do when you get 429 errors?
@evan@cosocial.ca if I've been hit by them I've never noticed. It could be that the nature of conversations on the fediverse usually mean NodeBB reaches out to many servers, but the only software I've ever had a problem with is Discourse. It blocks me after 15 requests.
mcc has a toot thread in the hundreds, and when NodeBB discovered it it backfilled the entire thing.
When it hits a 429 NodeBB should probably retry after a cooldown period, but it doesn't at the moment. It just marks it as failed.
-
#ActivityPub developers only: do you implement rate limit support in your HTTP client implementation?
Yes but, so far it's a filed issue, not the actual code.
-
Voted "No, but.." against backdrop of #ActivityPub API task force, where issue tracker has an issue on rate limits.
From perspective of "avoiding misconceptions" I was wondering about a range of issues that have been created, and how they relate to Protocol versus Solution design. See also: https://github.com/swicg/activitypub-api/issues/63
I think it may be valuable to define different stakeholder roles, to track people's needs. For #Protosocial thus far I discern in order of importance:
1. Solution developer
2. Protosocial implementer
3. Protocol designerWhen asking the question "Should rate limits be part of the protocol?", starting point for design is a firm No.
Solution devs should not be worried about them. Need for rate limits depends on requirements of individual Protosocial impls, and what their goals are.
Protocol-level there's actor introspection. There are no "instances" but Application actors that host Services, including system services, that may expose Rate Limit as metadata.
-
Voted "No, but.." against backdrop of #ActivityPub API task force, where issue tracker has an issue on rate limits.
From perspective of "avoiding misconceptions" I was wondering about a range of issues that have been created, and how they relate to Protocol versus Solution design. See also: https://github.com/swicg/activitypub-api/issues/63
I think it may be valuable to define different stakeholder roles, to track people's needs. For #Protosocial thus far I discern in order of importance:
1. Solution developer
2. Protosocial implementer
3. Protocol designerWhen asking the question "Should rate limits be part of the protocol?", starting point for design is a firm No.
Solution devs should not be worried about them. Need for rate limits depends on requirements of individual Protosocial impls, and what their goals are.
Protocol-level there's actor introspection. There are no "instances" but Application actors that host Services, including system services, that may expose Rate Limit as metadata.
I cross-referenced the poll and my reply to the Rate Limit issue in the tracker..
Rate limiting · Issue #4 · swicg/activitypub-api
"As an ActivityPub client developer, I want a reliable and standard way to discover rate limits in an ActivityPub API server, so I can avoid unexpected failures for my users."
GitHub (github.com)
-
#ActivityPub developers only: do you implement rate limit support in your HTTP client implementation?
@Evan Prodromou
Necessary via hubzilla/streams/forte? -
@Evan Prodromou
Necessary via hubzilla/streams/forte?@citc what?
-
R relay@relay.mycrowd.ca shared this topic
-
Voted "No, but.." against backdrop of #ActivityPub API task force, where issue tracker has an issue on rate limits.
From perspective of "avoiding misconceptions" I was wondering about a range of issues that have been created, and how they relate to Protocol versus Solution design. See also: https://github.com/swicg/activitypub-api/issues/63
I think it may be valuable to define different stakeholder roles, to track people's needs. For #Protosocial thus far I discern in order of importance:
1. Solution developer
2. Protosocial implementer
3. Protocol designerWhen asking the question "Should rate limits be part of the protocol?", starting point for design is a firm No.
Solution devs should not be worried about them. Need for rate limits depends on requirements of individual Protosocial impls, and what their goals are.
Protocol-level there's actor introspection. There are no "instances" but Application actors that host Services, including system services, that may expose Rate Limit as metadata.
@smallcircles @julian I disagree!
Rate limits are a common part of APIs. For apps to work across servers, the servers need to provide about the same interface.
Using standard rate-limiting headers lets client apps detect what rate limits they will be held to. It reduces the uncertainty.
Fortunately, there is a well known de facto standard and an even better IETF standard coming up. We should point them out.
-
@smallcircles @julian I disagree!
Rate limits are a common part of APIs. For apps to work across servers, the servers need to provide about the same interface.
Using standard rate-limiting headers lets client apps detect what rate limits they will be held to. It reduces the uncertainty.
Fortunately, there is a well known de facto standard and an even better IETF standard coming up. We should point them out.
@evan@cosocial.ca please do, I am unaware of any standard rate limiting headers...
-
> Rate limits are a common part of APIs.
Yes, of API *implementations*, and they may become part of the public interface of these implementation. Whether they should be part of an open standard protocol specification is a different matter imho. Perhaps in a separate implementation guide, suggesting recommended practices.
Or perhaps there may be some way to formulate a generic mechanism in the protocol specification that makes rate limits an extension point, without pinning to a particular method, esp. if it is only a de facto standard.
(Other example. The fediverse is still pinned to an expired draft of HTTP signatures.)
OTOH if the goal of the task force is to mostly just provide implementation guidance, and maybe a reference impl, then I guess examples of rate limiting may be provided.
-
> Rate limits are a common part of APIs.
Yes, of API *implementations*, and they may become part of the public interface of these implementation. Whether they should be part of an open standard protocol specification is a different matter imho. Perhaps in a separate implementation guide, suggesting recommended practices.
Or perhaps there may be some way to formulate a generic mechanism in the protocol specification that makes rate limits an extension point, without pinning to a particular method, esp. if it is only a de facto standard.
(Other example. The fediverse is still pinned to an expired draft of HTTP signatures.)
OTOH if the goal of the task force is to mostly just provide implementation guidance, and maybe a reference impl, then I guess examples of rate limiting may be provided.
For example as far as I am aware XMPP does not dictate how to deal with rate limits, though there's an optional non-final XEP on stream size (which is different). However, Prosody IM does implement rate limiting, explain the confi in their docs.
CloudEvents also says nothing about rate limits. But it has a guideline on how to implement Webhooks with HTTP + Websockets. It specifies that 429 Too Many Requests is returned, plus a Retry-After http header. This spec also mentions:
> This specification aims to provide such a
definition for use with CNCF CloudEvents, but is considered generally
usable beyond the scope of CloudEvents.What is nice wrt CloudEvents is how the protocol spec clearly distinguishes various extension points:
- adapters
- bindings
- formats
- extensions -
For example as far as I am aware XMPP does not dictate how to deal with rate limits, though there's an optional non-final XEP on stream size (which is different). However, Prosody IM does implement rate limiting, explain the confi in their docs.
CloudEvents also says nothing about rate limits. But it has a guideline on how to implement Webhooks with HTTP + Websockets. It specifies that 429 Too Many Requests is returned, plus a Retry-After http header. This spec also mentions:
> This specification aims to provide such a
definition for use with CNCF CloudEvents, but is considered generally
usable beyond the scope of CloudEvents.What is nice wrt CloudEvents is how the protocol spec clearly distinguishes various extension points:
- adapters
- bindings
- formats
- extensions@smallcircles @julian the point of the API task force is to make using the API across servers possible. That's why we're doing the OAuth work. I think rate limiting is part of the basic profile; it's one of the things you need to support to use the API across different servers.
-
@smallcircles @julian the point of the API task force is to make using the API across servers possible. That's why we're doing the OAuth work. I think rate limiting is part of the basic profile; it's one of the things you need to support to use the API across different servers.
For OAuth it is also questionable the extent to which its use should be dictated. For instance in CloudEvents "modeling the security layer" is only facilitated by the protocol spec, another extensibility point.
-
@smallcircles @julian I think we might have different ideas about what the ActivityPub API task force is for.
To me, it's about making it possible for clients to use different servers, and different implementations of the API. That's going to include the social API defined in the ActivityPub standard, but it will also encompass things like rate limits, authentication, caching, CORS, and so on.
How that all gets documented will probably be in one or more community group reports.
-
@smallcircles @julian I think we might have different ideas about what the ActivityPub API task force is for.
To me, it's about making it possible for clients to use different servers, and different implementations of the API. That's going to include the social API defined in the ActivityPub standard, but it will also encompass things like rate limits, authentication, caching, CORS, and so on.
How that all gets documented will probably be in one or more community group reports.
The extent to which the default profile becomes a 'straightjacket' impact scope, applicability, and usability. I guess its alright as long as there's sufficient flexibility and extensibility taken into account. Guess the "sufficient" does the heavy lifting here.
-
@julian There are 3 main clusters.
They're linked here for the ActivityPub API task force, but they also apply for the federation protocol:
Rate limiting · Issue #4 · swicg/activitypub-api
"As an ActivityPub client developer, I want a reliable and standard way to discover rate limits in an ActivityPub API server, so I can avoid unexpected failures for my users."
GitHub (github.com)
-
@julian There are 3 main clusters.
They're linked here for the ActivityPub API task force, but they also apply for the federation protocol:
Rate limiting · Issue #4 · swicg/activitypub-api
"As an ActivityPub client developer, I want a reliable and standard way to discover rate limits in an ActivityPub API server, so I can avoid unexpected failures for my users."
GitHub (github.com)
@julian The first is the most standard, `Retry-After`. You get it mostly on `429 Too Many Requests` responses, as a way to tell you when you're next allowed to make a request. Unfortunately, by the time you get it, you're already in the penalty box. It's better to get information on the request quota *before* you get locked out, so you can throttle your requests and avoid getting locked out.
-
@julian The first is the most standard, `Retry-After`. You get it mostly on `429 Too Many Requests` responses, as a way to tell you when you're next allowed to make a request. Unfortunately, by the time you get it, you're already in the penalty box. It's better to get information on the request quota *before* you get locked out, so you can throttle your requests and avoid getting locked out.
@julian The second cluster is a de facto standard used for a lot of APIs, with a lot of incompatible variations. The most common pattern is:
X-RateLimit-Remaining: integer, how many requests left in your quota
X-RateLimit-Reset: timestamp, when your quota will reset to full -
@julian The second cluster is a de facto standard used for a lot of APIs, with a lot of incompatible variations. The most common pattern is:
X-RateLimit-Remaining: integer, how many requests left in your quota
X-RateLimit-Reset: timestamp, when your quota will reset to fullSo, if the rate limit is 300 requests every 5 minutes, and you've already used 143 requests, you might see headers like this:
X-RateLimit-Remaining: 157
X-RateLimit-Reset: 2026-03-22T22:10:00Z -
So, if the rate limit is 300 requests every 5 minutes, and you've already used 143 requests, you might see headers like this:
X-RateLimit-Remaining: 157
X-RateLimit-Reset: 2026-03-22T22:10:00Z@julian Unfortunately, there are a ton of conflicting variations on this pattern. Some APIs use a Unix timestamp for the reset datetime (!), others use HTTP header values. Mastodon uses an ISO 8601 datetime.
The X-RateLimit-* headers also don't work well if there are multiple quota policies. That can happen if there are particular types of requests that are under a stricter quota than others. There are some variants that APIs use, but they're specific to the platform.
