Authentication is an area that generally has really difficult UX constraints and the language really matters.
Dan Abramov launched https://internethandle.org/ in late November and has been promoting the use of "Internet Handle" as a standard term for authentication in the ATProtocol ecosystem.
I'm open to the idea, but I don't think "handle" will catch on quickly since users might need time to get used to it. Still, it's better than options like "bluesky account", "at-handle", "DID" or "PDS". "Bluesky account" is probably the easiest for users to understand, but we shouldn't mix up identity with the Bluesky Social AppView.
Today, Tom Sherman posted screenshots of new terminology for https://frontpage.fyi/ to gather community feedback:
Thoughts on this atproto login UI? Play with it on the link below but you need a Vercel account so i attached some screenshots too frontpage-git-rework-login-form-frontpagefyi.vercel.app/login?_vercel_sh…
His post inspired me to try a similar experiment on Smoke Signal, using the same design and terms:
This is also a good time to document what I believe to be the standard all AppViews and applications should support for authentication inputs to make user authentication consistent across the ecosystem:
Login forms should accept four types of inputs: handles, DIDs, AT-URIs, and URLs. For example, these are all valid: "did:plc:cbkjy5n7bk3ax2wplmtjofq2", "did:web:atwork.place", "ngerakines.me", and "https://pds.cauda.cloud/". Any of these should start the authentication process.
A DID input can include the "at://" prefix. The specification says that a protocol prefix plus an authority makes a valid AT-URI, like "at://did:plc:cbkjy5n7bk3ax2wplmtjofq2".
A handle input can include the "@" or "at://" prefix. Like with DIDs, an AT-URI authority can also be a valid handle, such as "at://ngerakines.me".
If someone enters a partial handle as one alphanumeric string with dashes, it makes sense to assume the full handle ends with ".bsky.social".
An HTTPS URL is also a valid input and should be treated as an authorization server or protected resource. For example, it’s valid to authenticate against a PDS like "https://pds.cauda.cloud/".
Some users might be confused by "internet handle" and enter their handle as a URL. If, for example, "https://ngerakines.me" isn’t valid as an authorization server or protected resource, the system should check if the hostname be used to resolve to a DID.