12 ms·

This looks like a wrapper around several popular social login. While it is convenient, I fail to see how it is decentralized. If anything, it just add another s

This looks like a wrapper around several popular social login. While it is convenient, I fail to see how it is decentralized. If anything, it just add another single point of failure, so it is more centralized? As a SaaS vendor, I likely already support several social logins and email verification. Why should I switch? If I have not implemented the social logins, I can see the convenient factor. However, social login is not that hard to implement, and if you did for one vendor, it is just mechanic to do the same to other vendors. Users are your most valuable asset so I consider it time well spent.

dickhardt 4y ago
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.
- danpalmer 4y ago
  > 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 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. 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.
  - dickhardt 4y ago
    > 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.
    - 4y ago
- deleted 4y ago
  [deleted]
- type0 4y ago
  In what jurisdiction is this coop based/registered?
  - dickhardt 4y ago
    Washington as recommended by our counsel. REI is also based in Washington and the co-operative laws work well for having many members. Our vision is to have over a billion users, hence a billion members, and be the largest co-operative in the world.

dickhardt 4y ago

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.

danpalmer 4y ago
> 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 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. 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.
- dickhardt 4y ago
  > 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.
  - 4y ago
deleted 4y ago
[deleted]
type0 4y ago
In what jurisdiction is this coop based/registered?
- dickhardt 4y ago
  Washington as recommended by our counsel. REI is also based in Washington and the co-operative laws work well for having many members. Our vision is to have over a billion users, hence a billion members, and be the largest co-operative in the world.