mirrors/tranquil-pds
1
0
Fork 0
mirror of https://tangled.org/tranquil.farm/tranquil-pds synced 2026-09-04 01:06:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(docs): migration oauth update

Browse Source 
Lewis: May this revision serve well! <lu5a@proton.me>
This commit is contained in:
Lewis
2026-05-25 19:02:13 +03:00
committed by Tangled
parent 96c8375706
commit e6eee18ace
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/1_WELCOME_TO_TRANQUIL_PDS.md
+1 -1
View File
@@ -63,4 +63,4 @@ So you want to migrate your account from a different PDS to Tranquil? The UI of
The good thing about migrations is that for most of the rickety process, the real identity of your account hasn't actually moved, it's most of the unimportant data copied over (ie. everything but switching over your keys to say "hey this account is hosted on this specific PDS instance and not any other one"). So if something goes wrong in our migrator or any other, feel free to dip into a bit of Tranquil PDS admin and delete out the half-formed account ~~fetus~~ (sorry).
One thing that **tends to not go smoothly in our own migrator** right now is **session token refresh** -> it's surprisingly hard for me to figure out how to best refresh an OAuth token for an account that's not even technically really created yet, and if you wait too long in the browser during the migration then sometimes it seems to just start erroring out because of a dead session token. This is a really bad UX! I will fix this in the near future unless someone else fixes it first. I have successfully been on the line with an oomf migrating who had this happen, and we actually forced a token refresh via the browser console - so there's that if you don't want to start again after deleting the half-made account.
One thing that **tends to not go smoothly in our own migrator** right now is **deactivation on source PDS** -> since we use OAuth for our migrator, and the reference PDS disallows using OAuth to deactivate an account at time of writing, that part of the migration will fail - which is fine, a migration doesn't *need* the source account to be deactivated - but the Bluesky AppView for example definitely likes events to come in an exact order for it to update nicely. I have gotten around its multi-hour auth cache by manually cURLing login + deactivate endpoint in terminal to the source PDS, and then doing a no-op handle update API call on the newly migrated target PDS. Like a bit of a defribulation on the firehose such that the Bluesky AppView really does in fact pick up on the move instead of just screaming about jwt issuers for a couple of hours.