It is a React-based OSS audio player I developed primarily for museums and tour guides as I am really close to this industry and i was trying to scratch my own itch. In practice, thanks to the flexible design and architecture, it can be used for any use-case where you need to deliver sequential audio. Would like to hear any feedback or connect with someone who would need a solution like this.
I’ve actually started ignoring services where that’s the only login possibility.
Sorry even if your platform is the greatest thing ever, but I’ll find a different tool. I’ve read one too many stories about Google (or Apple!) closing the entire account over some bullshit unnecessary reason like “fraudulent” gift card issues or whatever.
I’m certain the affected people would’ve preferred to just pay back the amount in question instead of losing their entire Google Drive, or their 20 years of iCloud Photos or whatever.
It's the only reason I want to replace Tailscale with something else or look into self-host when have a bit of time during my vacation. They only allow login through a third party, which is a big no for me.
Tbf to Tailscale they allow any OIDC provider[1]. I wish this was more normalised, then we could have one login everywhere regardless of who hosts it (even if it's yourself).
While that isn't convenient is you don't want to use the public identity providers, it should make you think about what makes your identity on the Internet, and consider to have your own identity provider on a DNS domain you control.
I created my own AWS Cognito userpool just for tailscale. I recall the webfinger redirect was frustrating to get right but I refused to use Google/Apple as a gatekeeper to my own network so I had all the motivation to get it working.
You can host your own identity provider. Authentik, Keycloak, authelia or Zitadel work.
I don’t fully agree with tailscale’s decision to not want to be an identity provider but I understand it on some level. It simplifies their service greatly and the amount of asks for that will essentially have them build a full enterprise Entra-like solution that would be a constant maintain headache and they are not interested in that.
Beyond simplifying their service, it allows Tailscale to have reduced responsibilities (because of reduced collection of sensible data), and makes them a less interesting target for people wanting access to the data (wether illagally by hacking, or legally from government agencies). This probably makes them less attractive as targets for censorship.
It's not that weird. Building a modern accounts system is a lot of work and people don't like creating new accounts. So it's the path of least resistance for developers and users.
It's not even that it's hard to build a modern account system. It's that if you put your site behind a private / custom account system, and you post a link to it on HN (for example), everyone and their mother complains that it's requiring an email address and password. But if you put the same site behind a Google auth, most people wouldn't think twice to click the button.
I worked on the Google account system for a few years. I'd say it's a lot of work to beat it. Not necessarily "hard" for a team with the right skills, but certainly a lot of sweat, blood and tears.
A modern account system is expected to have, in rough implementation order: email confirmations, password strength checks, password reset emails, forgot password flows (=advanced ID verification as otherwise this becomes a backdoor into accounts), user profiles (+avatar image upload/recompression/hosting), usernames independent of email addresses along with ability to change usernames later, password brute forcing blockers, bulk signup prevention (=solid bot detection), abuse controls (can easily become a team of people), 2FA (SMS), 2FA (authenticator apps), 2FA (backup codes), 2FA (voice calls), 2FA (passkeys), 2FA: recovery when both factors are lost, enterprise SSO integration (SAML), enterprise SSO (Active Directory), fast global signout support (much harder than it looks), cookie theft mitigations, heuristic online login risk analysis to catch cases where an attacker knows the right password via phishing, support for signing the user in to multiple domains, audit logging so users can review their own sign-in history, age verification and restriction support, and possibly support for being logged in to multiple accounts in a single browser session.
Oh, that all has to be HA, and the account system is the keys to the kingdom so the security requirements are the strictest of any part of your system.
You might say we don't need all of that, but expectations rise over time. Maybe 20 years ago you could get away with a simple account system and an automatic forgot password flow that just assumes the user still has access to their email. Maybe today you still can write a simple system, if you don't expect to have many users and are willing to implicitly delegate identity to webmail providers anyway (the moment you assume the user has access to a secure email account you're basically doing Sign In With Google anyway for 90% of users). But if you roll your own accounts, and then the user gets phished and someone logs in from an obviously suspicious place with the right password, they won't say "yes that's my fault" anymore, they'll say "Google could block that log in, why didn't you?" or maybe "Why didn't you support 2FA? It's your fault".
> A modern account system is expected to have, in rough implementation order: email confirmations, password strength checks, password reset emails, forgot password flows (=advanced ID verification as otherwise this becomes a backdoor into accounts), user profiles (+avatar image upload/recompression/hosting), usernames independent of email addresses along with ability to change usernames later, password brute forcing blockers, bulk signup prevention (=solid bot detection), abuse controls (can easily become a team of people), 2FA (SMS), 2FA (authenticator apps), 2FA (backup codes), 2FA (voice calls), 2FA (passkeys), 2FA: recovery when both factors are lost, enterprise SSO integration (SAML), enterprise SSO (Active Directory), fast global signout support (much harder than it looks), cookie theft mitigations, heuristic online login risk analysis to catch cases where an attacker knows the right password via phishing, support for signing the user in to multiple domains, audit logging so users can review their own sign-in history, age verification and restriction support, and possibly support for being logged in to multiple accounts in a single browser session.
You don't need half of that. Even to this day, anthropic lets you log in by sending a code to your email. No password, no dealing with resets, no MFA. So yeah, you definitely don't need all of that.
That's what I said. If you're willing to implicitly rely on webmail provider's identity/auth systems then you can simplify - but that's not much different to just adding a Sign in with Google/Microsoft button. The identity is ultimately controlled by the email service and almost all users are on just two of those.
What web auth system doesn't rely on a user having a secure inbox? It is vastly different from signing in with an IdP, since I can use my email address regardless of who my mail provider is.
If you’re building a paid service you’re probably already using cognito or supabase or something. That puts you a few clicks aways from 5+ other identity providers and normal accounts.
It’s funny how the tides shift. I remember the more dominant online position in the early 2010s being “I don’t want to create yet-another-account for your website. Just let me sign in with my google account”. I’m with you though
Until one day your Google account gets locked with an automatically generated message that you violated an unspecified rule. Good luck getting contact to a human support.
It would help a heap to show some blogposts and on the landing page so people would know what they will get when you ask for account even for the readers.
I built a simple tool that enables anyone to quickly extract map data and turn them into SVG you can edit or modify in your favorite design tool of choice.
Is the state of the webdesign really in a point where people bluntly copy others work for commercial purposes and celebrate these acts on their blogs? I think the line is pretty clear here. I remember the old Dan Mall's article on this topic which is much more inspirational (and "correct"): https://medium.com/@danielmall/stealing-your-way-to-original...
> Is the state of the webdesign really in a point where people bluntly copy others work for commercial purposes and celebrate these acts on their blogs?
Yes and the reason is not subtle...
We'll see much more of that now: people defending theft and then arguing that if you change the position of one comma in the entirety of Harry Potter, then it's an acceptable new product.
It's crystal clear why: LLMs are very good at copying / stealing / tweaking.
What's not clear though is how are licenses, including the open-source ones, respected here?
I'm not just talking about copying a website pixel-for-pixel: I'm talking about things like re-implementing a compiler, supposedly from scratch, when we all know it's not at all a clean room implementation.
Expect a wave of "theft is good" from the same people who are pushing 24/7 "buy commercial AI models subscriptions" content (which I have btw so no need to sell me more of them).
> We bet that vibecoding would allow us to move faster
> people defending theft and then arguing that if you change the position of one comma in the entirety of Harry Potter, then it's an acceptable new product.
History rhymes, indeed. Almost two centuries ago, Balzac wrote:
> A man spends ten years of his life searching for an industrial secret, a machine, some kind of discovery, he takes out a patent, he believes he is master of his thing, he is followed by a competitor who, if he has not foreseen everything, perfects his invention with a screw, and thus takes it out of his hands. [Illusions perdues, 1843]
Do you not believe that the design of the "stolen" landing page was not itself 97% stolen from marketing landing pages that came before it?
It's unusual seeing the process stated so bluntly, but for something as cookie-cutter as a company homepage this has been how web designers have done things for decades. Or, at the very least, it's how the craft is learned.
I think the Mintlify designers viewed dozens if not hundreds of examples, then thought very carefully about exactly what they needed to express for their page and how best to express it. Then they built their page step by step, sweating over every detail.
Then Kibu came along, lifted the entire thing, changed "3%" of it and called it their own.
Agreed. As someone who has built landing pages like that professionally you take inspiration from a wide range of sources.
Directly copying is tacky and immoral - it's also not effective. You should be thinking about how to position _your product_ not how someone else positioned their product.
Yes, users can download routes and use navigation fully offline once a route's saved. Great for low-service areas, or just not burning data while walking around a new city. The explore page still needs a connection, but the actual trip-day experience — following a saved route, navigation, waypoints, notes, all works offline. Good question!
There is one issue: “normal locals” are usually not the best ones to walk you through their city. They never go sightseeing or to attractions meant for tourists. And tourists always want to see this top 10 things from the list. Majority don’t want to risk and go offbeat path when their resources are limited.
It is a React-based OSS audio player I developed primarily for museums and tour guides as I am really close to this industry and i was trying to scratch my own itch. In practice, thanks to the flexible design and architecture, it can be used for any use-case where you need to deliver sequential audio. Would like to hear any feedback or connect with someone who would need a solution like this.
reply