Show HN: Hellō, a cooperative approach for online identity(hello.coop)
hello.coop
Show HN: Hellō, a cooperative approach for online identity
https://www.hello.coop/pages/approach.html
54 comments
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.
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.
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.
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.
> 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.
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.
> 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.
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 concur that some of the tier0 social login providers are not very developer friendly. The more dev friendly and user friendly social logins are such as GitHub or Discord. They have straight forward processes and a clear management console.
> Are you not outsourcing to an intermediary with Apple/FB/Google?
This is a product decision, it gets you better security (on average), brand association that may be good for the right product/SSO combination, easier signup (at least in theory), and in many cases is necessary for integrations with those services.
Using Hellō gets you better security (on average), but not as much as going direct. It loses some of the brand association, and in fact I'd suggest many users would probably want to whitelabel Hellō. It adds an extra step to sign-up over direct integrations. And it likely complicates integrations with the services.
> 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.
These are all fair points!
Apple is a pain, in fact I wrote up a long post about all the issues, although I'm not sure Apple via Hellō solves the ongoing issues, only the initial setup cost? – https://danpalmer.me/2019-07-02-on-signing-in-with-apple/
Facebook will ban apps for all sorts of reasons, but having experienced the nasty end of this I unfortunately suspect that Facebook might take issue with it, and Hellō may become a single point of failure that could cause a FB login outage across many services.
> 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've seen good ones and bad ones. The one that I was thinking of when I wrote my original comment was Django All Auth. It gives you much the same effect as Hellō, and in my experience setup of the library has not been difficult, and has made it easier to implement multiple flows quickly. Devise for Rails was a bit of a pain 9 years ago though.
It probably all depends on access to high quality libraries in your ecosystem of choice how much you value things like Hellō, and having a lot of Django experience I just don't really feel the value proposition.
This is a product decision, it gets you better security (on average), brand association that may be good for the right product/SSO combination, easier signup (at least in theory), and in many cases is necessary for integrations with those services.
Using Hellō gets you better security (on average), but not as much as going direct. It loses some of the brand association, and in fact I'd suggest many users would probably want to whitelabel Hellō. It adds an extra step to sign-up over direct integrations. And it likely complicates integrations with the services.
> 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.
These are all fair points!
Apple is a pain, in fact I wrote up a long post about all the issues, although I'm not sure Apple via Hellō solves the ongoing issues, only the initial setup cost? – https://danpalmer.me/2019-07-02-on-signing-in-with-apple/
Facebook will ban apps for all sorts of reasons, but having experienced the nasty end of this I unfortunately suspect that Facebook might take issue with it, and Hellō may become a single point of failure that could cause a FB login outage across many services.
> 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've seen good ones and bad ones. The one that I was thinking of when I wrote my original comment was Django All Auth. It gives you much the same effect as Hellō, and in my experience setup of the library has not been difficult, and has made it easier to implement multiple flows quickly. Devise for Rails was a bit of a pain 9 years ago though.
It probably all depends on access to high quality libraries in your ecosystem of choice how much you value things like Hellō, and having a lot of Django experience I just don't really feel the value proposition.
As a developer, you don't know which provider the user has chosen, and the provider does not know which apps the user is using, improving privacy and resiliency.
> And it likely complicates integrations with the services. If you want access to resources at the provider, such as Google Calendar, then you will need to directly integrate to get the access token. Hellō provides identity, not access to resources.
> And it likely complicates integrations with the services. If you want access to resources at the provider, such as Google Calendar, then you will need to directly integrate to get the access token. Hellō provides identity, not access to resources.
> Using Hellō gives the same protection, while preserving the user's privacy (provider does not know which app the user is logging into)
Wouldn't Hellō know all of this though? It seems it's just moving the privacy concern to another organization.
Wouldn't Hellō know all of this though? It seems it's just moving the privacy concern to another organization.
Hellō has an interesting protocol that prevents Hellō staff from knowing what data is stored in the system.
There's an step-by-step overview of the protocol at https://www.hello.coop/pages/protocol.html
There's an step-by-step overview of the protocol at https://www.hello.coop/pages/protocol.html
> 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.
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.
Auth0 can be prohibitively expensive if you have low revenue per user.
We are working on providing an OSS docker image that would mock Hellō so that you could get full coverage in automated testing of registration and login. Would you find that useful?
We are working on providing an OSS docker image that would mock Hellō so that you could get full coverage in automated testing of registration and login. Would you find that useful?
Absolutely, that sounds really neat. (We actually don't do a SaaS at work anymore, so I'm not in the market... but would have loved that at the time!)
> 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
It absolutely is for people building/validating MVPs
It absolutely is for people building/validating MVPs
[deleted]
In what jurisdiction is this coop based/registered?
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.
Just chiming to say that we used Hellō for one of our products ( bestozy.com ) and the whole experience was a breeze. Dick Hardt was very accessible - but tbh we didn't need much help at all as the integration was straightforward and the documentation comprehensive.
Thanks for the kind words!
> Hellō provides a fully-featured OpenID Connect interface
Why not just use self-issued OpenID identities then?
Well, I guess the reason is that the standard[0] hasn't even been finalised yet, and there are no implementations (as far as I know), but it seems like some combination of that plus Verifiable Claims is the correct way to provide decentralised identities.
[0] https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
Why not just use self-issued OpenID identities then?
Well, I guess the reason is that the standard[0] hasn't even been finalised yet, and there are no implementations (as far as I know), but it seems like some combination of that plus Verifiable Claims is the correct way to provide decentralised identities.
[0] https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
SIOP has been around for a long time without any adoption. A critical technical challenge is getting the operating systems to support managing the app that responds to the 'openid:' scheme. On iOS, the last app installed gets the call, which is not what you want for your identity wallet.
I gave a talk on the need to be pragmatic to get adoption:
https://www.kuppingercole.com/watch/eic2021-hardt-dogmatism-...
I gave a talk on the need to be pragmatic to get adoption:
https://www.kuppingercole.com/watch/eic2021-hardt-dogmatism-...
Thanks for the reply. I hadn't realised that SIOP has been around for a long time, but I'm pleased that Microsoft and others still seem to be working on it (the most recent draft was published last month).
That's an interesting point about the 'openid:' scheme. Are you worried about someone having a use case where they want two separate wallet apps installed at the same time on their phone (rather than one app that can support multiple identities)?
Or is the concern more that someone might install a (seemingly unrelated) second app which surreptitiously hijacks the scheme and spoofs the interface of the existing app, to trick people into... revealing which sites they have accounts on? (The second app wouldn't be able to steal the keys from the first one, right?)
Anyway, it's good that multiple approaches are being attempted to solve the vital problem of decentralised identity, and I look forward to seeing how much adoption Hellō gets.
That's an interesting point about the 'openid:' scheme. Are you worried about someone having a use case where they want two separate wallet apps installed at the same time on their phone (rather than one app that can support multiple identities)?
Or is the concern more that someone might install a (seemingly unrelated) second app which surreptitiously hijacks the scheme and spoofs the interface of the existing app, to trick people into... revealing which sites they have accounts on? (The second app wouldn't be able to steal the keys from the first one, right?)
Anyway, it's good that multiple approaches are being attempted to solve the vital problem of decentralised identity, and I look forward to seeing how much adoption Hellō gets.
The second point is more concerning.
A related point is that it only works if the user already has a wallet installed that is listening on "openid:". "mailto:" and "tel:" work on a phone since there is an email and phone app on all phones by default.
This is a classic chicken and egg problem. Why would a developer use "openid:" if there are few, if any users, and why would a user install a wallet for "openid:" if there are no apps.
Thanks for your encouragement! ... would love any other feedback you have.
We believe Hellō is SSI (Self Sovereign Identity) -- decentralized approaches are one way to approach -- a distributed centralized approach like Hellō is another way that is more pragmatic.
A related point is that it only works if the user already has a wallet installed that is listening on "openid:". "mailto:" and "tel:" work on a phone since there is an email and phone app on all phones by default.
This is a classic chicken and egg problem. Why would a developer use "openid:" if there are few, if any users, and why would a user install a wallet for "openid:" if there are no apps.
Thanks for your encouragement! ... would love any other feedback you have.
We believe Hellō is SSI (Self Sovereign Identity) -- decentralized approaches are one way to approach -- a distributed centralized approach like Hellō is another way that is more pragmatic.
What I'm interpreting the value of this to me would be is that I can bootstrap user enrollment by getting them to login to my application with a social identity they assert via hello.coop, and then I can add layers of additional identity assurance on top of that login if my application requires it.
As a developer/architect, I would have a user enrollment waiting room role in my application/service where certain features would be available to hello.coop asserted identities, and then more features would become available as I got the necessary identity assurance/KYC from them. It removes the need for me to do password management and account recovery, because that's on the user to manage via their social identities.
As a user, I presume if I want access to a service, I just pick the IDP of my choice to use for a given service. (imo, protonmail needs to provide an oauth2 identity service as well)
The resilliance of this could be provided by linking social identities on a blockchain, so if any one or two IDPs decide they're going to cut hello.coop off, the users can still use their hello.coop identity that was linked to their other social logins, and just not the IDP who defected.
Is this an accurate interpretation?
As a developer/architect, I would have a user enrollment waiting room role in my application/service where certain features would be available to hello.coop asserted identities, and then more features would become available as I got the necessary identity assurance/KYC from them. It removes the need for me to do password management and account recovery, because that's on the user to manage via their social identities.
As a user, I presume if I want access to a service, I just pick the IDP of my choice to use for a given service. (imo, protonmail needs to provide an oauth2 identity service as well)
The resilliance of this could be provided by linking social identities on a blockchain, so if any one or two IDPs decide they're going to cut hello.coop off, the users can still use their hello.coop identity that was linked to their other social logins, and just not the IDP who defected.
Is this an accurate interpretation?
Thanks for the comments and describing your interpretation -- which is correct -- clarifications follow:
We not only support social login, but also crypto wallets that support browser extensions or Wallet Connect. The user can also just use email or phone. We will be adding support for Passkey once the implementations have sorted out some details.
Yes, you can bootstrap enrollment with Hellō and then prompt the user for additional profile / identity assurance. We are working on supporting KYC claims as well so that you could request them and then Hellō would interact with the user on how best to gather those from the user if we don't already have them. IE we would be an abstraction layer for KYC similar to being an abstraction for login and profile registration.
As a user, you pick your "IdP" for your Hellō wallet, and use that IdP for all apps that support Hellō until you want to change your preferred provider. In the future, the user does KYC once with us and then has a reusable identity.
wrt. resilience -- we encourage users to setup two or more backup providers so they can recover their Hellō Wallet if they lose access to their preferred provider. Recovery requires logging in with two backup providers, and then they can change their preferred provider.
We not only support social login, but also crypto wallets that support browser extensions or Wallet Connect. The user can also just use email or phone. We will be adding support for Passkey once the implementations have sorted out some details.
Yes, you can bootstrap enrollment with Hellō and then prompt the user for additional profile / identity assurance. We are working on supporting KYC claims as well so that you could request them and then Hellō would interact with the user on how best to gather those from the user if we don't already have them. IE we would be an abstraction layer for KYC similar to being an abstraction for login and profile registration.
As a user, you pick your "IdP" for your Hellō wallet, and use that IdP for all apps that support Hellō until you want to change your preferred provider. In the future, the user does KYC once with us and then has a reusable identity.
wrt. resilience -- we encourage users to setup two or more backup providers so they can recover their Hellō Wallet if they lose access to their preferred provider. Recovery requires logging in with two backup providers, and then they can change their preferred provider.
What is the role/responsibility/benefit of corporate members? It's not clear from the available descriptions why a company would want to become one. Perhaps simply to support the initiative?
Supporting the initiative is one reason to join. Influencing the direction of the co-operative is another. Our current corporate members want Hellō to succeed as it will help their business succeed. A rising tide raises all boats.
The only responsibility of a corporate member is to abide by the bylaws, and vote for the corporate board members.
We have been having regular corporate member meetings to review progress and discuss identity trends. I think the current members learn something from the other members at each meeting.
The only responsibility of a corporate member is to abide by the bylaws, and vote for the corporate board members.
We have been having regular corporate member meetings to review progress and discuss identity trends. I think the current members learn something from the other members at each meeting.
Corporate members can also can elect board members – as can the other classes of coop member. See https://www.hello.coop/pages/cooperative.html
Hi HN!
I’m Dick Hardt[1]. Over the last twenty years, I’ve led the design of identity standards (OAuth 2.0, JWT) and systems that you and billions of others use every day.[2]
You know that these systems don’t always work in your favor. Each is bespoke and most, if not all, of your identity is locked up in these silos. I called this out in my Identity 2.0 OSCON talk in 2005 where I popularized a user-centric identity vision.[3]
Unfortunately, we have failed to realize the vision of user-centric identity: of giving you control of your identity. We have far too many passwords. Identity theft is rampant. Online interactions are either tedious or risky. In short, internet identity is a disaster today.
Most proposals today to give you control of your identity require you, your applications, and the issuers of claims about you (such as your bank or government), to adopt a new technology - a three-sided cold start problem.
I founded Hellō to take a different approach -- an abstraction layer that lets you use the technology and identity you already have -- that’s operated by a not-for-profit co-operative.
The Hellō journey did not start with building a product -- it started with exploring how to resolve the risks of a central service, and finding organizations aligned on the vision. Once three industry-leading organizations joined as founding corporate members of the co-operative, we built and tested our PoC, our MVP, and then our developer console.
Hellō is available for you to use today. We have a demo at https://greenfielddemo.com. Several apps use Hellō today, and many are exploring adoption. If you are building a new app, you can tick off most of your identity tasks in a few hours if you use Hellō. Details at https://hello.dev
We’d love feedback on your experience.
In contrast to other identity service offerings, Hellō does not help the developer manage and store user data -- Hellō helps the user manage their data and share it with the developer. The Hellō business model is to charge (in the future) an interchange fee of a few pennies for each new verified claim the user releases to the application. There is no MAU fee. No fee for authentication. No fee for users. No fee for issuers.
We expect you have more questions.
https://www.hello.coop/pages/approach.html describes:
- Our approach
- How the cooperative works
- How we’ll fund Hellō with smart contracts
- Our guiding tenets
- How we protect people’s privacy
- Our architecture
Thanks for reading and trying! Please share your questions, impressions, criticisms, and requests!
Want a more personal interaction? I am hosting an AMA on Twitter Space later today (Wed Oct 12) from 4-5PM PT.
https://twitter.com/i/spaces/1LyxBqvnmAyJN
You can also email me [email protected]
[1] https://www.linkedin.com/in/dickhardt/ https://en.wikipedia.org/wiki/Dick_Hardt https://twitter.com/DickHardt
[2] https://datatracker.ietf.org/doc/html/rfc6749, https://datatracker.ietf.org/doc/html/rfc6750, https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
[3] https://www.youtube.com/watch?v=RrpajcAgR1E
I’m Dick Hardt[1]. Over the last twenty years, I’ve led the design of identity standards (OAuth 2.0, JWT) and systems that you and billions of others use every day.[2]
You know that these systems don’t always work in your favor. Each is bespoke and most, if not all, of your identity is locked up in these silos. I called this out in my Identity 2.0 OSCON talk in 2005 where I popularized a user-centric identity vision.[3]
Unfortunately, we have failed to realize the vision of user-centric identity: of giving you control of your identity. We have far too many passwords. Identity theft is rampant. Online interactions are either tedious or risky. In short, internet identity is a disaster today.
Most proposals today to give you control of your identity require you, your applications, and the issuers of claims about you (such as your bank or government), to adopt a new technology - a three-sided cold start problem.
I founded Hellō to take a different approach -- an abstraction layer that lets you use the technology and identity you already have -- that’s operated by a not-for-profit co-operative.
The Hellō journey did not start with building a product -- it started with exploring how to resolve the risks of a central service, and finding organizations aligned on the vision. Once three industry-leading organizations joined as founding corporate members of the co-operative, we built and tested our PoC, our MVP, and then our developer console.
Hellō is available for you to use today. We have a demo at https://greenfielddemo.com. Several apps use Hellō today, and many are exploring adoption. If you are building a new app, you can tick off most of your identity tasks in a few hours if you use Hellō. Details at https://hello.dev
We’d love feedback on your experience.
In contrast to other identity service offerings, Hellō does not help the developer manage and store user data -- Hellō helps the user manage their data and share it with the developer. The Hellō business model is to charge (in the future) an interchange fee of a few pennies for each new verified claim the user releases to the application. There is no MAU fee. No fee for authentication. No fee for users. No fee for issuers.
We expect you have more questions.
https://www.hello.coop/pages/approach.html describes:
- Our approach
- How the cooperative works
- How we’ll fund Hellō with smart contracts
- Our guiding tenets
- How we protect people’s privacy
- Our architecture
Thanks for reading and trying! Please share your questions, impressions, criticisms, and requests!
Want a more personal interaction? I am hosting an AMA on Twitter Space later today (Wed Oct 12) from 4-5PM PT.
https://twitter.com/i/spaces/1LyxBqvnmAyJN
You can also email me [email protected]
[1] https://www.linkedin.com/in/dickhardt/ https://en.wikipedia.org/wiki/Dick_Hardt https://twitter.com/DickHardt
[2] https://datatracker.ietf.org/doc/html/rfc6749, https://datatracker.ietf.org/doc/html/rfc6750, https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
[3] https://www.youtube.com/watch?v=RrpajcAgR1E
Can you support GitHub as aprovider? It seems to be the de-facto standard for dev tool services, and is the only one I regularly use.
Yes. GitHub, GitLab, and Discord are on our roadmap. Twitter is also -- but more as a way to claim a Twitter handle.
We did not do GitHub and Discord at first as they are OAuth only -- no OpenID Connect support.
Thanks for letting us know what you would like!
We did not do GitHub and Discord at first as they are OAuth only -- no OpenID Connect support.
Thanks for letting us know what you would like!
> - How we’ll fund Hellō with smart contracts
extremely hard for me to get excited about something that has blockchain in it these days
extremely hard for me to get excited about something that has blockchain in it these days
The blockchain aspect is not supposed to get you excited. :)
As a co-operative we don't have equity to sell for financing. Tokens enable us to separate ROI from governance, and many investors are willing to invest in tokens.
As a developer or user, the blockchain aspect is hopefully irrelevant.
As a co-operative we don't have equity to sell for financing. Tokens enable us to separate ROI from governance, and many investors are willing to invest in tokens.
As a developer or user, the blockchain aspect is hopefully irrelevant.
I can see this being very useful for web3 projects once you add support for the discord scope. A lot of the time you just want a way of logging in with a wallet and link to discord in a secure way.
I've implemented this for a bunch of clients lately and would probably have used something like this if it was available and mature.
I've implemented this for a bunch of clients lately and would probably have used something like this if it was available and mature.
Thanks for sharing! I’ve moved discord up in our priorities. Feel free to reach out directly.
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?
Giving you control of your identity is our mission. You online presence should not be held hostage by any of the social providers, which is why we encourage you to add backup providers so you can recover your Hellō Wallet if you lose access to your preferred provider.
Losing access to your users is also a risk as a developer as the provider can take away your app access to their service. Our goal is to be neutral and not be able to take away either the user's account, or the developer's access.
Losing access to your users is also a risk as a developer as the provider can take away your app access to their service. Our goal is to be neutral and not be able to take away either the user's account, or the developer's access.
Hellō has you set up multiple recovery providers and methods, making it unlikely that you'll lose access to your Hellō account. Visit https://wallet.hello.coop after you go through https://www.greenfielddemo.com/ and you'll see the workflow.
Also Spain digital certificate. (in translation) https://www.exteriores.gob.es/Consulados/toronto/en/Servicio...
I don't really see what this gives over Auth0, Orly or various other identity providers which have social login plugins available…and none of those seem to be involved with anything related to smart contracts, which makes them infinitely preferable in my opinion.
You don't need to register with the various providers or set up any plugins. You set things up once and then you're done. See Dick's comment about the reg bit at https://news.ycombinator.com/item?id=33180661
Also, jrockway shared relevant Auth0 comments in this discussion at https://news.ycombinator.com/item?id=33180939.
Is your reluctance around smart contracts influenced at all by https://www.hello.coop/pages/financing.html?
Also, jrockway shared relevant Auth0 comments in this discussion at https://news.ycombinator.com/item?id=33180939.
Is your reluctance around smart contracts influenced at all by https://www.hello.coop/pages/financing.html?
Not at all. I do not believe that smart contracts are a feature. With smart contracts, there's a shift to mostly untested buggy contracts written on buggy and wasteful execution systems (e.g., Ethereum or some other crypto-chain). It's also completely unclear whether "smart" contracts would be considered enforceable in many or most jurisdictions.
There's well-documented failures of so-called "smart" contracts, and IMO building something like this on top of one is a recipe for disaster, just like the rest of the crypto-blockchain ecosystem.
There's well-documented failures of so-called "smart" contracts, and IMO building something like this on top of one is a recipe for disaster, just like the rest of the crypto-blockchain ecosystem.
Agree that there have been many failures in the smart contract market.
In contrast to many crypto projects, we are only using smart contracts for financing Hellō so that we can separate the return on investment from the cooperative governance. This removes one of the common failure modes of governance gone awry.
There is significant innovation in the crypto ecosystem and while there are failures (as there will be with any novel technology) there are also successes. As we don’t need to issue any smart contracts in the immediate future, we will be able to build upon the successes.
In contrast to many crypto projects, we are only using smart contracts for financing Hellō so that we can separate the return on investment from the cooperative governance. This removes one of the common failure modes of governance gone awry.
There is significant innovation in the crypto ecosystem and while there are failures (as there will be with any novel technology) there are also successes. As we don’t need to issue any smart contracts in the immediate future, we will be able to build upon the successes.
Reminds me of Estonia digital identity. https://www.politico.eu/article/estonia-digital-id-scheme-eu...
Looks nice and convenient!
One question, though: How do you say Hellō? [həˈləʊ] or [həˈlø] or [həˈlɔː]? :-)
One question, though: How do you say Hellō? [həˈləʊ] or [həˈlø] or [həˈlɔː]? :-)
Thanks!
[həˈləʊ] just like "hello" =)
I just have one question: with a name like Hello, how do you ever expect anybody to find your service on the Internet?
You are correct -- a generic word like 'hello' is challenging. Today people find https://hello.coop through Google currently by searching for "hello coop" or "hello identity"
Demo: https://greenfielddemo.com