Some changes occurring to account creation that client devs need to be aware of

[pfrazee]

Hey all, need to catch you up on some changes we're deploying to account creation that can affect clients that support it.

I'll start by saying that these changes are considered temporary because the main effort underway is to move to an OAuth flow for account creation and signin. Our expectation is that the OAuth flows will involve opening webpages hosted by the PDSes to complete signup/signin. This means clients won't be tasked with implementing specific signup behaviors anymore. That is why these updates are considered temporary; we expect all of this to move outside of the account-creation lexicons. If that proves untrue, we'll stabilize these updates.

The two changes are:

• SMS verification
• Account-activation queueing

You can look at those PRs to see how each of them work, but I'll give a brief overview of the details.

For SMS verification, you make a call to com.atproto.temp.requestPhoneVerification() to get the code sent. You then include verificationPhone -- the phone number -- and verificationCode -- the texted code -- in createAccount(). You only need to do this if the server includes phoneVerificationRequired: true in its response to com.atproto.server.describeServer().

For account-activation queuing, there was a scope added to the access JWT named com.atproto.deactivated. (There was a typo in the backend that had com.atproto.deactived but ignore that, we're fixing it before deploy.) If the access-token has that scope, the user has been put in a queue due to an influx of new users. The access-token is only able to access com.atproto.temp.checkSignupQueue(), which gives information about their position in the queue. Once that method returns activated: true, you can refresh the session to get a new access token and the account will function normally.

[puellavulnerata]

Choosing to betray user privacy by requiring an index into surveillance systems such as SMS authentication is absolutely shameful