Assign a custom domain at signup that is not tied to the PDS

[kristojorg]

I would like to offer users of my custom app the ability to have a custom domain handle during sign up. I don't want this handle to be tied to their PDS. For the time being, assume they are using the bsky.social pds. However, I want them to be able to have a handle at a different domain by default. Is this possible? Passing a non bsky.social handle to com.atproto.server.createAccount causes a 403 error. Is there some other API I am missing to instantiate a DID? How does createAccount instantiate the did and the associated dns record on the PDS?

[DavidBuchanan314]

I believe you'd need to create the DID "manually" (i.e. using the plc.directory APIs https://github.com/did-method-plc/did-method-plc), set up the DNS correspondingly, and then go through the "inbound" half of the account migration flow https://github.com/bluesky-social/pds/blob/main/ACCOUNT_MIGRATION.md

(I'm not sure if this is the simplest/recommended method, but it should work at least)

[yamarten]

The easiest way is to first create an account with a random handle and then change the handle immediately.

If you want to avoid it, you can use the custom handle from the beginning in the following steps. ( The intention is the same as the answer of @DavidBuchanan314)

1. Create a pair of DID and handle (for example, in the case of did:plc, use CreatePlcOp). There is no need to fill service of the DID document with the appropriate value.
2. Create a jwt. Please refer to createServiceJwt and did:web accounts seem to be impossible to create right now #2100. The DID of PDS can be obtained in describeServer.
3. Call createAccount using the prepared DID, handle and jwt.
4. Update the DID document with the value obtained by getRecommendedDidCredentials. You can use CreatePlcOp or submitPlcOperation.
5. Start using your account with activateAccount.

I have never performed this procedure, so there may be an error.

4 can only be executed by those who have control of the domain, so we can't expect the appearance of an API that automatically performs all of this procedure.

[bnewbold]

Pragmatically, I would recommend @yamarten's answer of creating the account with a random handle (maybe prefixed with your app name?) and then immediately doing a change-handle operation.

Note that we don't currently support migrating accounts in to the Bluesky PDS service, only out of that service.

Part of the complexity here is that DIDs and handles are registered "together", and are supposed to be bi-directional validating. The Bluesky PDS service has no control over any external handles (DNS or domains), so it can't automatically create a DID PLC and update the handle to point at it at the same time. This will be true of any PDS instance. We will probably make it possible to create a DID with an invalid handle at the time of account creation, though this causes some friction (resolution errors/warnings) for the entire downstream ecosystem.

Philosophically, PDS hosting is intended to be distinct from application hosting, and handles are part of PDS hosting. This is kind of confusing in the case of Bluesky because we both run a PDS host and an application. The *.bsky.social handles are intended to be somewhat distinct from our client and the "Bluesky Social microblogging app", but that isn't really clear or possible to distinguish because we run both.

[kristojorg]

Philosophically, PDS hosting is intended to be distinct from application hosting, and handles are part of PDS hosting.

I'm not totally tracking how handles are part of PDS hosting, since handles are also part of verification and it is currently possible to have a handle at a different domain than the PDS host... it's just not possible during account creation. It seems like handles are part of a third thing (DNS) distinct from PDS or applications.

We will probably make it possible to create a DID with an invalid handle at the time of account creation, though this causes some friction (resolution errors/warnings) for the entire downstream ecosystem

To resolve the errors, could an update be made to allow plain DIDs as handles such that someone can be "handleless" for a time?

For now, I will use @yamarten's approach - thanks for that!