Following up on @bnewbold.net’s comment over in the community.lexicon.service.describe thread:
I wanted to make sure it was clear that I’m not demanding the implementation of community.lexicon.service.describe. My goal with this conversation was to find a solution that allows services to detect support for functionality.
If my reading of the com.atproto.server.describeServer lexicon’s description is correct, it seem like an ideal place for this information:
Describes the server’s account creation requirements and capabilities.
Which I’m reading as…
Describes the server’s account creation requirements AND describes the server’s capabilities.
…but maybe that’s not the intent.
Adding spacesAlpha to the com.atproto.server.describeServer schema seems like a band-aid solution to a challenge I expect we’ll run into again as we build more functionality that requires coordination across core atproto infrastructure.
I think a better long-term solution would be to update describeServer to be more generically expandable, allowing servers to define new functionality without requiring an update to the core com.atproto.* lexicons. For example, an additionalFeatures string array could look like this:
{
"properties": {
"inviteCodeRequired": {},
"additionalFeatures": {
"type": "array",
"description": "A list of features supported by this server.",
"items": {
"type": "string",
"knownValues": [
"inviteCodes",
"emailVerification",
"phoneVerification",
"blobUploads",
"spaces",
"ssoGoogle",
"ssoGithub",
"ssoApple",
"ssoDiscord"
]
}
}
}
}
Example usage:
{
"inviteCodeRequired": true,
"additionalFeatures": [
"spaces",
"ssoGoogle",
"ssoGithub",
"ssoApple",
"ssoDiscord"
]
}
A open string array also makes it easy for servers to advertise functionality not covered by the core spec (e.g. Tranquil PDS could advertise the SSO items I added above, or the Northsky PDS could advertise Stratos functionality).