Show HN: Hellō, a cooperative approach for online identity

Thanks for the questions!

Hellō is not decentralized -- apologies for any confusion -- did I mistakenly write that somewhere?

The governance is decentralized. Yes, it is another point of failure, as is any other service you build your app on. I have extensive experience with tier zero services such as AWS IAM and have applied those learnings to the Hellō deployment if that is any consolation.

The value proposition of Hellō is not as great for you as you have already made a substantial investment in your identity implementation. In the future when Hellō has a larger claims selection than verified email, phone and ethereum address -- you may find it valuable to use Hellō to request claims from your users. Additionally, depending on your application, you may want to make claims about your users that they can share with other sites. Empowering users to control their identity and share it is our mission. Claims can range from VIP cards to memberships to reputation scores.

Fully agree that social login is not hard to implement. (I'll take that as a compliment as one of the designers!) As you add additional providers so that you provider more choice to your users, the risk of a user fragmenting their identity by choosing a different provider when they return increases. Dealing with fragmented identities in your app is hard.

Additionally, registering and configuring your app at Apple / Facebook / Google etc. is non-trivial. I know what I am doing in theory, and I have already invested a week of time in configuration and approvals and updates.

I like this direction, I think for web3 to really become a thing the user should never see any cryto stuff, and advanced use and control can come as an enchancement of the basic case.

> I don't feel like it's worth giving up control over your user's authentication to an intermediary in return for saving a week of work. Maybe the case could be made for day-1 of a startup, but certainly not year-1, it's just too critical a component.

Are you not outsourcing to an intermediary with Apple/FB/Google?

Authentication is critical. Completely agree. It is also not a differentiator for your application unless done poorly. Using a 3P such as Apple/FB/Google leverages the account protection investment that those providers are making. Using Hellō gives the same protection, while preserving the user's privacy (provider does not know which app the user is logging into) -- and giving them choice and account recovery.

As noted, if you have already made the investment, Hellō does not provide the same value today.

> I'd also challenge this taking a week. Apple/FB/Google sign-on is pretty straightforward, and I've found the cost is mostly in setting up an open-source auth library in my webapps rather than enabling a given service provider.

I'm sharing my experience. Apple requires a D&B number to register your app. Many require you to jump through their process for proving control of a domain. Microsoft requires you register as a partner if you don't want the scary unverified label. FB disabled Hellō for not having the correct link to the app, then disabled for not having a required term in our T&S.

Others may not have the same challenges as I did -- but it was non-trivial amount of time to manage the app registrations.

FWIW I don't use libraries for the OIDC flows -- I find it makes it more complicated than it needs to be. I do use libraries for any JWT work of course.

> I don't feel like it's worth giving up control over your user's authentication to an intermediary in return for saving a week of work.

The market is tested, though. Auth0 is a notable player in this space and they seem to be making money.

Like you, I've been pretty unhappy with this class of product. Auth0 provides just enough to be dangerous; upload Javascript with no way to unit test it to gate auth (that broke!), support for multiple social providers but no built-in way to unify accounts (do that yourself), etc. They also have an insanely low limit for OAuth client applications; so low that we had to buy an enterprise contract to scale out to production.

(BTW, the way I tested auth hooks after an outage caused by a faulty one was to implement their API in Go, embed a Javascript interpreter in our Go tests, and then execute the hooks against an in-memory version of our API server. That eliminated any server-caused auth hook breakages. But I have to ask, why am I paying them when I have to do all the work?)

A competitor could be good here.

I created my account with Google. But then Google shut my account down for posting too much pirated music to Youtube. How do I get back into my Greenfield Fitness account?