Right. The bug is that a bridgy BlueSky account (like, say @cowperthwait.sfba.social.ap.brid.gy) can't authenticate via OAuth flows to BlueSky until they change their current implementation a smidgen.
They can implement it or not, but breaking OAuth seems bad.
Less "implement" and more "not break other clients."
1. I set up a Bsky account using bridgy.
2. I use that account normally. Now I try to use that account with Client Foo, a bsky client that uses OAuth instead of app passwords.
3. That account will fail to authenticate for Client Foo.
well if bridgy is your PDS, you need your PDS to implement oauth to do oauth. bridgy is an incomplete PDS implementation. obviously it is good to have and yes I agree it would be nice if bridgy had it
you can always migrate your account to a PDS running our PDS software if you need oauth
That does make some sense. I'm just wondering how to construct an error flow that doesn't send future developers down the same rabbit hole I just climbed out of!
You’re (amazingly) bridging a completely different protocol and participating pretty well.
Bridgy as stated is not a fully native account or client.
And bridgy just forwards posts, so no cool non-microblog content like @recipe.exchange or @smokesignal.events or @whtwnd.com
Bridgy's PDS library github.com/snarfed/arroba already pretty much is a full featured PDS! Minus OAuth. 😎 I ran it as a standalone PDS, separate from Bridgy Fed, early on for testing.
was asking this as well - while it would be super cool to log in to your pds account on bridgy i don't think the devs particularly intended for one to do so,