HN user

shrink

99 karma
Posts1
Comments11
View on HN

I can't speak to how things were in 2023 but today you do not need to visit Estonia.

Registering a company in the U.K. is very easy but the tax treatment is less favourable compared to Estonia. The U.K. leaving the European Union is also disadvantageous (although the full consequence of that is yet to be seen). All company filings in the U.K. are public, much more information about your company is public compared to Estonia.

I've had companies in a few different jurisdictions, including a Delaware C Corp[1] and currently an OÜ through Estonia's e-residency program.

Yes, it is fantastic and delivers on all of the promises. The only potential headache is that you must collect your e-residency card from an embassy which, depending on your location, might require travel to a nearby country.

I used Xolo but there are lots of agents in the directory. I like and recommend Xolo. No idea what the supposed issue with banking is, all of the agents have banking relationships and you can also use Revolut and Wise. My bank account was opened same day as the company.

Your details are published on the public register. The moment your registration is published you'll get lots of emails offering services, like banking (some people pretend to be Revolut but are actually just sending you affiliate links). Don't publish an email address you care about.

[1] The problem with forming a U.S. company is that all of the formation agents are layers on top of a convoluted nightmare. The formation agent can do their best to abstract away the complexity but the moment you have to peak behind the curtain you'll find yourself face to face with something very scary. The Estonian e-residency program is integrated all the way through.

https://e.ml A free inbrowser inbox for inspecting .eml (email) files. There are many one-off .eml viewers around but I found myself inspecting the same files many times which evolved into this concept of an inbrowser inbox. Plus, world's shortest domain (3 characters) and the domain is an exact match for the file extension, a fun novelty. Very easy to remember!

https://milliondollarchat.com a reimagining of the million dollar homepage for the AI age. Not useful, but fun. A free to use chatbot that anyone can influence by adding to the context. The chatbot's "thoughts" are streamed to all visitors.

I built handles.net[1] to make it easy for organisations to manage their member's handles, I think that using domain names for identity is neat and valuable, I have a vested interest in its success as a paradigm but... domain name "verification" is not the right solution today for non-technical people. I shared this sentiment a few months ago[2] and I have only become more confident in that assessment since.

The approach they've taken ("trusted verifiers") is an approach aligned with their values, as it is an extension of the labelling concept that is already well established in the ecosystem. As an idealist, it is a shame that they gave up, I think they could have had an impact on shifting how non-technical people view domain names and understand digital identity... but as a pragmatist, this is the right choice. Bluesky has to pick their battles, and this isn't a hill to die on.

[1] https://handles.net [2] https://news.ycombinator.com/item?id=42749786

I like the domain name identity model used by AT (so much so I built handles.net[1] for managing domain name based handles) but during my time reading opinions on Bluesky it has become apparent there's a lot more confusion about and distrust towards domain names amongst non-technical people than I previously thought.

I thought that people generally understood that domain names are owned and that their provenance can be independently verified (which is why they're valuable for identity) but there's a fairly large and vocal contingent of Bluesky users that are frustrated by domain names, so much so there are multiple efforts to establish a private verification system on Bluesky like verified.quest[2].

A lot of people do not want to look at and understand domain names, instead they want to see a name and a check mark. They want a central authority to tell them who is trustworthy and who is not. Domain names are a great solution for technology-adjacent people and I hope that they become more widely accepted, but I'm not too optimistic.

I am optimistic and hopeful that AT has a bright future ahead of it. I think AT has a lot going for it... but I do not think that identity will be a part of that. I suspect many apps built on AT will not bother with handles and will just use local display names.

[1] https://handles.net [2] https://verified.quest

After watching network requests, I think it's based on the use of the Javascript login functionality vs. the redirect functionality.

If the "Login with Google" button opens in a new tab and the Google OAuth flow completes in the second tab, then the process will have the "loading" screen after clicking "continue" because "loading" indicates Google OAuth is communicating back to the original tab. If the "Login with Google" button opens in the same tab, clicking "continue" triggers a 302 redirect to your callback URL of which the loading speed is controlled by your website.

The immediate workaround is to switch to opening the Google OAuth login page in a new window.

edit: "Sign In with Google for Web" appears to be what provides the new tab for login functionality https://developers.google.com/identity/gsi/web/guides/overvi...

edit edit: that's not to say you're wrong, Google should definitely fix this but "Sign In with Google for Web" is not impacted in case anyone needs an immediate fix for their own apps, they can switch to "Sign In with Google for Web" (a difference user interface for OAuth).

We use Google OAuth to handle hundreds of registrations each day and haven't encountered this before. No errors, no customer reports. Following your instructions, I logged in to my own Google account, removed the connection to our app (via "Third-party apps & services") and then did the login again: after clicking "continue" the screen changes to "loading" instantly before redirecting after a few seconds. There's no ability to click "continue" twice. I then tried to sign up to your app following your instructions and I can reproduce the issue there: the screen doesn't change to "loading" view that I get for our app.

Can you share a copy of your OAuth consent screen settings? Maybe there's an option influencing this behaviour.

edit: we do not use Auth0, our Google OAuth connection is built in house.

edit edit: comparing the URLs, our flow redirects from `https://accounts.google.com/signin/oauth/id` to `https://accounts.google.com/signin/oauth/consent` after clicking "continue" whereas yours remains on `https://accounts.google.com/signin/oauth/id` before redirecting to your app so there's definitely something different in the behaviour.