Detecting spaces support

Working Groups WG Private Data
1

I’ve been working on a system in HappyView to automatically migrate a user’s spaces data from HappyView to their PDS if I can detect that their PDS supports spaces.

It’s really hard. :sweat_smile:

describeServer is the first place I checked, but it hasn’t changed in the alpha to indicate support for spaces. The DID document entries for spaces are optional with fallbacks, so we can check for them but their absence doesn’t prove anything.

My current solution

This is what I’ve landed on so far, but I’m looking for feedback. Right now, detection is two tiers. First, I check community.lexicon.service.describe. If the server answers it, I treat the method list as authoritative. The presence of spaces XRPCs is a definitive indicator that spaces are supported by the PDS.

The second tier is required because the reference alpha PDS doesn’t implement community.lexicon.service.describe. Since it’s by far the most common PDS implementation and, thus, the primary target, I fall back to some unreliable status code-based detection:

Request What the reference PDS says
community.lexicon.service.describe 400, not implemented, and notably not a 404
com.atproto.space.listSpaces with no auth 401 AuthMissing, route present
com.atproto.space.<nonexistent> 400 InvalidRequest, route absent
com.atproto.simplespace.getSpace with no auth 400, route present, rejecting missing params

A missing route and a present-but-unparameterised route both return 400, but an auth-gated method returns 401. The logic is:

  • If we receive the same status code for everything (say all 4 requests return 405), we can’t reliably determine spaces support so we assume it isn’t there.
  • If we get the expected status codes from each route, we can be reasonably confident that 1) this is a reference PDS, and 2) it has spaces support.

It’s still a problem

This method is, to say the least, unreliable. Somebody could be running the reference PDS between a reverse proxy that converts all error responses to 418 just for the memes, meaning the it may support spaces but HV would assume it doesn’t. A non-reference PDS may return the same status codes but have a broken implementation. It’s a minefield.

Since my survey of the ecosystem shows that it’s safe for now, I’m shipping this detection system today, but I’m hoping there’s a better way. IMHO the ideal would be for the ref PDS to implement community.lexicon.service.describe. Thoughts?

5 Likes
2

+1 for putting community.lexicon.service.describe support in the reference PDS impl, and if that’s not an available course of action, updating com.atproto.server.describeServer for spaces.

2 Likes
3

We’ll need to think harder before implementing something like community.lexicon.service.describe on the Bluesky PDS distribution as it’d probably become something of an implicit standard at that point.

In the mean time & to unblock things, how about just adding a spacesAlpha boolean to the com.atproto.server.describeServer output? (I might not even put it in the lexicon)

One step further could be experimentalFeatures: ["spaces-alpha"]

Let the PDS advertise the account management page
4

Considering the Bluesky PDS is in the minority of PDS implementations that don’t implement community.lexicon.service.describe, I’d say the lexicon has already become an implicit standard.

Adding a spacesAlpha boolean or an experimentalFeatures array to describeServer certainly works but, like you said, anything added to the reference PDS becomes implicit standard. That ends up being the same as implementing community.lexicon.service.describe.

I’d wager it’s better to take the time to sort the standard solution for this, rather than jam something in. Besides, I don’t know that anything is blocked right now. I’ve got a hacky solution above that’s working, so we can just roll with that until we have a better idea of how to handle it moving forward.

2 Likes
5

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).

2 Likes
6

IRC prefixes new features with draft- as to distinguish them from the fully ratified form which may have breaking changes from the draft implementation. This is done on live networks, and in my opinion works quite well.

3 Likes
7

@dholms.xyz @bnewbold.net Have y’all thought anymore about this? I’m closing in on releasing HappyView v3 in the next ~2 weeks, and having a reliable way to detect spaces support would be a huge boon.

8

Hey thanks for following up!

Yeah it definitely is a bandaid. But I think doing more than that has the potential to become load-bearing before we’ve had time to give it proper thought.

I’ll ship the spacesAlpha boolean on describeServer next Thursday. That’ll unblock you & other alpha builders. And we can continue wrestling with how/if we want to do feature discovery more generally :+1:

4 Likes