Bluesky: handle federated PDSes

[snarfed]

Bluesky is federating internally, and it's hitting us! 😁 bluesky-social/atproto#1832 . We need to start resolving handles and DIDs to users' individual PDSes and make calls to them instead of bsky.social, or at least auth calls and get timelines etc from the prod AppView api.bsky.app. Not sure which we'll prefer. cc @JoelOtter

[snarfed]

Sounds like this isn't actually a priority until real federation. From bluesky-social/atproto#1832 :

Client apps, bots, and other integrations can continue to connect to bsky.social as an API endpoint, and requests will be proxied to the appropriate endpoint. They do not need to connect directly to the account's PDS for now, especially for authentication (login and session refresh)

[snarfed]

Most of the work here will probably happen in snarfed/lexrpc#4

[benharri]

I am running into this now that I have completed my PDS migration. Holler if there's any way I can help!

[benharri]

thoughts on adding a service field to the login form so you don't have to do the resolution every time? the main bsky app makes you pick a service when you log in

[snarfed]

@benharri hmm! I could, but I think I'd prefer to discover the PDS from the DID doc. Easier UX for users, and logging in is rare, so I'm not worried about load.

Sorry I haven't gotten to this yet! I've been focused on Bridgy Fed. Happy to help if you want to dive in here! The work might end up all in lexrpc, eg snarfed/lexrpc#4

[benharri]

Makes sense! I will pull down lexrpc and see what I can do :)