Extend describeServer

[kjarex]

Is your feature request related to a problem? Please describe.

Somewhat of a problem. There exist a few limitations on a PDS, like max blob size for example, which I assume are not limitations by the protocol but limitations individual to a pds. Those limits would be useful to know for a client. Right now, the only information which a client can receive without just running into an error, is whether a PDS requires an invitation in order to register a new account.

Describe the solution you'd like

I would like that describeServer gets a standard to describe a PDS' limits/rules if the PDS wishes to do so (=optional), as it benefits both, the client and the server, for the limits to be known before a relevant request is made and possibly fails. Ideally a client can avoid any unsuccessful attempts if it parsed any available information it receives from describeServer. Rate limits, even though they should be known to a client usually before they ran into them by earlier requests, should be included as well, so such information is already known to a client, and potential user, before they even necessarily create an account on a server (in order to decide if they want to create an account on that server). Same goes for non boolean or numeric values, like allowed file types/ formats, for example. As there are too many options to have them all hardcoded, I would think instead of defining those options directly, there should be a standard to how to describe those rules universally.

Describe alternatives you've considered

Leaving it as it is - but this means there might be unnecessary account creation, migration, and failed requests, which could have been avoided in the first place.

[bnewbold]

Thanks for your proposal! I think the issues you are raising are real.

I think that many of the examples you give are application-specific and should be specified in application Lexicons, and don't need to be returned via describeServer. For example, blob sizes and mimetype patterns can be specified in a Lexicon. These constraints impact primarily the client-app and the app-view, and to some degree the PDS. Application Lexicons also have their own built-in governance authority (based on the NSID of the Lexicon).

For rate-limits, I think the current norm (which isn't very well documented/specified) of using HTTP headers works well, because it is generic to the HTTP protocol layer, not the atproto protocol layer. Rate limiting is also notoriously something that is hard to provide stable long-term public documentation on: what is and isn't "expensive" changes over time, and different implementation details make sense at different scales of operation. I think it would be quite difficult to standardize how rate-limits will work throughout the entire atproto ecosystem in a way that will remain compatible and interoperable for many years. Also, some rate-limits will be specific to a PDS, and some to an AppView, so there will be a complex blend to communicate.

[kjarex]

As far as I understand it, this would mostly contradict the discussion/answer at #1139 wouldn't it?

[bnewbold]

I don't see a major contradiction between my comment and the other discussion/answer. Things like "maximum image size for use in app.bsky.feed.post" are application-specific and specified in an existing Lexicon, and should work on every PDS instance.

In theory there might be a generic/fallback maximum limit on blob sizes, and different PDS implementations or instances might define that differently. But except in corner cases Lexicons should pretty much always specific a maximum blob size, and keep that maximum reasonable, to ensure interoperation.

A different issue is limits on things like "total number of records or size (bytes) in an atproto repository" or "sum size of all blobs". These might be PDS instance specific, and even change over time or be something that folks pay for. For that kind of limit, there might not be a single limit for all accounts on the instance though. It might make sense to have an endpoint that shows current resources used and (optionally) a quota maximum, for a specific account (DID). Just brainstorming, we don't have a plan/proposal for this yet.