`pdsadmin/account.sh create` requires bio edit for functioning account, but this is not documented

[mcclure]

The pdsadmin/account.sh create script appears to create accounts which always appear as "⚠️Invalid Handle ⚠️Invalid Handle" until you edit the profile and change the display name or bio. This is neither documented nor indicated by the account.sh tool.

I am mostly certain about this, I have seen it once in informal use and once in a controlled test I did this afternoon. Here are the steps I performed:

Repro

I have a functioning PDS server bsky.example.com. On the server, I run pdsadmin/account.sh. I give it email address admin+temporary3@example.com and handle temporary3.bsky.example.com. It gives me DID did:plc:ei24m7la7nsl656y3hmnideo and a password.

Next I go to my DNS configuration and I add a TXT record containing "did=did:plc:ei24m7la7nsl656y3hmnideo" to subdomain _atproto.temporary3.bsky. I use https://bsky-debug.app/handle?handle=temporary3.bsky.example.com to verify it's correct (it is).

In an incognito Firefox window, I go to bsky.app and click "log in". I select "custom server" bsky.example.com. I log in as temporary3.bsky.example.com. It lets me log in. I verify with https://plc.directory/did:plc:ei24m7la7nsl656y3hmnideo that my plc is registered correctly. It is.

I click "Profile". I see the screenshot above. I reload several times over several minutes. It continues saying this. I click "Edit Profile" and enter a display name and bio. Immediately it now shows my display name and handle.

Note: "example.com" is of course not my domain, you can see my real domain if you click plc.directory. (Although after running this test I tested changing usernames, so the username you will find on plc.directory is no longer "temporary3".) I have a log of everything journalctl printed during this test.

Expected behavior

Ideally, whatever step is necessary for a handle and username to be not "invalid" should be performed by the account.sh create step. But if this is inconvenient, or if changing the display name is really a required step for whatever reason, then the documentation (help.sh) should print that to make the plc usable you need to log in and change the displayname/bio once (or whatever the magic step is); and in my opinion account.sh create should also print this when it succeeds in creating an account.

Impact

In my testing, I find many different errors in PDS setup can result in a newly created account appearing as "⚠️Invalid Handle". However, in the case above, "⚠️Invalid Handle" is shown even though the PDS is fine. Since the documentation does not give adequate guidance about this final nonobvious step, someone setting up a new PDS would be misled to believe their PDS is misconfigured even once it actually is working.

[bnewbold]

Thanks for this detailed bug report! I'm going to dig in to the details below, partially as additional documentation of this issue for myself.

If I recall correctly, the root cause of this issue is that the AppView is serving this API route (the profile view, including account metadata like handle), and in some situations the AppView doesn't know about the account yet, and that results in this bad and confusing experience.

One hack-y way to fix this is to send out pretty much any event for the account on the PDS repo event stream (firehose). This could be a profile edit (profile record results in commit event), posting, I think even liking or following might do it (all record creation and commit events). I can't remember if changing handle does it.

IIRC, in our app we added a sort of hack during account sign-up to create an empty profile record during onboarding to result in an event, which helps prime the pump for downstream services. I think our search service still requires some profile record (even an empty one) or it won't index the account.

One of the big-picture ways we want to fix this is have more helpful events go out on the repo event stream (firehose). The current #identity event in theory should go out for the new DID / new handle, but I think doesn't. We are also planning for an #account event which indicates the PDS-location aspect of identity (and things like account deletion without identity deletion).

A related big-picture question is what the bsky AppView should do with atproto accounts which are never active (or interested in) the app.bsky.* application (aka, "Bluesky Social" the microblogging app). This is analogous to a system that supports both blogging and photo sharing: if you never share photos should there be an empty profile on photo sharing side of things? Or just "not found"?

Both of those are kind of academic and not related to this specific flow/experience though. At this point in time I think the right thing is that the account should not look broken when going through the setup process as you did. Probably the easiest "fix" is for us to have the account.sh script (or the PDS itself) create an empty profile record, or send out some extra event (a redundant #identity event?) when the account is created.

[mcclure]

A related big-picture question is what the bsky AppView should do with atproto accounts which are never active (or interested in) the app.bsky.* application (aka, "Bluesky Social" the microblogging app).

Well, one option would be to have the act of logging in to bsky.app trigger some sort of vacuous event (maybe conditionally doing this only if bsky.app realizes the logged-in account is in this broken "empty" state). It wouldn't be surprising to me if an account that had never interacted with bsky.app in any way showed an error message when you tried to look at the profile…! Whereas logging into bsky.app, looking at your own profile, and seeing an error, does not inspire confidence that the login was successful and more complicated tasks like posting will work (esp because in the self-host case it is easy to get into misconfigured states where operations like following and posting fail silently).

Probably the easiest "fix" is for us to have the account.sh script (or the PDS itself) create an empty profile record, or send out some extra event (a redundant #identity event?) when the account is created.

But this would work too.