Our Personal Data Server from scratch! tranquil.farm
pds rust database fun oauth atproto

Bug: Migration flow instructs to deactivate Bluesky account #672

Open tynanpurdy.com
Open opened by tynanpurdy.com

The user-facing copy at the end of a migration says to make sure that your "Bluesky" account is deactivated, even if the account migrated from a non-bsky PDS. This is probably leftover from when that was the main feasible migration pattern. Now there are regularly folks migrating between any two independent PDS hosts.

I propose this get updated. The migration flow is obviously aware of the origin PDS, so the hostname of that PDS should be used in the copy instead of assuming "Bluesky".

On an unrelated note, I hope that the old account can be deactivated automatically soon, or that this screen could provide more useful direction as to how the user should do so.

nel.pet

on the last note. the only reason we dont deactivate the old account automatically is because ref impl doesnt allow doing that with an oauth session for ... reasons that are beyond us. the wording should be changed though agreed

From my conversations with them, it's a combination of haven't gotten around to implementing that endpoint and potentially wanting to reserve some dangerous account actions for password-only. I think the risks of giving access to deactivation endpoints over oauth can be mitigated in UI screen (put a big warning on that scope in the consent screen). There is currently no issue so I will write one quickly.

Sign up or Sign in to add to the discussion.