Handle Hiding with OAuth

[Kzoeps]

Currently the browser oauth-client does not allow a user login with their email. Thats due to handle resolver working only with handles and pds url (in case someone forgets their handle). The oauth browser client provided by atproto does not allow emails to be entered.

Even if you know the PDS URL and you send an email with it, the current setup of PDS and atproto is such that the request errors out since they dont accept emails. Just handles, did and pds url (same as the browser oauth-client).

Potential Solution

However if one does know which PDS the user will be on and if we have admin* access to the PDS then we can use this searchAccounts function ( bsky docs which allows you to get the handle of the user based on the email. So when the user tries to login they enter their email, the app calls this api endpoint to search accounts with the related email and the email has an associated handle then we send the handle in the oauth request.

Called it hypercertsPDS here but would be better to call it as Hypercerts Service

Currently while implementing this i had an issue with the com.atproto.admin.searchAccounts so used a combination of com.atproto.sync.listRepos along with com.atproto.admin.getAccountInfo. But I think the issue is actually on atproto side and needs more clarification.

Note while calling the xrpc functions for com.atproto.admin we need to know the PDS_ADMIN_PASSWORD to be able to call this API as it uses basic auth (admin:PDS_ADMIN_PASSWORD) so i guess there would have to be some form of central server as mentioned in the bottom

Alternative Solutions

The browser oauth client accepts the pds_url incase a user forgets their handle. however it doesnt allow adding a login_hint. So since we know that most users are going to be on the certs pds, we could fork the atproto browser client to allow entering a login_hint. so it would look something like:

client.signIn("https://hypercerts.org", {login_hint: "user@email.com"}

Caveat to this is that it requires touching not just the oauth client but also the pds code as well since the pds also has a check for handle resolver

Hashbased usernames is also a potential solution but I think it would really confuse the user quite a bit. since we would be creating accounts with the username as a hash of the email and when we redirect them to the oauth login page the identifier would be the hash and that is quite confusing.

it would probably look something like this

I say hypercerts PDS but we would probably need to either make the searchAccounts public or set up a server which fitlers based on who is sending the request (so only authorized websites) have access to it or there might be some other way.

[Kzoeps]

https://www.loom.com/share/58dbe8fcc4b548579e1b23e8eec52319

Repo link: https://github.com/Kzoeps/maearth-test

But the function to get the account handle is here: https://github.com/Kzoeps/maearth-test/blob/main/api/searchAccounts.ts

Used a work around of listing repos and then getting the account info for each. but will try to create an issue on atproto to see if its not an issue from their side.