HN user

dickhardt

119 karma

20 years exploring idea maze for identity

Founder/CEO Hellō - https://hello.coop

Ported Perl 5 to Windows Founder/CEO ActiveState & Sxip Identity Led design of OAuth 2.0 and JWTs Identity 2.0 https://www.youtube.com/watch?v=RrpajcAgR1E https://www.linkedin.com/in/dickhardt/ @DickHardt ex-MSFT, ex-AMZN

Posts3
Comments44
View on HN

Eartho sounds like a something a user wants. We have found that privacy is an added bonus, but that it is only one of many features a developer wants.

Adding yet another button that users don't understand confuses users.

I'm the founder of Hellō and we have a similar service that has cooperative governance. https://hello.coop/

FWIW it is a myth that Google uses where you login with Google for retargeting. Big Tech is always concerned about having to share user specific usage with US agencies. Google considers knowing where you login to be toxic data that they want to dump as quickly as possible. There are more than enough other signals from re-targetting.

OAuth 2.0 took the best features of what was already being deployed by Google, Microsoft, Yahoo, etc. and added in scopes and refresh tokens. The objective was to standardize how to delegate authorization so that developers did not have to learn slightly different ways of doing effectively the same thing.

Typing your username and password into a 3P website so it could crawl your contacts was horrible anti-pattern.

Hey HN, I’m Dick Hardt[1][2][3], and I’m the founder of Hellō.

Hellō is a new paradigm in Identity as a Service that empowers the user, simplifies development, and has a much lower cost structure.

If you are building a new app, Hellō is faster (minutes) and cheaper (free) than the alternatives.

https://www.hello.dev/docs/comparison/

... especially if you are building with Next.js, Express, or Fastify and using our Quickstart which removes all the manual configuration so that you are running locally in a minute, and can be deployed fully configured a minute later.

We posted about our co-operative approach on HN last year https://news.ycombinator.com/item?id=33177705

Since then we have added support for Discord, GitHub, GitLab, Mastodon, and Twitter. If you are on a mobile device, you can enroll a passkey for future logins on that device. On the desktop, you can scan a QR code to login with your phone.

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 here, or you can email me @ dick.hardt@hello.coop

[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

Tl;dr: If you are a developer considering adding World ID to your project. Wait.

If you see an app using World ID. Be safe.

The OAuth Best Security Current Practices have not been followed. Combined with the following point, applications using World ID may be vulnerable to attacks.

The implementation is not compliant with the OpenID Connect specification. Times are in milliseconds instead of seconds, requests can be made without required parameters. Update Aug 9, these have been addressed.

The user’s privacy is being violated. The authorization page presents no information on what the application is requesting, nor on what worldcoin.org is releasing. There are no application terms of service and privacy policy links.

The OP conflates the fediverse with Mastodon, and my understanding of his key point is that it is doomed because Mastodon is complicated to run. As the operator of https://press.coop, I agree. Mastodon is 10 yr old web tech (Ruby on Rails with Postgres) that does not take advantage of modern cloud architectures. (The streaming service is written in nodejs and is efficient and just works)

But software continues to evolve. There are numerous other software projects on the fediverse, Cloudflare's Wildebeest being an example of a more efficient, and easier to manage implementation. Crowdfunding has become a common means for instances to be funded. It is still early days for the fediverse, and the pace of innovation continues to accelerate. Remember that Twitter was twttr when it launched, and was an SMS based app. Flickr was a Flash app.

ActivityPub is the core protocol and is a W3C standard

Mastodon is the most popular implementation currently, but there are many other implementations in the fediverse

When I first looked at Mastodon, I had to choose between applying for an account, or choosing open enrollment to a server that had moderation issues. We created verified.coop for people that wanted to start using Mastodon right away and wanted to interact with other people using their real names. You can find me https://verified.coop/@DickHardt

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.

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.

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.

Q: how many of you will add support to Passkeys to your application? Is it worth the effort of adding yet-another-way-to-login for your users? It will be a long time before you could use it as the ONLY way to login. You will need to figure out how to enable your existing users to convert to Passkeys. Apple has a glide path for converting username password -> but not for other mechanisms.

I believe we in letting the user choose whatever way is best for them to login -- and to take that burden off of the developer. If you want to learn more, check out the Show HN post on Hellō I wrote this morning. https://news.ycombinator.com/item?id=33177705#33182379

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.

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!

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.