shrink
Joined 2 years ago
Joined 2 years ago
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.
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://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.
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 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.
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).
ChatGPT, Retool, Ramp, PostHog and HubSpot have the behaviour you've described.
I checked my browser history for `oauth/consent` and found the following examples with the loading behaviour:
HelpScout, Google Cloud, Termly.io
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.
1. Point your domain to `a.defunct.website` or `34.36.101.120`
2. Add a TXT record containing `defunct.theme=intentionally-blank`
Voila, you have an intentionally blank page, e.g: https://theme-blank.examples.dfnct.net
[1] https://defunct.net (my service)
adjohu: I tried to tackle making mine financially sustainable and chat-like so I came up with https://milliondollarchat.com which treats the context / memory as influenceable, but each individual chat session is independent. Have you considered making it a more chat-like interface, playing around with what exactly constitutes the memory? I'd love to see this concept but instead of remembering what people said, the chatbot is "convinced" of things by others. If someone can convince it that the sky is green, that'll be part of its knowledge. Each chat session would be sort of... pvp chat, the text version of r/place.