PDS Provider Login Flow

As part of the fake PDS Provider I wrote about in PDS-as-a-Service, I put together the screens the provider service might give to appviews that implement it. The workflow is actually quite similar to how "Login with Bluesky" works today; these hypothetical login screens are hosted by "OctoPDS," not by the "GrahameReads" appview.

What folks are doing today (check out the great embedded canvas for examples!)

putting the @ in atproto - Chris's Corner

a moment to reflect on the politics behind atproto

https://chrisshank.leaflet.pub/3maf7mbsi222i/l-quote/0_702-0_785#0_702

This is the model for most apps today. Most people are hosted on Bluesky, so you're directed to login at Bluesky.

Wamellow

1mo

now, explain that the average user who is not a tech nerd. "why do I have to create an account on bluesky to use XY?" "I created a bluesky account; what's atproto?" "why can I not create an account here?"

If your user is savvy enough to have a different PDS, they can log in with it, and it is the responsiblity of the PDS to handle auth. But user new to the ATmosphere must make a Bluesky PDS. This includes people who might have made a PDS with a different provider and not realized they were on the ATmosphere!

The problem in a nutshell -->

A PDS provider ought to handle the routing for the users in a way that makes it clear to the user what they're signing up for, but doesn't obfuscate the fact that the data is going to live with the provider, NOT with the app view. It needs to serve people who are used to the mental model of "email for everything" while nudging them towards the way things are done in the ATmosphere.

It's a tricky line to walk.

My imaginary provider, OctoPDS, does this by hosting an appview's login page (or providing hooks for the appview) and allowing them to customize it for their branding and style. GrahameReads (my cool app), directs all login attempts to this page. It is OctoPDS' responsibility to handle the rest.

As an app developer, I'm using OctoPDS because I can quickly configure this page and then I can get on to doing something useful with my project. Plus, if I spring for the domain service, users who make an account will have @foo.grahamereads.com as their default. Free marketing and I don't have to host any infrastructure or data backups!

The Four Logins of the OctoPDS-alypse

1. User knows they are on the ATmosphere. They log in with an OctoPDS-hosted handle.

3. User is brand new to the ATmosphere. They log in with their email address.

4. User doesn't know they've got a PDS with OctoPDS (or they forgot). They log in with their email address.

2. User knows they are on the ATmosphere. They log in with a 3rd-party (or self-hosted) handle.

The goal is to push your users into categories 1 & 2, but be forgiving for people used to the classic email signup model. Developers get rid of data management headaches; users can authenticate however they feel comfortable, and no one feels like they're signing up for a service they didn't want. Everyone wins.

How it starts:

<-- ATmosphere login

<-- Email login (log into OctoPDS)

I think this could be better. The point is to put the appview branding first (to not confuse people on the old model) while making it clear to people who are actually interested in this stuff where their data is living.

Workflow 1:

Workflow 2:

3rd-party PDS providers use their own OAuth workflows, just as it is today. My foo.bsky.social PDS handle directs me to the appropriate service. Log in, approve the scopes, we're good

I've got a PDS with OctoPDS. Easy--just log in, approve the new scopes, all done.

--------------->

Workflow 3:

------------>

(might skip this for a brand new account, see below)

Signing up for GrahameReads is actually signing up for OctoPDS. We don't hide that fact but the UX ideally makes it so you don't have to care.

-------------->

Workflow 4:

This is the perfect situation for a "magic link" login. If I'm trying to create an account with a new service and I didn't realize I had an OctoPDS account, what are the odds I remember my password for it?

--------------------------------------------------------------->

If this is a brand new account through OctoPDS, you probably don't need to approve the scopes, since by definition the PDS only serves GrahameReads! We should still notify you that we did it though, even if we do skip the OAuth step.

Oh, I guess I already had an OctoPDS account. All I gotta do is log in and I'm good.

How it ends:

All workflows except 3rd-party PDS providers end up here when you first sign up for GrahameReads. OctoPDS makes the account, does the confirmation, and then gives you a link to their portal to browse your data.

Third-party providers would likely just end up in the actual appview; at a minimum they wouldn't have the "Browse your PDS" button. Or maybe they would--it's a good idea o foster some competition between these services if we want to keep our PDS providers honest!

Just one more nudge to check out this whole "ATmosphere" thing...

Final Thoughts

I don't run a PDS service, but from what I've seen the existing ones go hard into supporting the folks who care about the decentralized/federalized/"own your data" aspects of it. The unfortunate reality is that most people don't know or care about those things--but they do care about the benefits. Likewise, a PDS provider needs to make themselves as attractive to the app developers as possible if they want to get people on their service.

This mock workflow is how I think about approaching that problem. All of you out there actually building this infrastructure--please feel free to steal this! It benefits everyone to get folks on the AT Protocol, and I think an approach is possible that allows users to ease in, go full-bore, or completely ignore the underlying tech--whatever they prefer