Post

Nick Gerakines
@ngerakines.me

The simple answer is that atprotofans is an early technical preview where we’re trying out stuff. Long term we won’t need that app password bit.

dad (aka miguel)
@aka.dad

thats a fair answer, from what i've learned while building out my own atproto oauth and client package is that app passwords, while invasive, are just easier for scheduled tasks, creating records or completing other actions on the behalf of the user while they're away from the site.

dad (aka miguel)
@aka.dad

like you mentioned, great for experimenting quickly. and unless you are using a well developed library/package for atproto oauth, it is very annoying to set up. you wouldn't want to fail to create these records or delay them while you email the user, so app passwords ftw (until the site is matured)

0 reposts0 likes

Luna
@shi.gg

while I agree that app passwds are easier to implement as a dev; I hate to use them as a user. plus, PDSs like cocoon dont even support app passwds

Wamellow@wamellow.com

in case you are wondering why people do not implement @atproto.com oauth2, this is why. It's very hard to do compared to the traditional oauth2 flow..

dad (aka miguel)
@aka.dad

I hate them too, one of the reasons I am not using atf. just adding context for others that may not be in the know. but once matured I’m sure they’ll move off them 🤷🏽‍♂️ I hope anyway