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